Многие сервисы рассылки email-сообщений предлагают инструменты автоматизации – триггеры и email-API (как улучшенная версия SMTP). Для многих задач этого функционала действительно хватает. Но иногда возникают более сложные задачи, когда нужно обеспечить максимально продвинутый обмен данными между разными web-приложениями или между разными облачными сервисами. Как раз тут на помощь приходят вебхуки (webhooks).

Ниже наш материал, расставляющий все точки над i. Расскажем о том, что такое Webhook’и и как их применять в email-рассылках для повышения эффективности. Начнём с определений.

Что такое Webhook простыми словами

Webhooks – дословно «веб-перехватчик». Слово hook переводится как «крючок», «ловушка» или «захватка».

Система вебхуков – это модель автоматического обмена данными по http(https)-протоколу, реализованная с помощью web-обработчиков. Здесь есть источники оповещений, отправляющие набор данных при возникновении определённых событий, и web-перехватчики, которые отвечают за принятие этих данных на стороне внешнего сервера и последующую обработку.

Такая система во многом похожа на взаимодействие двух разных web-сервисов по API-интерфейсу (в некоторых документах webhooks даже называют «обратным API»), но фактически это разные подходы.

Чтобы обмениваться данными по API, системы реализуют модель опроса внешнего сервера, это происходит циклически (то есть непрерывно). Если сервер отвечает о готовности, начинается процедура отправки/обмена. API обычно имеют двунаправленный характер – «ты мне, я тебе».

Webhook’и просто отправляются на внешний сервер без каких-либо циклических опросов. Инициатором отправки всегда выступает определённое событие – триггер. Соответственно, отправка данных фактически выполняется только однократно – при срабатывании триггера.

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

Итак, Webhooks – это такая система автоматических однонаправленных уведомлений, в рамках которой разные web-приложения или сервисы обмениваются данными между собой по интернету.

Это как сообщения в чатах или мессенджерах, но только их отправляют и принимают веб-сервисы, а внутри важная техническая информация.

Для чего могут использоваться вебхуки

Исходя из вышесказанного, получается, что webhooks удобно использовать для того, чтобы:

  • Отправлять уведомления о наступлении важных событий внутри определённого онлайн-сервиса: поступление новых заказов, появление новых сообщений, срабатывание иных триггеров.
  • Добавлять новые контакты и данные из внешних сервисов – при их появлении.
  • Обновлять, изменять и удалять данные в базах – цены, остатки и т.п.

Web-хуки часто применяются в CRM и CMS-системах, в системах сквозной аналитики, а также в сервисах push, SMS и email-рассылок (ESP-сервисах).

Применение вебхуков в email-рассылках

В email-рассылках вебхуки применяются для:

  • Оповещения внешних систем об изменении статуса письма в триггерной рассылке (доставлено оно или нет, открыто или нет, перешёл ли пользователь по ссылке и по какой).
  • Оповещения об изменении статуса контакта, а также об изменении/появлении данных в определённых полях (отписался, подписался, проявил активность, было заполнено поле с датой рождения, с именем и т.п.).
  • Уведомления об изменении статуса общей рассылки (в процессе, закончена, отклонена и пр.).
  • Уведомления о наличии ошибок или проблем (отписки, жалобы на спам, проблемы доставки и т.д.).

Почти всегда webhooks в email-рассылках соотносятся с системой внутренних триггеров. Соответственно, с их помощью можно значительно расширить возможности автоматических рассылок.

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

Эффективность продаж может вырасти в разы.

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

Самый простой и востребованный функционал – встраивание статусов рассылок в свои бизнес-процессы. Для этого платформа email-рассылок может оперативно уведомлять внешний веб-сервис об актуальных статусах запущенных кампаний. И делать это логичнее всего по системе веб-хуков – через POST-запросы посредством HTTP-протокола.

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

Как подключить /настроить webhook для отправки уведомлений

Так как список обработчиков хуков у каждого сервиса рассылки свой, то и функционал триггеров у каждой платформы будет отличаться.

Точно также будут различаться API-интерфейсы и методы вызова хуков.

Чтобы настроить отправку данных по тому или иному событию, нужно обратиться к документации сервиса.

Единственный плюс – все вебхуки передаются в POST-запросах и используют один и тот же формат (JSON).

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

Для защиты данных могут применяться специальные ключи (как с API), которые одновременно обеспечивают идентификацию клиента и отсекают все нелегитимные запросы (если внешний сервис не может предъявить ключ, то его запросы просто игнорируются).

Алгоритм создания и настройки нового вебхука выглядит примерно так:

  • Внутри основного сервиса, выступающего в роли источника данных, например, в сервисе email-рассылок, создаётся новый хук. Для этого нужно задать его название и определить тип сообщения (если есть разделение по форматам). В отдельных сервисах может потребоваться использование/генерация API-ключей для защиты.
  • Для хука задаётся адрес принимающего сервиса. Это может быть URL с доменом, а может быть конкретный IP-адрес, включающий номер вызываемого порта (порты указываются после двоеточия).
  • На принимающем сервере (сервисе), например, в CRM-системе, настраиваются web-перехватчик. Он будет отвечать за приём и распарсивание данных из JSON-структуры. Данные, принятые в POST-запросе, могут вноситься в единую базу, на их основе могут работать различные триггеры и т.п.

