ЗамыселЪ Глеба Киренкова

ЗамыселЪ Глеба Киренкова

Бизнес ·

Вебхук — это событие, за которое кто-то должен отвечать

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

Событие вместо постоянного вопроса

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

Так работает событийная связь. Отправитель знает, когда случилось изменение; получатель решает, как на него реагировать. Это не замена API целиком: часто вебхук сообщает об изменении, а подробности получатель затем читает через API. Разницу полезно сохранить в архитектуре.

У сообщения есть контракт

Недостаточно указать URL и нажать «включить». Стороны должны согласовать тип события, идентификатор, время, состав полей и версию схемы. Особенно важно различать «заявка создана» и «заявка подтверждена»: это разные бизнес-действия.

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

Подлинность проверяют до обработки

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

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

Одно событие может прийти дважды

Сеть обрывается, ответ теряется, отправитель повторяет доставку. Если обработчик каждый раз создаёт новую запись, один заказ превращается в два. Поэтому событию нужен стабильный идентификатор, а действию — правило повторной обработки без дубля.

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

Быстрый ответ отделяют от долгой работы

Получатель должен быстро принять сообщение и зафиксировать его. Долгие операции — запись в несколько систем, генерация документа, вызов ИИ — лучше выполнять отдельно с собственными повторными попытками и журналом ошибок.

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

Наблюдаемость завершает интеграцию

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

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

Начинать стоит с одного бизнес-события

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

В рамках Метода я начинаю интеграцию с одного события и его результата: например, заявка должна оказаться у ответственного человека. После этого проектируются схема, доступ, повторная обработка и наблюдение. Такой разбор может стать первым шагом к автоматизации заявок, CRM или другого внутреннего цифрового инструмента.

ИИ для конкретного процесса

Если вы рассматриваете внедрение ИИ, начнём с процесса, доступных данных, границ автоматизации и способа проверить результат.

Обсудить внедрение ИИ