Webhook и REST API простыми словами: как связать разные системы - Разработка сайтов, автоматизация и IT-решения

Представьте обычную ситуацию: клиент оставляет заявку на сайте, менеджер должен получить её в CRM, клиенту нужно отправить сообщение в Telegram, а после оплаты автоматически открыть доступ к продукту.

Если все эти действия выполнять вручную, сотрудники будут постоянно переключаться между сервисами, переносить данные, проверять оплаты и следить, чтобы ничего не потерялось.

Именно для таких задач существуют API, вебхуки и интеграции.

Но что скрывается за техническими терминами REST API и Webhook? Чем они отличаются? Почему некоторые интеграции работают годами, а другие начинают терять заявки при первой серьёзной нагрузке?

Разберём на понятных примерах из автоматизации бизнеса.

Зачем бизнесу связывать разные сервисы

Сегодня даже небольшой проект редко использует одну программу.

У компании может быть сайт на WordPress, CRM для работы с клиентами, Telegram-бот для коммуникаций, отдельная система оплаты и образовательная платформа.

Каждый сервис выполняет собственную задачу.

Проблемы начинаются, когда информация должна переходить между ними.

Например:

Клиент оставил заявку на сайте.
Менеджер должен увидеть её в amoCRM.
После оплаты доступ к обучению должен открыться в GetCourse.
Telegram-бот должен отправить инструкцию.
Руководителю необходимо видеть состояние заказа.

Без интеграций информация передаётся вручную. Это увеличивает количество действий, усложняет контроль и создаёт дополнительные возможности для ошибок.

Автоматизация позволяет организовать обмен данными между системами.

Но для этого нужно понимать, каким образом они взаимодействуют.

Что такое API простыми словами

API (Application Programming Interface) — это программный интерфейс, через который одна система может обращаться к возможностям другой.

Проще говоря, API — это набор правил и способов взаимодействия между приложениями.

Допустим, у компании есть CRM, в которой хранятся контакты клиентов.

Другому приложению необходимо создать новый контакт.

Вместо того чтобы открывать CRM и вручную заполнять карточку, приложение отправляет запрос через API.

CRM проверяет запрос и, если всё корректно, выполняет действие.

Пример API на бытовой аналогии

Представьте ресторан.

Посетитель не идёт на кухню и не начинает самостоятельно готовить заказ. Он передаёт информацию официанту.

Официант принимает заказ, передаёт его на кухню и возвращает результат.

В этой аналогии:

Посетитель — приложение, которому требуется информация или действие.
Официант — API.
Кухня — система, выполняющая операцию.
Заказ — API-запрос.
Готовое блюдо или сообщение об ошибке — ответ API.

Приложению не требуется знать внутреннее устройство CRM или платёжного сервиса.

Ему достаточно понимать, какие запросы разрешены, как их отправлять и какой ответ ожидать.

Что можно делать через API

Возможности зависят от конкретного сервиса.

Через API можно:

Создавать и обновлять контакты.
Получать информацию о сделках.
Изменять статусы заказов.
Передавать данные анкет.
Проверять записи клиентов.
Создавать задачи сотрудникам.
Получать сведения об оплатах.
Запускать разрешённые действия в других системах.

Но важный момент: наличие API не означает, что через него можно выполнить абсолютно любое действие.

У каждого сервиса есть собственные ограничения, методы авторизации и правила доступа.

Что такое REST API

REST (Representational State Transfer) — это архитектурный стиль построения взаимодействия между системами.

Когда говорят «REST API», обычно имеют в виду API, организованный вокруг ресурсов и использующий возможности HTTP.

HTTP — тот же протокол, который используется при открытии веб-сайтов.

Только вместо привычной страницы приложение может получать структурированные данные, например в формате JSON.

Как выглядит REST API-запрос

Предположим, приложение должно получить информацию о заказе.

Условный адрес API:

https://api.example.com/orders/125

Приложение отправляет GET-запрос.

Сервер может вернуть данные:

