Webhook — механизм автоматической отправки HTTP-запроса на указанный URL при наступлении события, обеспечивающий real-time интеграцию между системами без необходимости постоянного опроса.
Webhook (вебхук) — это механизм межсерверного взаимодействия, при котором одна система автоматически отправляет HTTP POST-запрос на заранее указанный URL другой системы при наступлении определённого события. В отличие от API-опроса (polling), когда клиент периодически запрашивает сервер «есть ли новые данные?», webhook работает по принципу push — сервер сам уведомляет клиента в момент события.
Аналогия из повседневной жизни: polling — это когда вы каждые 5 минут проверяете почтовый ящик, а webhook — когда почтальон звонит в дверь при доставке. Webhook экономит ресурсы обеих сторон и обеспечивает минимальную задержку между событием и реакцией на него.
В маркетинговой автоматизации webhook используется в двух направлениях. Входящие webhooks (inbound) позволяют платформе получать данные от внешних сервисов: статусы доставки от провайдеров рассылок, callback от платёжных систем, уведомления от мессенджеров. Исходящие webhooks (outbound) отправляют данные о событиях платформы во внешние системы: CRM получает уведомление об открытии письма, аналитическая система — о конверсии, Slack — алерт о массовых отписках. Двунаправленная поддержка webhooks делает маркетинговую платформу центральным узлом в экосистеме бизнес-инструментов.
Webhooks обеспечивают мгновенную синхронизацию данных между маркетинговой платформой и другими бизнес-системами. Без webhooks интеграции работают с задержкой (от минут до часов), что критично для триггерного маркетинга, где каждая минута промедления снижает конверсию.
Конкретные бизнес-сценарии: мгновенное обновление CRM при взаимодействии клиента с email-рассылкой (открытие, клик, отписка); автоматическое оповещение отдела продаж в Slack, когда «горячий» лид кликнул по ссылке на тарифы; синхронизация статусов доставки SMS и email для корректного fallback на альтернативный канал; отправка данных о конверсиях в рекламные системы для оптимизации таргетинга.
По опросам MuleSoft, компании в среднем используют 976 отдельных приложений, и 70% IT-бюджета тратится на интеграцию между ними. Webhooks снижают стоимость интеграции на 60-80% по сравнению с разработкой custom API-коннекторов. Время внедрения webhook-интеграции — часы вместо недель для API-коннектора.
Техническая реализация webhook состоит из нескольких компонентов. Подписка — вы регистрируете URL своего сервера и указываете, какие события хотите получать (email.sent, email.opened, email.clicked, campaign.completed). Доставка — при наступлении события система формирует JSON-payload с данными события и отправляет POST-запрос на зарегистрированный URL.
Безопасность — критически важный аспект webhook. Без проверки подлинности злоумышленник может подделать запрос и отправить ложные данные на ваш endpoint. Стандартный метод защиты — подпись HMAC: при создании webhook генерируется секретный ключ (secret), каждый исходящий запрос подписывается с помощью HMAC-SHA256 от тела запроса и secret, подпись помещается в заголовок. Получатель пересчитывает подпись и сверяет — если не совпадает, запрос отклоняется.
Надёжность обеспечивается через retry-механизм. Если целевой сервер не ответил кодом 2xx, система повторяет попытку с экспоненциальным интервалом: через 1 минуту, 5 минут, 30 минут. После нескольких неудачных попыток webhook помечается как неработающий, а администратор получает уведомление. Failure counter отслеживает стабильность каждого endpoint.
Маркетплейс настроил исходящий webhook для синхронизации с Битрикс24: при каждом клике по ссылке в email (событие email.clicked) данные о клиенте и кампании отправлялись в CRM. Менеджеры по продажам видели в карточке клиента, какие именно товары его интересовали, и звонили в течение 15 минут. Конверсия из лида в сделку выросла с 4% до 11%.
Онлайн-школа использовала входящий webhook от Telegram: при нажатии кнопки «Записаться на пробный урок» в Telegram-боте webhook передавал данные в CDP-платформу, которая мгновенно запускала welcome-серию из 3 писем + SMS с ссылкой на занятие. Без webhook задержка составляла бы до часа (при polling), а с webhook — менее 2 секунд. Показываемость на пробных уроках выросла с 45% до 68%.
Сервис доставки еды настроил webhook на событие email.bounced (недоставленное письмо). При hard bounce email автоматически добавлялся в suppression list, а клиент переключался на SMS и push-уведомления. Это сократило бесполезные отправки на 8% и улучшило deliverability с 94% до 98.5%.
Trigly поддерживает полноценную двунаправленную webhook-архитектуру. Исходящие webhooks реализованы через модель CampaignWebhook и WebhookNotificationService. Каждый webhook содержит: URL-endpoint, список отслеживаемых event_types (JSONB), secret для HMAC-SHA256 подписи, is_active, failure_count. Исходящие запросы подписываются HMAC-SHA256 — получатель может проверить подлинность каждого вызова. При неудаче система выполняет до 3 повторных попыток.
API исходящих webhooks предоставляет 5 эндпоинтов: создание, получение, обновление, удаление и листинг. Webhook можно привязать к конкретной кампании (campaign_id FK) или сделать глобальным (campaign_id = null) для получения событий от всех кампаний.
Входящие webhooks реализованы через provider_webhooks.py с 4 публичными эндпоинтами. POST /hooks/email/unisender обрабатывает callback от Unisender (bounce, complaint, unsubscribe) и автоматически добавляет запись в SuppressionEntry. POST /hooks/email/bounce — универсальный обработчик bounce (hard_bounce добавляет в suppression, spam ставит unsubscribe). POST /hooks/telegram/{org_id} обрабатывает обновления Telegram Bot API: команда /start с deep link привязывает chat_id к клиенту, callback_query записывает событие в ClickHouse. POST /hooks/sms/status обрабатывает статусы доставки SMS.ru (103=delivered, 104/105=failed с retry).
Все входящие webhooks доступны без JWT-авторизации (публичные пути в middleware) и защищены на уровне провайдера.
API — это запрос по инициативе клиента: «Дай мне данные». Webhook — уведомление по инициативе сервера: «У меня произошло событие, вот данные». API подходит для запроса данных по требованию, webhook — для real-time уведомлений. В Trigly используются оба подхода: API для управления (290+ эндпоинтов), webhooks для интеграций и событий.
Три уровня защиты: 1) Проверка HMAC-SHA256 подписи (Trigly автоматически подписывает все исходящие вызовы). 2) Whitelist IP-адресов сервера-отправителя. 3) HTTPS — никогда не используйте HTTP для webhook, данные передаются в открытом виде. Trigly отправляет подпись в заголовке X-Trigly-Signature, формула: HMAC-SHA256(request_body, secret).
Проверьте: 1) Доступен ли ваш URL извне (не закрыт файрволом). 2) Отвечает ли endpoint кодом 200 в течение 10 секунд. 3) Не превышен ли failure_count (Trigly деактивирует webhook после серии неудач). Trigly реализует exponential backoff retry — 3 попытки с увеличивающимися интервалами. В логах webhook видны все попытки и ошибки.
AI-платформа автоматизации маркетинга с лучшими инструментами