Перейти к основному содержанию
Didit’s KYB webhooks сообщают вашему бэкенду, когда сессия верификации бизнеса меняет статус или когда проверяющий либо реестр меняет данные. У сущностей Business есть собственные события. Подпишитесь на нужные события через API адресов назначения webhook или в Business Console.

Каталог событий

События сессий общие для сессий User и Business. Поле session_kind в payload показывает, к какому типу сессии относится событие. События на уровне сущности отделены от событий на уровне сессии.

События на уровне сессии

data.updated не отправляется, когда заявитель загружает документ или отправляет Key People, а также когда завершается повторный AML-скрининг. Чтобы отслеживать этот прогресс, используйте status.updated или получите решение по сессии.

События сущности Business

Подпишитесь на любую комбинацию этих событий на вашем адресе назначения webhook. Полный справочник событий сущностей Business и User см. в разделе webhook для сущностей.

Структура payload

Webhook сессий использует плоский payload без обёртки data. Оболочка, заголовки подписи и все общие поля описаны в справочнике по webhook. Сессия KYB добавляет следующие поля:

status.updated для сессии KYB

Блок decision содержит registry_checks[], key_people_checks[], document_verifications[], aml_screenings[] и другие массивы KYB.

data.updated для сессии KYB

data.updated содержит ту же плоскую оболочку, что и status.updated, а также trigger, который показывает, почему событие было отправлено. Когда статус сессии равен Approved, Declined, In Review или Abandoned, событие также содержит текущий decision. Чтобы увидеть, что изменилось, повторно запросите решение. Списка changed_fields в payload нет.

business.status.updated и business.data.updated

События сущностей тоже плоские. Они содержат vendor_business_id, vendor_data, status (ACTIVE, FLAGGED или BLOCKED) и created_at. business.status.updated дополнительно содержит previous_status. business.data.updated дополнительно содержит changed_fields и карту changes вида { field: { previous, current } }.

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

Каждый webhook подписывается по HMAC-SHA256 с использованием общего секрета вашего адреса назначения. Проверяйте необработанное тело запроса по заголовку X-Signature-V2 (рекомендуется) и отклоняйте доставки, у которых X-Timestamp старше 300 секунд. В справочнике по webhook перечислены все заголовки подписи, период перекрытия при смене секрета подписи и примеры кода.

Политика повторных попыток

  • Ответ 5xx или 404, таймаут либо ошибка соединения запускают до 2 повторных попыток: примерно через 1 минуту и примерно через 4 минуты. После этого доставка отбрасывается.
  • Ответы 4xx (кроме перечисленных) и 3xx не повторяются.
  • Каждая повторная попытка сохраняет тот же event_id, поэтому отсеивайте дубликаты по нему.
  • Вы можете переотправить доставку из журнала доставок адреса назначения. Полная политика описана в справочнике по webhook.

Подписка

Подпишитесь на нужные события на адресе назначения webhook:
Чтобы отфильтровать сессии бизнеса на своей стороне, проверяйте session_kind === "business" в событиях status.updated и data.updated.

Что дальше

Справочник по webhook

Адреса назначения, подпись, повторные попытки, типовые сценарии.

Статусы

Справочник статусов сессий и функций.

Схема ответа

Разбор payload решения KYB.
Последнее изменение 7 ноября 2026 г.