{
  "id": 125,
  "status": "paid",
  "amount": 4900,
  "currency": "RUB"
}

Здесь:

id — идентификатор заказа.
status — текущий статус.
amount — сумма.
currency — валюта.

Это демонстрационный пример, а не реальный API конкретной платёжной системы.

Другое приложение может использовать полученную информацию в собственной логике.

Например, если заказ оплачен, запустить процесс выдачи доступа к материалам.

Основные методы REST API

Метод	Для чего обычно используется
GET	Получение данных
POST	Создание ресурса или выполнение операции
PUT	Полная замена представления ресурса
PATCH	Частичное изменение ресурса
DELETE	Удаление ресурса

Например, GET может получать информацию о клиенте, а POST — создавать новую запись.

Однако конкретные действия зависят от документации API.

Нельзя считать, что любой POST-запрос обязательно создаёт новый объект, а любой PATCH работает одинаково во всех сервисах.

Что происходит после отправки запроса

Сервер обрабатывает запрос и возвращает HTTP-статус.

Распространённые варианты:

200 OK — запрос успешно обработан.

201 Created — ресурс успешно создан.

400 Bad Request — запрос составлен некорректно.

401 Unauthorized — отсутствует корректная аутентификация.

403 Forbidden — доступ к операции запрещён.

404 Not Found — запрашиваемый ресурс не найден.

429 Too Many Requests — превышено допустимое количество запросов.

500 Internal Server Error — внутренняя ошибка сервера.

При разработке интеграций важно учитывать не только успешные ответы.

Если приложение ожидает исключительно HTTP 200, а остальные ситуации никак не обрабатывает, рано или поздно возникнут проблемы.

Что такое Webhook простыми словами

Webhook, или вебхук, — это механизм отправки уведомления от одной системы другой при наступлении определённого события.

Например, когда клиент оплатил заказ, платёжный сервис может автоматически отправить HTTP-запрос на указанный адрес.

Получатель обработает уведомление и выполнит необходимые действия.

В отличие от регулярных запросов за статусом, инициатором передачи данных выступает система, в которой произошло событие.

Пример работы вебхука

Допустим, интернет-магазин принимает оплату.

После успешного платежа платёжная система отправляет уведомление:

{
  "event": "payment.succeeded",
  "payment_id": "pay_125",
  "order_id": 125,
  "status": "succeeded"
}

Это условный формат события.

Получив уведомление, система может:

Проверить подлинность сообщения.
Найти соответствующий заказ.
Убедиться, что платёж ещё не был обработан.
Изменить статус заказа.
Запустить процесс выдачи товара или доступа.
Отправить уведомление клиенту.

Всё происходит без необходимости вручную проверять каждую оплату.

Но есть важная тонкость: получение вебхука не означает, что событие нужно сразу считать подтверждённым.

Для критичных операций необходимо проверить подлинность уведомления и, если требует документация поставщика, дополнительно сверить состояние операции через API.

Чем REST API отличается от Webhook

Здесь возникает главная путаница.

REST API и Webhook часто противопоставляют друг другу, хотя они решают разные задачи.

REST API — это способ организации взаимодействия с ресурсами системы.

Webhook — это способ уведомления другой системы о произошедшем событии.

При этом вебхук сам обычно отправляется обычным HTTP-запросом.

Основное отличие на примере оплаты

Представим, что система должна узнать, оплатил ли клиент заказ.

Вариант с периодическими API-запросами

Приложение регулярно обращается к платёжному сервису:

«Заказ №125 уже оплачен?»

Через некоторое время повторяет запрос.

Потом ещё раз.

Это называют polling, или периодическим опросом.

Вариант с Webhook

Платёжный сервис самостоятельно сообщает:

«По заказу №125 произошло событие успешной оплаты».

Приложение получает уведомление и начинает обработку.

Сравнение REST API и Webhook

