Перейти к основному содержанию
webhook оповещений отправляют оповещения вашей команды на HTTPS endpoint, которым вы управляете. Используйте их, чтобы передавать оповещения в инструмент для дежурных, очередь тикетов или собственную панель операций. webhook оповещений отделены от webhook верификации. webhook верификации передают в ваше приложение результаты сессий, сущностей и транзакций. webhook оповещений сообщают вашей команде, что требуется внимание: верификация ждёт проверки, платёж не прошёл или возник сбой сервиса. У них есть собственный payload, секрет для подписи, подпись и расписание повторных попыток.

Настройка адреса назначения

webhook оповещений настраиваются в Business Console, а не через API. Участники, которые могут управлять настройками организации, могут добавлять, изменять и тестировать адреса назначения.
1

Добавьте адрес назначения

В разделе Настройки организации > Уведомления команды добавьте адрес назначения типа webhook оповещений с URL вашего endpoint. URL должен использовать https:// и резолвиться в публичный адрес.
2

Сохраните секрет для подписи

Didit показывает полный секрет для подписи, который начинается с whsec_, только один раз. Сохраните его сразу: после этого консоль показывает только последние четыре символа.
3

Направьте оповещения на адрес

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

Отправьте тест

Нажмите Отправить тест, чтобы отправить оповещение alert.test, и проверьте, что ваш endpoint его принимает.
В одной организации в разделе Уведомления команды может быть до 25 адресов назначения. На адрес назначения попадает только активность из продакшн-среды. Оповещения о верификациях в песочнице, верификациях бизнеса, транзакциях и срабатываниях AML-мониторинга на него не отправляются никогда.

Типы оповещений

payload

Каждое оповещение отправляется методом POST с телом в формате JSON. Didit отправляет тело как компактный JSON с отсортированными ключами. Для удобства чтения этот пример отформатирован:
data всегда содержит:
  • event: ключ события, например session_in_review.
  • label и value: сведения о том, к чему относится оповещение, например Session и #1042.
Некоторые типы оповещений добавляют ключи в data:
  • alert.billing.autorefill_failed добавляет paused, логическое значение, которое равно true, если автопополнение приостановлено до обновления карты.
  • alert.service.degraded и alert.service.recovered добавляют service, status, incident_id, service_name, state, affected, country_name, started_at, resolved_at, duration_minutes, title и body. status принимает значение degraded или down для alert.service.degraded и значение recovered для alert.service.recovered. service использует ключи сервисов из GET /v3/status/, а incident_id совпадает с id инцидента в том же ответе.
Оповещения никогда не содержат персональных данных конечного пользователя или данных документов. Они идентифицируют сессию, транзакцию или другой объект по его номеру и содержат ссылку на него в консоли. Игнорируйте значения webhook_type и ключи data, которые вы не распознаёте, чтобы новые значения и ключи не ломали ваш endpoint.

Заголовки запроса

Проверка подписи

X-Signature-V2 представляет собой HMAC-SHA256 строки <X-Timestamp>.<raw body>, записанный в шестнадцатеричном виде и вычисленный с использованием секрета для подписи адреса назначения.
  • Используйте полный секрет в том виде, в котором Didit его показал, включая префикс whsec_.
  • Подписывайте необработанные байты запроса в том виде, в котором вы их получили. Разбор JSON и его повторная сериализация могут изменить байты и сломать проверку.
  • Сравнивайте подписи за постоянное время.
  • Отклоняйте запрос, если значение X-Timestamp отличается от текущего времени более чем на 5 минут. Didit подписывает каждую попытку, включая каждую повторную, новой меткой времени, поэтому это окно никогда не отклонит настоящую повторную попытку.
  • На неудачную проверку отвечайте кодом 400. Ответы 401, 403, 404 или 410 помечают адрес назначения для переподключения (см. Повторные попытки).
Webhook уведомлений подписываются не так, как webhook верификации. Заголовок тоже называется X-Signature-V2, но подписываемая строка другая, а webhook уведомлений не отправляют X-Signature или X-Signature-Simple. Не используйте повторно ваш верификатор webhook верификации.

Node.js (Express)

Python (Flask)

Ротация секрета для подписи

Ротацию секрета для адреса назначения выполняйте в разделе Уведомления команды. Didit показывает новый секрет один раз и подписывает им каждую последующую попытку, включая повторные попытки уведомлений, созданных до ротации. Старый секрет перестаёт работать сразу. Периода перехода нет, и ни один заголовок не содержит подпись, сделанную предыдущим секретом. Сразу после ротации разверните новый секрет на вашем endpoint.

Повторные попытки

Didit считает доставленным любой ответ 2xx. Каждая попытка ждёт ваш ответ до 5 секунд и не следует перенаправлениям. Didit повторяет отправку уведомления после тайм-аута, ошибки соединения, ответа 5xx или ответов 408, 425 и 429. Он делает до 5 повторных попыток в течение примерно 24 часов: Любой другой ответ окончательный, включая 3xx и любой другой 4xx. Тестовое сообщение, отправленное через Отправить тест, делает одну попытку и никогда не повторяется. Ответы 401, 403, 404 или 410 также помечают адрес назначения для переподключения: в консоли он отображается со статусом Переподключить. То же происходит, если URL при отправке Didit разрешается в частный или иным образом заблокированный адрес. Didit продолжает отправлять новые уведомления на адрес назначения и снова делает его активным после следующей успешной доставки или после обновления его URL. В разделе Уведомления команды в Последние уведомления показан каждый результат доставки, и оттуда можно повторить неудачную доставку.

Связанные материалы

  • Webhook верификации: результаты сессий, сущностей и транзакций для вашего приложения.
  • Статус сервиса: публичная лента, на которой основаны alert.service.degraded и alert.service.recovered.
  • Ручная проверка: что делать с верификацией, которая находится на проверке.
Последнее изменение 7 ноября 2026 г.