Webhook — это механизм автоматического уведомления одной системы другой о наступлении определенного события. Когда событие происходит, источник отправляет HTTP-запрос на заранее указанный адрес получателя.
Например, платежный сервис может отправить интернет-магазину Webhook после успешной оплаты заказа. Магазину не нужно каждую минуту спрашивать платежную систему, изменился ли статус: уведомление приходит автоматически.
Webhooks широко используются в интеграциях между сервисами, платежных системах, CRM, интернет-магазинах, Git-платформах, CI/CD, службах доставки и облачных приложениях.
Что такое Webhook простыми словами
Webhook можно представить как автоматическое сообщение от одной программы другой.
Обычное API часто работает по принципу: клиент сам обращается к серверу и спрашивает нужную информацию. Webhook работает наоборот: сервер сам отправляет запрос клиентской системе, когда происходит важное событие.
Webhook позволяет системе не проверять состояние постоянно, а получить уведомление именно в момент наступления события.
Например, служба доставки сообщает интернет-магазину, что заказ передан курьеру. Как только статус меняется, ее сервер автоматически вызывает Webhook магазина.
Для чего нужны Webhooks
Webhooks используются там, где одна система должна быстро сообщать другой о событии.
- подтверждение платежа;
- изменение статуса заказа;
- создание заявки в CRM;
- уведомление о новом сообщении;
- запуск CI/CD Pipeline;
- реакция на Commit или Merge Request;
- уведомление о завершении длительной операции;
- синхронизация данных;
- обработка событий доставки;
- интеграция SaaS-сервисов.
Как работает Webhook
Типовая схема включает систему-источник и систему-получатель.
- Получатель создает HTTP endpoint для Webhook.
- Адрес endpoint регистрируется в системе-источнике.
- В источнике происходит событие.
- Источник формирует HTTP-запрос.
- Запрос отправляется на Webhook URL.
- Получатель проверяет запрос и обрабатывает событие.
- Получатель возвращает HTTP-ответ.
Например, интернет-магазин указывает платежной системе адрес /webhooks/payment. После оплаты платежный сервис отправляет туда информацию о транзакции.
Что такое Webhook URL
Webhook URL — адрес HTTP endpoint, на который отправляются события.
Он должен быть доступен системе-источнику и принимать запросы ожидаемого формата.
https://example.ru/webhooks/payment
Не следует использовать случайный URL без защиты. Endpoint должен проверять источник запроса и корректность полученных данных.
Webhook и HTTP
Большинство Webhooks работает поверх HTTP или HTTPS.
Источник обычно отправляет POST-запрос, содержащий сведения о событии в теле.
Получатель возвращает HTTP status, подтверждающий успешную или неуспешную обработку.
| Код | Типичное значение |
|---|---|
| 200 | Событие успешно принято |
| 202 | Событие принято для асинхронной обработки |
| 400 | Некорректный запрос |
| 401 | Не прошла проверка аутентификации |
| 403 | Запрос запрещен |
| 500 | Ошибка обработки на стороне получателя |
| 503 | Сервис временно недоступен |
Пример Webhook
Платежная система отправляет интернет-магазину событие об успешной оплате.
{"event":"payment.succeeded","payment_id":"pay_125","order_id":"501","amount":4500,"status":"paid"}Backend магазина принимает запрос, проверяет подпись, находит заказ 501 и меняет его статус на оплаченный.
После этого система может поставить задачу на отправку письма и передачу заказа в службу доставки.
Webhook и API
Webhook является одним из способов интеграции и часто используется вместе с API.
Через API клиент сам запрашивает данные или запускает операции. Через Webhook сервер сообщает клиенту о событии.
| API | Webhook |
|---|---|
| Клиент инициирует запрос | Источник события инициирует запрос |
| Используется для чтения и изменения данных | Используется для уведомления о событиях |
| Клиент решает, когда обратиться | Запрос отправляется при событии |
| Подходит для получения текущего состояния | Подходит для реакции на изменение состояния |
Webhook и Polling
Polling — периодический опрос сервера на предмет изменений.
Например, интернет-магазин каждые 30 секунд спрашивает платежную систему, был ли оплачен заказ.
При Webhook необходимость постоянного опроса исчезает: платежная система сама сообщает об оплате.
| Polling | Webhook |
|---|---|
| Регулярные запросы | Запрос только при событии |
| Создает лишний трафик при отсутствии изменений | Экономнее по количеству обращений |
| Клиент контролирует частоту | Источник контролирует момент уведомления |
| Проще при недоступном входящем endpoint | Требует доступного Webhook URL |
Почему Webhook не гарантирует однократную доставку
Сетевые системы работают с ошибками, timeout и повторными попытками.
Представим, что получатель успешно обработал Webhook, но его HTTP-ответ потерялся. Источник решает, что доставка завершилась неудачно, и отправляет событие повторно.
Поэтому приложение должно быть готово получить одно событие несколько раз.
Webhook следует проектировать так, чтобы повторная доставка одного события не приводила к повторному выполнению критичной бизнес-операции.
Идемпотентность Webhook
Идемпотентность означает, что повторная обработка одного события не создает нежелательного повторного результата.
Например, два одинаковых Webhook о платеже не должны создать два заказа или дважды начислить бонусы.
Для этого событию обычно присваивается уникальный идентификатор.
Получатель сохраняет обработанные event_id и при повторной доставке понимает, что событие уже выполнено.
Event ID
Event ID — уникальный идентификатор конкретного события.
Он позволяет отличить повторную доставку от нового события.
Например, два запроса имеют одинаковый event_id. Backend проверяет журнал и обнаруживает, что первый уже обработан.
После этого второй запрос можно подтвердить без повторного изменения бизнес-данных.
Webhook Retry
Если получатель недоступен или возвращает ошибку, источник может повторить отправку.
Количество попыток и интервалы зависят от конкретного сервиса.
Хорошая система обычно не выполняет бесконечные запросы каждую секунду, а увеличивает интервал между попытками.
Получатель должен учитывать, что событие может прийти с задержкой.
Exponential Backoff
Exponential Backoff — стратегия, при которой интервал между повторными попытками постепенно увеличивается.
Например, первая повторная отправка происходит через короткое время, следующая позже, а затем еще позже.
Это уменьшает дополнительную нагрузку на сервис, который уже испытывает проблемы.
Порядок Webhook-событий
Нельзя всегда исходить из того, что события поступят строго в том же порядке, в котором произошли.
Например, событие order.shipped из-за сетевой задержки теоретически может прийти позже или раньше другого уведомления, связанного с тем же заказом.
Система должна учитывать временные метки, версии состояния или получать актуальное состояние через API, если порядок критичен.
Webhook и Event-driven Architecture
Webhooks хорошо соответствуют событийной архитектуре.
Одна система сообщает, что нечто произошло, а другая решает, как на это реагировать.
Например, событие payment.succeeded может запустить создание чека, уведомление клиента и передачу заказа на склад.
При большом количестве внутренних событий вместо прямых Webhook могут использоваться Message Broker и Event Streaming.
Webhook и Message Queue
Webhook передает событие по HTTP непосредственно получателю, а Message Queue сохраняет сообщение в промежуточной очереди.
| Webhook | Message Queue |
|---|---|
| Прямой HTTP-вызов | Передача через брокер сообщений |
| Удобен между независимыми SaaS-системами | Удобна внутри распределенной архитектуры |
| Получатель должен иметь HTTP endpoint | Получатель читает сообщения из очереди |
| Повторная доставка реализуется источником | Механика доставки реализуется брокером |
Эти механизмы могут использоваться совместно. Например, Backend быстро принимает Webhook и сразу помещает событие во внутреннюю очередь.
Почему Webhook лучше обрабатывать асинхронно
Источник обычно ожидает быстрый HTTP-ответ.
Если получатель при каждом Webhook несколько секунд создает отчет, отправляет письма и вызывает сторонние сервисы, возрастает риск timeout.
Надежнее проверить запрос, сохранить событие или поместить его в очередь и быстро подтвердить прием.
Основная бизнес-обработка выполняется Background Worker.
Webhook и Background Worker
Worker может обрабатывать задачи независимо от HTTP-соединения.
Например, Webhook платежа принимается за десятки миллисекунд, помещается в очередь и получает успешный HTTP-ответ.
Затем Worker обновляет заказ, отправляет email и выполняет интеграцию с CRM.
Так сбой внешнего сервиса не заставляет источник постоянно повторять весь Webhook.
Безопасность Webhook
Webhook endpoint является внешней точкой входа в Backend. Если просто доверять любому POST-запросу, злоумышленник может попытаться отправить поддельное событие.
Поэтому необходимо подтверждать источник и целостность запроса.
- использовать HTTPS;
- проверять цифровую или HMAC-подпись;
- проверять Timestamp;
- защищаться от Replay Attack;
- не доверять только IP-адресу;
- валидировать структуру payload;
- ограничивать размер запроса;
- вести аудит критичных событий;
- не записывать секреты в логи.
Webhook Signature
Webhook Signature — подпись запроса, которая помогает подтвердить его подлинность.
Один из распространенных подходов заключается в использовании общего секретного ключа. Источник вычисляет HMAC от содержимого запроса и передает подпись в HTTP-заголовке.
Получатель самостоятельно вычисляет ожидаемую подпись и сравнивает ее с полученной.
Сам секретный ключ по сети при каждом запросе не передается.
Почему нельзя доверять только API Key в URL
Иногда защиту Webhook пытаются реализовать длинным секретным параметром непосредственно в URL.
Это лучше полностью открытого endpoint, но адрес может попасть в access logs, аналитику, историю или конфигурацию.
Для критичных интеграций предпочтительнее использовать подписанные запросы и полноценную проверку содержимого.
Replay Attack
Replay Attack — повторная отправка ранее перехваченного корректного запроса.
Даже правильная подпись не всегда защищает от повторного воспроизведения, если она остается действительной неограниченно долго.
Поэтому в подпись часто включают Timestamp, а получатель отклоняет слишком старые запросы.
Дополнительно Event ID предотвращает повторную бизнес-обработку.
Webhook и HTTPS
Webhook URL в production должен использовать HTTPS.
Шифрование защищает содержимое запроса и заголовки при передаче через сеть.
Без HTTPS злоумышленник в определенных сетевых сценариях может получить или изменить данные.
Валидация Payload
Даже после успешной проверки подписи данные необходимо валидировать.
Например, поле status должно содержать одно из разрешенных значений, идентификатор иметь ожидаемый формат, а обязательные поля присутствовать.
Не следует автоматически доверять содержимому только потому, что источник известен.
Webhook и IP Allowlist
Некоторые сервисы публикуют диапазоны IP, с которых отправляются Webhooks.
Allowlist может быть дополнительным уровнем защиты, но не всегда подходит как единственный механизм.
IP-инфраструктура может меняться, запросы могут проходить через различные сети, а адрес сам по себе не подтверждает целостность payload.
Подпись обычно дает более надежную криптографическую проверку.
Webhook Secret
Webhook Secret — секретное значение, которое знают источник и получатель.
Оно используется для формирования или проверки подписи.
Secret нельзя хранить в открытом Git-репозитории или отправлять в обычные логи.
Для него следует использовать защищенное хранилище секретов или конфигурацию среды исполнения.
Ротация Webhook Secret
Секреты периодически приходится менять, например после подозрения на утечку.
Чтобы не остановить интеграцию, удобно иметь переходный период, когда получатель способен проверить как новый, так и предыдущий ключ.
После обновления всех сторон старый секрет отключается.
Webhook и Backend
Webhook endpoint обычно реализуется на Backend.
Frontend не подходит для надежного приема серверных событий, поскольку браузер пользователя может быть закрыт и не имеет постоянного публичного адреса.
Backend принимает событие, проверяет его и выполняет бизнес-логику.
Webhook и Frontend
Frontend может косвенно использовать результат Webhook.
Например, после оплаты Backend получает уведомление от платежной системы и меняет статус заказа.
Frontend при следующем запросе получает новый статус или узнает о нем через WebSocket, Server-Sent Events или другой механизм.
Сам платежный сервис обычно не отправляет Webhook напрямую в браузер пользователя.
Webhook и REST API
REST API и Webhook часто строятся на HTTP и JSON, но направление взаимодействия отличается.
REST-клиент сам решает, когда выполнить запрос. Webhook инициирует система, в которой произошло событие.
Практически надежная интеграция нередко использует оба механизма: Webhook сообщает об изменении, а API позволяет получить актуальное полное состояние объекта.
Почему после Webhook иногда полезно запросить API
Webhook payload может содержать только идентификатор и тип события.
Получатель после проверки уведомления обращается к API источника и получает актуальное состояние объекта.
Такой подход уменьшает зависимость от структуры самого Webhook и помогает проверить текущее состояние.
Он также полезен при возможном нарушении порядка событий.
Webhook и платежные системы
Платежи — один из наиболее известных сценариев использования Webhook.
Пользователь может закрыть страницу сразу после оплаты, поэтому нельзя полагаться только на перенаправление браузера обратно в интернет-магазин.
Надежный Backend получает серверное уведомление от платежной системы и только после его проверки меняет статус заказа.
Почему Redirect не заменяет Webhook
После платежа сервис может перенаправить пользователя обратно на сайт.
Но браузер может быть закрыт, сеть потеряна или пользователь вообще не дождался redirect.
Webhook идет между серверами и не зависит от того, открыт ли браузер.
Поэтому для критичного подтверждения платежа серверное уведомление надежнее клиентского перехода.
Webhook и CRM
CRM может использовать Webhooks для интеграции с телефонией, сайтом и другими системами.
Например, после создания сделки CRM отправляет событие внешней системе аналитики.
Или сайт отправляет новую заявку в CRM через API, а CRM позже сообщает Webhook об изменении статуса.
Webhook и интернет-магазин
В электронной коммерции Webhooks связывают платежи, доставку, CRM и учетные системы.
Например, служба доставки отправляет событие shipment.delivered, после которого интернет-магазин автоматически переводит заказ в статус доставлен.
Важно, чтобы изменение статуса было идемпотентным и учитывало возможный неправильный порядок событий.
Webhook и 1С
Webhook может использоваться в интеграциях внешних сервисов с 1С, если архитектура системы предусматривает прием HTTP-запросов.
Например, внешний сервис уведомляет о новом заказе или изменении статуса платежа, после чего промежуточный Backend или интеграционный слой передает данные в учетную систему.
В критичных сценариях важно учитывать доступность 1С, очереди повторной обработки и защиту входящего HTTP endpoint.
Webhook и GitLab
Git-платформы могут отправлять Webhooks при событиях репозитория.
Например, внешняя система получает уведомление после Push, создания Merge Request или другого события проекта.
На основании такого уведомления можно запустить внутреннюю автоматизацию, обновить задачу или синхронизировать данные с другой платформой.
Webhook и CI/CD
Webhooks широко используются для запуска автоматических pipelines.
Например, после Push в Git удаленная CI-система получает событие и начинает сборку приложения.
Так автоматизация запускается непосредственно после изменения кода, а не по расписанию.
Webhook и GitOps
GitOps-система может получать уведомление об изменении Git-репозитория и быстрее инициировать проверку желаемого состояния.
При этом Git остается Source of Truth, а Webhook служит триггером для реакции на изменение.
Даже при потере уведомления GitOps-система обычно должна периодически сверять фактическое состояние с репозиторием.
Webhook и Docker
Сам Webhook не зависит от Docker, но принимающее приложение часто работает в контейнере.
Например, небольшой Backend принимает события платежной системы внутри Docker-контейнера и помещает их в очередь.
Необходимо обеспечить постоянный внешний URL через Reverse Proxy или Load Balancer.
Webhook и Kubernetes
Webhook Receiver можно запускать в Kubernetes как обычный Backend-сервис.
Несколько его реплик позволяют распределять входящие запросы.
При этом дедупликация событий не должна храниться только в памяти одного pod, иначе другая реплика не узнает, что Event ID уже обработан.
Для этого используется общая база данных или другое внешнее хранилище.
Webhook и Serverless
Serverless-функции хорошо подходят для некоторых Webhook-сценариев.
HTTP-запрос автоматически запускает функцию, которая проверяет событие и выполняет небольшую операцию или ставит сообщение в очередь.
Так не нужно постоянно держать отдельный сервер только ради нерегулярных входящих событий.
Однако необходимо учитывать ограничения времени выполнения, холодный старт и модель повторной обработки.
Webhook и Reverse Proxy
Перед Webhook Backend часто находится Nginx или другой Reverse Proxy.
Он принимает HTTPS, ограничивает размер запросов, может выполнять Rate Limiting и передает запрос приложению.
При этом криптографическую проверку подписи обычно выполняет само приложение или специализированный доверенный компонент.
Webhook и API Gateway
API Gateway может выступать внешней точкой входа для Webhooks.
Он маршрутизирует события к нужному сервису, применяет ограничения и ведет часть технического аудита.
Например, Webhooks платежного сервиса направляются в payment-handler, а события доставки — в logistics-handler.
Webhook и Rate Limiting
Rate Limiting защищает Webhook endpoint от аномально большого количества запросов.
Однако лимиты нужно настраивать осторожно: слишком жесткое ограничение может отвергать легитимный поток событий во время пиковой нагрузки.
Также необходимо учитывать повторные попытки источника.
Webhook и DDoS
Публичный Webhook URL доступен из сети и потенциально может стать целью большого количества запросов.
Защита может включать Reverse Proxy, API Gateway, Rate Limiting, сетевые фильтры и масштабирование Backend.
Проверка подписи необходима для бизнес-безопасности, но сама по себе не предотвращает расход ресурсов на входящий вредоносный трафик.
Логирование Webhook
Логирование помогает расследовать проблемы доставки.
Полезно сохранять Event ID, тип события, время получения, результат проверки подписи и статус обработки.
Не следует без необходимости записывать секретные заголовки, токены или полные персональные данные.
Для спорных бизнес-операций полезен отдельный аудит.
Webhook и Observability
При большом количестве интеграций необходимо видеть состояние Webhook-процесса.
Полезными показателями являются количество полученных событий, доля ошибок, время обработки и размер очереди.
Если источник присылает события, но Worker перестал их обрабатывать, обычная проверка HTTP endpoint может этого не заметить.
Метрики Webhook
| Метрика | Что показывает |
|---|---|
| Received Events | Количество входящих событий |
| Error Rate | Долю событий с ошибкой |
| Processing Latency | Время полной обработки |
| Duplicate Rate | Количество повторно доставленных событий |
| Queue Depth | Количество событий, ожидающих обработки |
Webhook и Prometheus
Backend может экспортировать технические показатели Webhook в Prometheus.
Например, количество обработанных payment.succeeded и количество ошибок проверки подписи.
На основании метрик создаются алерты в случае резкого роста ошибок или остановки потока событий.
Webhook и OpenTelemetry
Webhook можно включать в распределенную трассировку.
Полученный HTTP-запрос становится началом или продолжением Trace, после чего можно увидеть работу базы данных, Message Queue и зависимых сервисов.
Это особенно полезно, если одно внешнее событие запускает длинную цепочку внутренних процессов.
Webhook и SLA
Для бизнес-критичных интеграций необходимо понимать гарантии источника.
Важно знать, сколько времени он повторяет события, как долго хранит историю и можно ли вручную повторно отправить уведомление.
Если доставка критична, одной надежды на Webhook недостаточно: обычно нужен механизм сверки состояния через API или периодический reconciliation.
Reconciliation
Reconciliation — периодическая сверка фактического состояния систем.
Например, раз в несколько часов интернет-магазин запрашивает API платежной системы и проверяет, совпадают ли статусы платежей.
Если отдельный Webhook был потерян окончательно, сверка обнаружит расхождение.
Таким образом, Webhook обеспечивает быструю реакцию, а reconciliation повышает надежность интеграции.
Dead Letter Queue
Если событие не удается обработать после нескольких попыток, его полезно переместить в отдельное хранилище неуспешных сообщений.
Такое хранилище часто называют Dead Letter Queue.
Инженер может изучить причину ошибки и запустить повторную обработку после исправления проблемы.
Это особенно важно для финансовых и учетных событий, которые нельзя просто потерять.
Webhook Delivery History
Системе-источнику полезно хранить историю попыток доставки.
Разработчик может увидеть, когда был отправлен запрос, какой HTTP status вернул получатель и выполнялись ли retries.
Такой журнал значительно упрощает диагностику интеграций между независимыми компаниями.
Тестирование Webhook
Для разработки необходимо проверить не только успешный запрос, но и отказные сценарии.
- повторная доставка одного Event ID;
- неправильная подпись;
- устаревший Timestamp;
- некорректный Payload;
- недоступность базы данных;
- повторное изменение статуса;
- нарушение порядка событий;
- timeout внешнего сервиса.
Именно такие сценарии чаще всего определяют надежность production-интеграции.
Локальная разработка Webhook
Локальный компьютер разработчика обычно недоступен напрямую из интернета.
Для тестирования используются специальные туннели, тестовые окружения или возможность ручной повторной отправки события со стороны источника.
При использовании внешнего туннеля необходимо учитывать безопасность и не оставлять тестовый endpoint доступным дольше необходимого.
Webhook и тестовое окружение
Платежные и другие внешние сервисы часто предоставляют Sandbox или тестовый режим.
Он позволяет генерировать события без реальных финансовых операций.
Webhook test и production должны иметь отдельные настройки и секреты, чтобы тестовые события случайно не изменяли реальные бизнес-данные.
Типичные ошибки при работе с Webhook
- Не проверять подпись события.
- Считать, что Webhook приходит только один раз.
- Выполнять всю тяжелую обработку внутри HTTP-запроса.
- Не использовать Event ID.
- Не учитывать изменение порядка событий.
- Хранить Webhook Secret в Git.
- Отвечать успехом до сохранения события без надежного механизма обработки.
- Не вести журнал ошибок.
- Не иметь механизма повторной обработки.
- Полагаться только на Webhook для критичной финансовой сверки.
Как спроектировать надежный Webhook Receiver
Шаг 1. Использовать HTTPS
Весь трафик должен передаваться через защищенное соединение.
Шаг 2. Проверять подпись
До изменения бизнес-данных необходимо подтвердить подлинность события.
Шаг 3. Проверять Event ID
Повторная доставка не должна повторно выполнять критичную операцию.
Шаг 4. Быстро сохранять событие
Полезно сначала надежно зафиксировать запрос или поставить его в очередь.
Шаг 5. Обрабатывать асинхронно
Тяжелые действия выполняются Worker после подтверждения приема.
Шаг 6. Сделать обработчик идемпотентным
Повторная попытка должна приводить к тому же итоговому состоянию.
Шаг 7. Добавить Observability
Необходимо видеть ошибки, retries, очередь и время обработки.
Шаг 8. Создать процедуру reconciliation
Для критичных данных следует периодически сверяться с системой-источником.
Практический пример
Интернет-магазин принимает оплату через внешний платежный сервис.
После создания платежа покупатель переходит на страницу банка. Магазин не считает заказ оплаченным только потому, что браузер пользователя вернулся на страницу успешной оплаты.
Платежная система отправляет серверный Webhook payment.succeeded. Backend магазина проверяет HTTPS-запрос и HMAC-подпись.
Затем он проверяет Event ID. Если событие новое, оно сохраняется в базе и помещается в очередь. Backend сразу возвращает успешный HTTP status.
Worker получает событие, запрашивает актуальное состояние платежа через API и переводит заказ в статус Оплачен.
Далее другие фоновые задачи отправляют письмо покупателю и передают заказ на склад.
Если платежная система повторно отправит тот же Webhook, Event ID не позволит выполнить бизнес-операцию второй раз.
Раз в сутки отдельная задача сверяет статусы платежей через API и обнаруживает возможные пропущенные события.
Webhook для бизнеса
Webhooks позволяют исключить множество ручных проверок и ускорить обмен данными между системами.
Заказ может автоматически перейти в обработку после оплаты, CRM — получить изменение статуса, а склад — начать комплектацию.
Для бизнеса это означает сокращение задержек и ручных операций.
Но критичные процессы требуют надежной архитектуры: проверка подписи, идемпотентность, очередь, retries и контроль расхождений должны проектироваться заранее.
Когда нужен Webhook
- система должна быстро реагировать на внешнее событие;
- постоянный Polling создает лишнюю нагрузку;
- нужно получать статусы платежей;
- есть интеграция с CRM или службой доставки;
- необходимо запускать автоматизацию после события;
- используются Git и CI/CD;
- внешняя система поддерживает callback уведомления;
- важно уменьшить задержку между событием и реакцией.
Когда Webhook может быть недостаточно
Webhook не является гарантией идеальной доставки.
Если бизнес не может позволить потерять ни одного события, необходимо дополнять механизм очередями, историей доставки и периодической сверкой через API.
Для очень большого внутреннего потока событий также могут лучше подходить Message Broker или Event Streaming платформы.
Связанные термины
| Термин | Связь с Webhook |
|---|---|
| API | Часто используется вместе с Webhook для получения актуального состояния |
| REST API | Распространенный HTTP-интерфейс интеграций |
| HTTP | Протокол, через который обычно отправляются Webhooks |
| Polling | Альтернативный способ проверки изменений |
| Event-driven Architecture | Архитектурный подход, основанный на реакции на события |
| Message Queue | Используется для надежной внутренней обработки полученных событий |
| Idempotency | Предотвращает нежелательный результат повторной доставки |
| HMAC | Может использоваться для проверки подписи Webhook |
| GitLab | Может отправлять Webhooks по событиям репозитория |
| CI/CD | Может запускаться после получения Webhook |
| Backend | Обычно принимает и обрабатывает Webhook-запросы |
| Observability | Помогает отслеживать доставку и обработку событий |
Краткий итог
Webhook — механизм автоматической отправки HTTP-запроса одной системой другой при наступлении события. Он позволяет быстро реагировать на оплату, изменение заказа, действия в Git, события CRM и другие изменения без постоянного Polling.
Надежный Webhook Receiver должен использовать HTTPS, проверять подпись, валидировать Payload и быть готовым к повторной доставке. Для критичных операций особенно важны Event ID и идемпотентность.
Тяжелую обработку желательно выполнять асинхронно через Message Queue и Background Worker. Для финансовых и других критичных данных Webhook полезно дополнять периодической сверкой через API, поскольку сетевые уведомления нельзя считать абсолютной гарантией однократной и строго упорядоченной доставки.
