Двусторонние webhook-интеграции для связи Trigly с внешними системами: исходящие вебхуки с HMAC-SHA256 подписью и 3 повторными попытками, входящие вебхуки от провайдеров каналов.
Маркетинговая платформа не работает в вакууме. Она должна обмениваться данными с CRM, аналитическими системами, складскими программами, платёжными системами и десятками других сервисов. Традиционный подход -- периодический опрос API (polling) -- неэффективен: создаёт лишнюю нагрузку, вносит задержки и пропускает события.
Вебхуки решают эту проблему: система немедленно уведомляет внешний сервис о событии (отправка, доставка, отписка) через HTTP-запрос. Однако реализация вебхуков требует решения множества инженерных задач: гарантия доставки при сбоях, безопасность (как убедиться, что запрос действительно от Trigly), обработка ответов, управление failure count. Без надёжной системы вебхуков интеграция превращается в хрупкую конструкцию из cron-задач и CSV-экспортов.
С другой стороны, каналы доставки (Unisender, Telegram, SMS.ru) отправляют callback-уведомления о статусе сообщений -- bounce, delivery, read. Без обработки этих входящих вебхуков платформа не знает, доставлено ли сообщение, и не может реагировать на проблемы.
Trigly реализует полноценную двустороннюю систему вебхуков: исходящие (outgoing) для уведомления внешних систем и входящие (incoming) для приёма callback-ов от провайдеров.
Исходящие вебхуки управляются через модель CampaignWebhook. Каждый вебхук имеет: url (адрес получателя), event_types (JSONB-массив типов событий, на которые подписан вебхук), secret (ключ для HMAC-подписи), is_active (флаг активности) и failure_count (счётчик неудачных попыток).
WebhookNotificationService отвечает за отправку уведомлений. При наступлении события (отправка сообщения, доставка, открытие, клик, отписка) сервис находит все активные вебхуки, подписанные на этот тип события, и отправляет HTTP POST запрос на каждый URL.
HMAC-SHA256 подпись гарантирует аутентичность запроса. Каждый исходящий запрос подписывается: тело запроса хешируется с использованием secret вебхука через алгоритм HMAC-SHA256. Подпись передаётся в заголовке X-Signature. Получатель может верифицировать подпись, вычислив HMAC от полученного тела с использованием того же secret, и сравнив результат с заголовком. Это криптографически доказывает, что запрос отправлен именно Trigly и не был модифицирован.
3 повторные попытки с экспоненциальной задержкой: если получатель не ответил 200 OK, WebhookNotificationService повторяет попытку. Первый retry через несколько секунд, второй через более длительный интервал, третий -- ещё позже. Экспоненциальная задержка (exponential backoff) даёт получателю время на восстановление. Если все 3 попытки неудачны, failure_count инкрементируется. При достижении критического количества неудач вебхук может быть деактивирован.
Входящие вебхуки от провайдеров обрабатываются через 4 публичных эндпоинта в provider_webhooks.py:
POST /hooks/email/unisender -- принимает callback-уведомления от Unisender о событиях email-доставки. Обрабатывает bounce (жёсткий отказ), complaint (жалоба на спам) и unsubscribe. При hard bounce автоматически создаётся SuppressionEntry, исключающая адрес из будущих рассылок. При spam complaint клиент автоматически отписывается.
POST /hooks/email/bounce -- универсальный обработчик отказов, не привязанный к конкретному провайдеру. Hard bounce создаёт запись в suppression-списке. Spam complaint вызывает автоматическую отписку клиента (is_unsubscribed = true).
POST /hooks/telegram/{org_id} -- принимает обновления от Telegram Bot API. Обрабатывает три типа событий: команда /start с deep link (привязка telegram_chat_id к профилю клиента через TelegramLinkService), callback_query от inline-кнопок (логируется в ClickHouse, вызывается answerCallbackQuery), текстовые сообщения (логируются в ClickHouse для timeline).
POST /hooks/sms/status -- принимает callback-уведомления от SMS.ru о статусе доставки. Код 103 -- доставлено, коды 104/105 -- ошибка доставки (инициируется повторная попытка).
API для управления: 5 эндпоинтов в webhooks.py обеспечивают полный CRUD для вебхуков: создание, получение списка, получение по ID, обновление, удаление.
Безопасность по умолчанию: HMAC-SHA256 подпись каждого исходящего запроса исключает подделку. Получатель математически верифицирует источник запроса без передачи секретов по сети.
Гарантированная доставка: 3 повторные попытки с экспоненциальной задержкой обеспечивают доставку даже при временных сбоях получателя. Мониторинг failure_count позволяет вовремя обнаружить системные проблемы.
Автоматическая реакция на проблемы: входящие вебхуки от провайдеров автоматически обрабатывают bounce, spam complaints и unsubscribe. Suppression-список обновляется без участия маркетолога, защищая репутацию домена.
Гибкая подписка на события: JSONB-массив event_types позволяет каждому вебхуку подписаться только на нужные типы событий. CRM получает уведомления об отписках, аналитика -- о доставках, склад -- о покупках.
Привязка Telegram через deep links: вебхук /hooks/telegram/{org_id} автоматически связывает Telegram-аккаунт с профилем клиента через HMAC-подписанные deep links. TelegramLinkService обеспечивает безопасную привязку с 24-часовым сроком действия ссылки.
Большинство маркетинговых платформ предлагают только исходящие вебхуки без HMAC-подписи. Trigly подписывает каждый запрос HMAC-SHA256, что соответствует стандартам безопасности финтех-индустрии.
В отличие от Mailchimp и SendPulse, где входящие вебхуки ограничены email-каналом, Trigly обрабатывает callback-уведомления от Email, Telegram, SMS и WhatsApp провайдеров в единой системе. Автоматическое создание SuppressionEntry при hard bounce -- функция, которую конкуренты часто оставляют на ручную настройку. 3 retry с exponential backoff -- промышленный стандарт, который реализуют не все платформы.
E-commerce + CRM: Интернет-магазин настроил исходящий вебхук на event_type "message.clicked" для уведомления CRM о кликах по продуктовым ссылкам. CRM автоматически создаёт сделку, когда клиент кликает на товар в рассылке. HMAC-подпись гарантирует, что CRM принимает только верифицированные данные от Trigly. Конверсия из клика в сделку отслеживается в обеих системах.
Финансовые услуги: Банк использует входящие вебхуки для мониторинга доставки критичных уведомлений. Bounce-вебхук немедленно уведомляет отдел комплаенса о невозможности доставки уведомления клиенту. Исходящий вебхук отправляет данные о доставке в систему аудита для соответствия требованиям регулятора. 3 retry гарантируют доставку даже при сбоях аудит-системы.
Маркетплейс с мульти-вендорами: Маркетплейс использует вебхуки для уведомления продавцов о действиях покупателей. Каждый продавец имеет свой вебхук с уникальным secret. Event_types настроены индивидуально: один продавец получает уведомления об открытиях, другой -- о кликах и покупках. HMAC-подпись позволяет продавцам автоматически обрабатывать данные без риска подделки.
Webhook-система Trigly связывает платформу с любыми внешними сервисами через HTTP. Исходящие вебхуки интегрируются с CRM (amoCRM, Bitrix24, RetailCRM), аналитическими системами (Google Analytics, Яндекс.Метрика через Measurement Protocol), складскими системами (1С, МойСклад), платёжными шлюзами. Входящие вебхуки принимают callback-уведомления от Unisender, Telegram Bot API, SMS.ru и WhatsApp Cloud API. REST API предоставляет CRUD для управления вебхуками. ClickHouse хранит историю всех webhook-событий для аналитики и аудита.
Как верифицировать HMAC-подпись на стороне получателя?
Получатель вычисляет HMAC-SHA256 от тела запроса (body) с использованием secret, указанного при создании вебхука, и сравнивает результат с заголовком X-Signature. В Python: hmac.new(secret.encode(), body, hashlib.sha256).hexdigest(). Если подписи совпадают -- запрос аутентичен.
Что происходит, если все 3 retry неуспешны? Failure_count вебхука инкрементируется. Событие не повторяется далее, но логируется для анализа. Маркетолог может проверить failure_count в интерфейсе и диагностировать проблему (неверный URL, сервер получателя не отвечает, firewall блокирует запросы).
Можно ли получать вебхуки от внешних систем в Trigly? Да, через CampaignTrigger и TriggerEngine. Вы можете настроить триггер, который реагирует на входящий HTTP-запрос и запускает кампанию или flow. Это позволяет, например, отправить приветственное сообщение при создании пользователя в вашей системе.
Верифицируйте HMAC-подпись на стороне получателя. Не принимайте вебхуки от Trigly без проверки подписи. Это защищает от подделки запросов и гарантирует целостность данных. Реализация проверки занимает 5 строк кода на любом языке.
Обрабатывайте вебхуки идемпотентно. Trigly может отправить один и тот же вебхук повторно (при retry). Ваш обработчик должен корректно обрабатывать дубликаты: проверяйте уникальность события по ID перед обработкой.
Отвечайте 200 OK быстро. Если обработка вебхука занимает более 5 секунд, ответьте 200 OK сразу и обработайте данные асинхронно. Иначе Trigly будет повторять попытку, считая отправку неудачной.
Мониторьте failure_count. Регулярно проверяйте счётчик неудачных попыток для каждого вебхука. Рост failure_count сигнализирует о проблемах на стороне получателя: недоступный URL, ошибки обработки, firewall.
Открытый вебхук-эндпоинт без проверки подписи. Без верификации HMAC-SHA256 злоумышленник может отправить поддельные данные на ваш обработчик, например, симулировать отписку клиента или изменить статус заказа.
Игнорирование входящих вебхуков от провайдеров. Без обработки bounce и spam complaints от Unisender и SMS.ru платформа продолжает отправлять на невалидные адреса, портя репутацию домена. Убедитесь, что все провайдерские вебхуки настроены при подключении канала.
Слишком много типов событий в одном вебхуке. Если один вебхук подписан на все типы событий, получатель обрабатывает огромный поток данных. Создавайте отдельные вебхуки для разных систем: CRM — отписки и конверсии, аналитика — все доставки, склад — покупки.
Байесовское A/B тестирование с Monte Carlo симуляцией. Автовыбор победителя, калькулятор выборки, мультивариантные тесты.
Генерация email subject lines, тела писем, SMS, push-текстов с помощью AI. GPT-4 и Claude, оптимизированные для маркетинга на русском языке.
Полноценная REST API платформа с 290 эндпоинтами, JWT-аутентификацией, Redis rate limiting, SDK для фронтенда и публичными эндпоинтами для трекинга и интеграций.
Визуальный конструктор автоматических цепочек: email, SMS, Telegram, WhatsApp, push. DAG-executor, условия, ожидание, smart send.
Бесплатная интеграция. Все функции доступны с первого дня. Гарантия окупаемости.
Записаться на аудит