Критерий	REST API	Webhook
Назначение	Работа с ресурсами и операциями	Уведомление о событиях
Кто инициирует взаимодействие	Клиент API	Отправитель события
Когда передаются данные	При отправке запроса	При наступлении события
Получение актуального состояния	Обычно через запрос к ресурсу	Зависит от содержимого события
Типичное применение	Получить или изменить данные	Сообщить об оплате, заявке, изменении
Особенность	Нужно учитывать лимиты и ответы	Нужно учитывать повторы и задержки доставки

На практике эти механизмы прекрасно дополняют друг друга.

Webhook сообщает, что произошло событие, а REST API позволяет получить дополнительные сведения или выполнить нужную операцию.

Как связать сайт, CRM и Telegram-бота

Рассмотрим типовую архитектуру автоматизации обработки заявок.

У компании есть сайт на WordPress, amoCRM и Telegram-бот.

Необходимо, чтобы пользователь оставил заявку на сайте, информация появилась в CRM, а ответственный сотрудник получил уведомление.

Как работает схема

Шаг 1. Пользователь отправляет форму

На сайте заполняется форма с именем, телефоном и выбранной услугой.

Шаг 2. WordPress передаёт данные

После проверки и обработки формы сайт отправляет информацию в интеграционный сервис или непосредственно в CRM.

Шаг 3. Создаётся контакт и сделка

Через API CRM выполняется поиск существующего контакта и, при необходимости, создание новой записи.

Шаг 4. Сохраняются результаты

Интеграция фиксирует идентификатор сделки и состояние операции.

Шаг 5. Отправляется уведомление

Telegram-бот получает задачу уведомить ответственного сотрудника.

Шаг 6. Обрабатываются ошибки

Если CRM временно недоступна, операция не должна бесследно исчезнуть. Её можно сохранить для повторной отправки.

Почему лучше не делать всё непосредственно в обработчике формы

Технически можно отправить запрос к CRM прямо в момент отправки формы.

Но если CRM отвечает медленно, пользователь будет ждать завершения операции.

Если API недоступен, форма может завершиться ошибкой, хотя данные пользователя уже получены.

Для более надёжных решений удобно использовать промежуточную обработку.

Например, сначала сохранить заявку, затем передать её в очередь и выполнить внешние запросы независимо от времени ответа формы.

В этом случае интерфейс сайта не зависит напрямую от скорости стороннего API.

Однако пользователю нельзя сообщать, что заявка уже доставлена в CRM, если фактически она только поставлена в очередь.

Зачем нужен промежуточный сервис для интеграций

Когда систем становится много, прямые соединения между ними постепенно усложняются.

Допустим, компания использует:

WordPress.
amoCRM.
Битрикс24.
GetCourse.
Telegram.
Платёжный сервис.
Собственные приложения.

Можно связывать системы напрямую.

Но если каждая начинает взаимодействовать с несколькими другими, появляется большое количество независимых соединений и дублирующейся логики.

Например, одна интеграция по-своему форматирует телефонные номера, другая создаёт дубли контактов, третья не учитывает ошибку API.

Промежуточный сервис позволяет централизовать часть операций.

Как выглядит такая архитектура

Вместо множества прямых связок появляется отдельный компонент:

Сайт / Бот / CRM → Интеграционный сервис → Другие системы

Этот сервис может:

Принимать вебхуки.
Проверять входящие данные.
Преобразовывать форматы.
Выполнять запросы к API.
Сохранять историю операций.
Обрабатывать ошибки.
Контролировать повторные попытки.
Отправлять уведомления о сбоях.

Для подобных задач можно использовать Python, PHP или другую технологию, подходящую под существующую инфраструктуру.

Но промежуточный сервис не нужно создавать ради самой идеи сложной архитектуры.

Если две системы имеют стабильную готовую интеграцию, которая полностью решает задачу, дополнительное приложение может быть избыточным.

Пример из моей практики: CRM, YClients и Telegram

В период работы руководителем отдела разработки в OllyTeam я занималась не только организацией работы команды, но и технической архитектурой интеграций.

Одно из направлений — построение кастомной API-системы для взаимодействия мобильных приложений, сайтов, Telegram-ботов и CRM-виджетов с YClients.

