Настройка адреса назначения
webhook оповещений настраиваются в Business Console, а не через API. Участники, которые могут управлять настройками организации, могут добавлять, изменять и тестировать адреса назначения.1
Добавьте адрес назначения
В разделе Настройки организации > Уведомления команды добавьте адрес назначения типа webhook оповещений с URL вашего endpoint.
URL должен использовать
https:// и резолвиться в публичный адрес.2
Сохраните секрет для подписи
Didit показывает полный секрет для подписи, который начинается с
whsec_, только один раз.
Сохраните его сразу: после этого консоль показывает только последние четыре символа.3
Направьте оповещения на адрес
Добавление адреса назначения пока ничего на него не отправляет.
Добавьте адрес назначения в правила маршрутизации тех оповещений, которые он должен получать.
4
Отправьте тест
Нажмите Отправить тест, чтобы отправить оповещение
alert.test, и проверьте, что ваш endpoint его принимает.Типы оповещений
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помечают адрес назначения для переподключения (см. Повторные попытки).
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. - Ручная проверка: что делать с верификацией, которая находится на проверке.