Создание Webhook в сервисе рассылок RuSender

В новой версии панели управления перейдите в раздел «Интеграции» –> «Webhooks» –> кнопка «Создать webhook».

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

В качестве событий могут выступать (это и есть ваши триггеры/хуки) следующие статусы рассылок:

  • .moderating – на модерации.
  • .approved – одобрена.
  • .rejected – отклонена.
  • .started – запущена.
  • .completed – завершена.
  • .banned – остановлена системно.

Для статуса «banned» структура payload вебхука будет иметь расширенный формат, с дополнительным указанием причин через поля reason и explanation (с полноценным описанием). Например:

  • hard_bounced – «жёсткий» возврат, из-за большого количества ошибок с кодом, начинающимся на цифру 5, со стороны принимающих почтовых серверов. К таким ошибкам относятся «постоянные» проблемы: несуществующие адреса, сервер не принимает почту, превышен лимит хранилища, нет службы SMTP и т.п.
  • soft_bounced – «мягкий» возврат из-за большого количества ошибок с кодом, начинающимся на цифру 4. К таким ошибкам относятся «временные» проблемы: почтовый ящик сейчас занят, сервер пока не может обработать параметры и т.п.
  • error_spam – возврат из-за срабатывания спам-политик.
  • complain – возврат из-за большого количества жалоб.

Статусы добавляются к сущности, в нашем случае к «рассылкам» – mail_distribution.

Читайте также: Основные причины попадания писем в спам.

Общий формат вебхука будет выглядеть так:

{
  "eventId": "<uuid>",
  "trigger": "<entity>.<event>",
  "occurredAt": "2023-10-27T12:35:01.123Z",
  "payload": {
    "someStringField": "string",
    "numberField": 42
  }
}
Более предметный пример с отправкой веб-хука о наличии жёсткой остановки:
{
  "eventId": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "trigger": " mail_distribution.banned",
  "occurredAt": "2030-12-31T20:59:59.999Z",
  "payload": {
    "mailDistributionId": 12345,
    "mailDistributionName": "Название рассылки",
    "mailDistributionSubject": "Тема письма",
    "negative": {
        "reason": "hard_bounced",
        "explanation": "Подробное описание причины жёсткой блокировки"
    },
  }

На принимающей стороне, например, на сайте или в CRM-системе, должен реализовываться приём и обработка webhook’а. Тело JSON-ответа должно распарсиваться, а важные данные должны передаваться для дальнейшей работы. Например, CMS-система сайта может инициировать оповещения в Telegram.

Вместо собственных обработчиков можно задействовать обработчики, встроенные в сервисы-коннекторы: Albato, Zapier, ApiX-Drive, IFTTT и пр.

На примере платформы-коннектора Albato:

  1. Нужно создать триггер, запускающий связку. В качестве триггера указывается входящий webhook-запрос.
  2. Для вебхука создаётся и настраивается новое подключение – определяется список возможных параметров и заголовков.
  3. Сервис Albato сгенерирует специальный URL-адрес, на который нужно будет направлять оповещения из хуков. Он будет иметь примерно такой вид – «https://h.albato.com/wh/38/1lft5ig/bL8jY64RyATU3H_tsu-xxСЛОЖНЫЙ_ИДЕНТИФИКАТОР/».
  4. Далее настраивается web-хук в сервисе рассылки (в него вписывается принимающий URL-адрес).
  5. После отправки нескольких тестовых запросов сервис Albato автоматически обнаружит имеющиеся поля вебхука.
  6. Останется только настроить дальнейшую логику обработки данных из этих полей. Например, можно обновить статус сделки в CRM или добавить новую задачу для исполнителя в PBM-системе, отправить оповещение в любимый мессенджер и т.п.

Если принимающий сервер не обработает хук в течение 30 секунд (для этого он должен вернуть HTTP-статус с кодом 200-299), система будет осуществлять ещё до 6 попыток отправки с нарастающими интервалами задержки – от 1 до 15 минут.

Документация по работе с вебхуками RuSender.

Заключение

Вебхуки – это реально полезный инструмент для быстрой и беспроблемной автоматизации типовых задач, в том числе для сбора технических уведомлений с сервисов рассылки email-сообщений.

Однако, стоит помнить, что webhook’и рассчитаны исключительно на продвинутых пользователей и программистов (web-разработчиков). Одно дело настроить отправку стандартных данных в POST-запросе, это делается в несколько кликов. А другое – организовать их приём и обработку на своём сервере. Готовые стандартные решения представлены пока только на базе no-code платформ, таких как, Albato (работает в РФ) или Zapier (не работает в РФ).

Даже с платформами-коннекторами нужно будет правильно настроить обработку полей и все последующие действия. Всё это повышает порог вхождения для начинающих email-маркетологов.

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

Читайте также: Как грамотно использовать триггерные рассылки.

Дата публикации Дата публикации: 20 сентября 2023 Обновлено: 14 ноября 2025

Автор статьи

Дарья Л.

Написано статей: 115

Контент-менеджер и email маркетолог в RuSender.

Поделиться статьёй