При разработке приходилось учитывать особенности API и необходимость согласованной работы разных компонентов.

Также я разработала собственный виджет для amoCRM, заменяющий стандартный виджет интеграции с YClients.

Это хороший пример того, почему при сложной автоматизации нельзя ограничиваться вопросом «Есть ли у сервиса API?».

Гораздо важнее понять:

Какие операции API действительно позволяет выполнять.
Какие данные доступны.
Как устроена авторизация.
Какие ограничения есть у запросов.
Как согласовать логику нескольких систем.
Как корректно обрабатывать возникающие ошибки.

При этом готовая интеграция не всегда будет плохим решением.

Если она соответствует требованиям и поддерживается поставщиком, иногда её использование рациональнее собственной разработки.

Я предпочитаю начинать с анализа задачи и возможностей существующих инструментов, а не сразу писать новое приложение.

Как выглядят API-запросы на практике

Для понимания принципа рассмотрим небольшой пример на Python.

Предположим, нам нужно получить информацию о заказе из тестового API.

import json
from typing import Any
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen


def get_order(order_id: int, token: str) -> dict[str, Any]:
    """
    Получает данные заказа через HTTPS API.

    :param order_id: Идентификатор заказа.
    :param token: Токен доступа к API.
    :return: Словарь с информацией о заказе.
    :raises ValueError: Если аргументы или ответ некорректны.
    :raises RuntimeError: Если сервер вернул ошибку.
    """
    if order_id <= 0 or not token:
        raise ValueError("Некорректный ID заказа или токен")

    request = Request(
        url=f"https://api.example.com/orders/{order_id}",
        headers={
            "Authorization": f"Bearer {token}",
            "Accept": "application/json",
        },
        method="GET",
    )

    try:
        with urlopen(request, timeout=10) as response:
            payload = json.load(response)

    except HTTPError as error:
        raise RuntimeError(
            f"API вернул HTTP {error.code}"
        ) from error

    except URLError as error:
        raise RuntimeError(
            "Не удалось подключиться к API"
        ) from error

    if not isinstance(payload, dict):
        raise ValueError("API вернул неожиданный формат данных")

    return payload

Это учебный пример. Адрес api.example.com условный, а конкретный формат авторизации и ответа нужно брать из документации используемого сервиса.

Что делает этот код

Функция получает идентификатор заказа и токен доступа.

Затем формирует GET-запрос, добавляет заголовок авторизации и отправляет запрос по HTTPS.

Если сервер отвечает успешно и возвращает JSON-объект, функция преобразует его в словарь Python.

Если возникает сетевая ошибка или сервер отвечает неуспешным HTTP-статусом, вызывающий код получает исключение.

Здесь предусмотрен тайм-аут, чтобы приложение не ожидало ответ бесконечно.

Но для полноценной интеграции этого недостаточно.

В реальном проекте понадобятся более подробная проверка ответа, логирование, обработка ограничений API, обновление токенов и продуманная стратегия повторных запросов.

Как принимать Webhook на Python

Для демонстрации принципа можно использовать простой HTTP-обработчик на Flask.

Приложение принимает JSON-сообщение от внешней системы, проверяет подпись и возвращает ответ.

import hashlib
import hmac
import json
import os
from typing import Any

from flask import Flask, Response, request

app = Flask(__name__)


def verify_signature(body: bytes, signature: str) -> bool:
    """
    Проверяет HMAC-подпись полученного сообщения.

    :param body: Исходные байты тела запроса.
    :param signature: Подпись из заголовка.
    :return: True, если подпись корректна.
    """
    secret = os.environ["WEBHOOK_SECRET"].encode("utf-8")

    expected = hmac.new(
        secret,
        body,
        hashlib.sha256,
    ).hexdigest()

    return hmac.compare_digest(expected, signature)


