Разбираемся с webhooks
Во всех проектах с интеграциями обычно возникает вопрос «как передавать события между сервисами». И сегодня хотела бы поговорить о таком способе, как webhooks.
Webhooks – это механизм, при котором система сама отправляет событие другой системе, когда что-то произошло.
То есть вместо постоянного вопроса «есть ли новые данные?» (polling) система сама уведомляет о событии.
Рассмотрим на примере:
1. В системе происходит событие
Например: пользователь оплатил заказ.
2. Система формирует HTTP-запрос
Обычно это POST-запрос на заранее настроенный URL.
3. Отправляет данные получателю
В запросе передается payload с информацией о событии.
Когда используют webhooks, а не polling?
На моём опыте чаще всего webhooks используются в следующих случаях:
◾️платежные системы уведомляют о результате операции
◾️CRM отправляет события о новых клиентах
◾️сервисы доставки сообщают о смене статусов заказов
◾️Git-сервисы запускают CI/CD при новом коммите
Главная идея – система отправляет событие сразу после его возникновения.
И чтобы интеграция работала стабильно, важно правильно разделить ответственность между СА и разработчиком и не лезть туда, куда не надо))
⏺Аналитик отвечает за логику интеграции и требования.
Фиксируем:
— какие события отправляются
— при каких условиях они возникают
— какие данные входят в payload
— формат запроса
— примеры сообщений
— ожидаемые ответы принимающей системы
— сценарии ошибок
— правила retry и повторной отправки
Также аналитик описывает контракт интеграции между системами.
⏺А вот разработчик отвечает за техническую реализацию:
— создание endpoint для приёма webhook
— отправку HTTP-запросов
— обработку ответов
— реализацию retry-механизмов
— обработку дублей событий
— логирование и мониторинг
Проще говоря:
аналитик отвечает за что и когда отправляется,
разработчик – за как это работает технически.
На практике это разделение сильно упрощает работу команды: когда контракт интеграции описан заранее, разработчикам проще реализовать и протестировать взаимодействие систем.
Во всех проектах с интеграциями обычно возникает вопрос «как передавать события между сервисами». И сегодня хотела бы поговорить о таком способе, как webhooks.
Webhooks – это механизм, при котором система сама отправляет событие другой системе, когда что-то произошло.
То есть вместо постоянного вопроса «есть ли новые данные?» (polling) система сама уведомляет о событии.
Рассмотрим на примере:
1. В системе происходит событие
Например: пользователь оплатил заказ.
2. Система формирует HTTP-запрос
Обычно это POST-запрос на заранее настроенный URL.
3. Отправляет данные получателю
В запросе передается payload с информацией о событии.
Я обычно сразу добавляю пример payload в требования:
event: payment_success
order_id: 8421
amount: 2500
timestamp: 2026-03-13
Так команде сразу понятно, какие данные придут во внешнюю систему.
Когда используют webhooks, а не polling?
На моём опыте чаще всего webhooks используются в следующих случаях:
◾️платежные системы уведомляют о результате операции
◾️CRM отправляет события о новых клиентах
◾️сервисы доставки сообщают о смене статусов заказов
◾️Git-сервисы запускают CI/CD при новом коммите
Главная идея – система отправляет событие сразу после его возникновения.
И чтобы интеграция работала стабильно, важно правильно разделить ответственность между СА и разработчиком и не лезть туда, куда не надо))
⏺Аналитик отвечает за логику интеграции и требования.
Фиксируем:
— какие события отправляются
— при каких условиях они возникают
— какие данные входят в payload
— формат запроса
— примеры сообщений
— ожидаемые ответы принимающей системы
— сценарии ошибок
— правила retry и повторной отправки
Также аналитик описывает контракт интеграции между системами.
⏺А вот разработчик отвечает за техническую реализацию:
— создание endpoint для приёма webhook
— отправку HTTP-запросов
— обработку ответов
— реализацию retry-механизмов
— обработку дублей событий
— логирование и мониторинг
Проще говоря:
аналитик отвечает за что и когда отправляется,
разработчик – за как это работает технически.
На практике это разделение сильно упрощает работу команды: когда контракт интеграции описан заранее, разработчикам проще реализовать и протестировать взаимодействие систем.