@app.post("/webhook")
def receive_webhook() -> tuple[Response, int]:
    """
    Принимает событие от внешнего сервиса.

    :return: JSON-ответ и HTTP-статус.
    """
    body = request.get_data(cache=False)
    signature = request.headers.get("X-Signature", "")

    if not verify_signature(body, signature):
        return app.json.response({"error": "Invalid signature"}), 401

    try:
        event: Any = json.loads(body)
    except json.JSONDecodeError:
        return app.json.response({"error": "Invalid JSON"}), 400

    if not isinstance(event, dict):
        return app.json.response({"error": "Invalid payload"}), 400

    # Здесь событие необходимо надёжно сохранить или поставить в очередь.
    # Нельзя подтверждать успешную обработку до сохранения события.
    return app.json.response({"status": "accepted"}), 202

Пример показывает общую структуру обработки вебхука, но не является готовым промышленным обработчиком.

Формат подписи X-Signature, алгоритм HMAC и правила формирования подписываемых данных зависят от конкретного поставщика API.

Кроме того, перед возвратом успешного ответа необходимо действительно сохранить событие или гарантированно передать его в очередь.

В приведённом примере этот шаг оставлен в виде комментария.

Для реального сервиса также понадобятся HTTPS, ограничения размера запросов, защита от повторной обработки событий, журналирование и контроль очередей.

Почему интеграции иногда теряют данные

Допустим, клиент оставил заявку, сайт сообщил об успешной отправке, но в CRM ничего не появилось.

При этом в браузере ошибок нет.

Причина может находиться на любом этапе обработки.

Проблема №1. Ошибка внешнего API

CRM могла вернуть HTTP 500 или временно не отвечать.

Если интеграция не проверяет ответ, система может ошибочно считать заявку отправленной.

Проблема №2. Истёк токен авторизации

Некоторые API используют временные токены.

Если система не обновляет их автоматически, через определённое время запросы начинают завершаться ошибками.

Проблема №3. Превышены лимиты запросов

У многих сервисов существуют ограничения на количество обращений.

Если приложение отправляет слишком много запросов, сервер может возвращать HTTP 429.

Проблема №4. Изменился формат данных

Например, внешний API начал возвращать дополнительное поле или изменил допустимые значения статуса.

Если обработчик жёстко привязан к прежнему формату, интеграция может перестать работать.

Проблема №5. Нет контроля результатов

Одна из самых неприятных ситуаций — когда запрос отправлен, но никто не проверяет, был ли он успешно обработан.

Именно поэтому важно хранить состояние операций, а не ограничиваться фактом отправки HTTP-запроса.

Как сделать API-интеграцию надёжной

При проектировании интеграций я обращаю внимание не только на передачу данных, но и на поведение системы при ошибках.

Проверка входящих данных

Нельзя считать, что внешняя система всегда передаст корректную информацию.

Необходимо проверять наличие обязательных полей, типы данных, допустимые значения и соответствие ожидаемой структуре.

Авторизация и безопасность

API-ключи и токены не должны находиться в открытом JavaScript, публичном репозитории или логах.

Для серверных интеграций стоит использовать безопасное хранение секретов и минимально необходимые права доступа.

Вебхуки желательно проверять по подписи, если поставщик поддерживает такой механизм.

Логирование

Для каждой важной операции полезно сохранять:

Время события.
Источник.
Тип операции.
Идентификатор объекта.
Результат обработки.
Код ошибки при неудаче.
Количество попыток.

При этом пароли, токены, платёжные реквизиты и другие чувствительные данные не должны попадать в журналы.

Повторные попытки

Если внешняя система временно недоступна, полезно предусмотреть повторную отправку.

Но повторять все операции подряд опасно.

Например, повторный запрос на создание платежа или заказа способен привести к дублированию, если API не обеспечивает защиту от повторов.

Поэтому необходимо использовать идентификаторы операций, идемпотентные обработчики и учитывать документацию поставщика.

Очереди задач

Если обработка операции занимает много времени, её можно передать в очередь.

Это позволяет быстрее отвечать на входящие запросы и выполнять тяжёлую работу отдельно.

Но сама очередь тоже требует контроля: задачи могут зависать, завершаться ошибками и нуждаться в повторном выполнении.

Мониторинг

Если интеграция критична для продаж, желательно узнавать об ошибке раньше, чем о ней сообщит клиент.

Для этого можно использовать журналы, уведомления, контроль количества необработанных событий и периодические проверки состояния системы.

Готовые интеграторы или собственная разработка?

Для связывания сервисов необязательно сразу писать код.

Существуют готовые инструменты автоматизации, конструкторы ботов и интеграционные платформы.

Например, можно использовать SaleBot, BotHelp, SendPulse или специализированные сервисы обмена данными, если они поддерживают необходимый сценарий.

Но выбор зависит от сложности процесса.

Готовое решение рационально, когда интеграция типовая, поддерживается платформой и не требует большого количества нестандартных условий.

Собственная разработка полезнее, когда необходимо объединить сложные API, реализовать индивидуальную логику, контролировать обработку событий и хранить собственные данные.

Иногда оптимальным становится сочетание обоих подходов.

Например, SaleBot отвечает за коммуникацию с клиентом, а промежуточный Python-сервис обрабатывает нестандартные запросы к CRM.

В таком случае нет необходимости переписывать всю воронку с нуля.

Частые вопросы об API и вебхуках

Можно ли связать два сервиса, если у них нет готовой интеграции?

Да, если у сервисов есть подходящие API, вебхуки или другие разрешённые способы обмена данными.

Но нужно проверить, позволяют ли они выполнять именно те операции, которые необходимы бизнесу.

Webhook работает без API?

Вебхук может существовать отдельно от REST API.

Например, сервис способен отправлять уведомления о событиях, но не предоставлять публичный интерфейс для управления всеми своими данными.

Однако на практике вебхуки часто используются совместно с API.

Можно ли подключить amoCRM к Telegram?

Да. В зависимости от задачи используются готовые решения или собственные интеграции.

Через API CRM можно работать с контактами, сделками и другими поддерживаемыми объектами, а через Telegram Bot API отправлять сообщения и обрабатывать действия пользователей.

Нужно ли знать Python для работы с API?

Необязательно.

Простые интеграции можно собирать через готовые платформы.

Python, PHP или другие языки нужны, когда требуется индивидуальная логика или собственный сервис.

Что лучше: Webhook или постоянная проверка через API?

Если система поддерживает надёжные уведомления о событиях, вебхуки часто позволяют избежать лишних запросов.

Однако для критичных процессов полезно предусмотреть периодическую сверку состояния через API, чтобы обнаруживать пропущенные или необработанные события.

Что делать, если вебхук пришёл дважды?

Обработчик должен распознавать повторное событие и не выполнять критичное действие повторно.

Например, не создавать вторую сделку или не выдавать один и тот же доступ несколько раз, если это нарушает бизнес-логику.

Итог: REST API и Webhook — основа современной автоматизации

Сайт, CRM, Telegram-бот и платёжный сервис могут работать как отдельные приложения.

А могут стать частями единого бизнес-процесса.

REST API позволяет получать и изменять данные, а вебхуки помогают реагировать на события без постоянных ручных проверок.

Но качественная интеграция — это не просто отправка JSON из одной системы в другую.

Она должна учитывать ошибки, безопасность, ограничения API, повторные события и корректность бизнес-операций.

Именно от этих деталей зависит, будет ли автоматизация действительно помогать бизнесу или превратится в ещё один источник технических проблем.

Меня зовут Светлана Преснякова. Я занимаюсь разработкой API-интеграций, автоматизацией бизнес-процессов, Telegram-ботами и технической архитектурой проектов.

В моём опыте — интеграции Битрикс24, amoCRM, GetCourse, YClients, платёжных сервисов, сайтов и собственных приложений.

Если требуется связать несколько систем, устранить ошибки существующей интеграции или разработать собственный промежуточный сервис, могу помочь разобраться в архитектуре и реализовать подходящее решение.

Подробнее об услугах: https://svkote.ru/services/

Мой профессиональный опыт: https://svkote.ru/resume/

Главная страница: https://svkote.ru/