Перейти к основному содержанию
Сессии — это единица верификации в Didit. Когда вы запускаете верификацию, создаётся сессия. Когда верификация завершается, сессия содержит полный payload решения. Один и тот же API сессий работает с обоими типами: В уроке Academy о том, что видят пользователи, глава с отметкой 5:34 сравнивает размещённый сценарий с созданием собственных экранов. Именно этот компромисс API решает за вас.

​
Тип определяется сценарием

Когда вы создаёте сессию, вы передаёте workflow_id. Тип сценария определяет, будет ли сессия сессией проверки пользователей или верификации бизнеса. Тип вы отдельно не выбираете. Сценарии KYB создают сессии верификации бизнеса, а сценарии KYC создают сессии проверки пользователей.

​
Дискриминатор session_kind

Каждый ответ с сессией (при создании, получении, выводе списка, обновлении статуса, предоставлении доступа и импорте) содержит поле верхнего уровня:
  • "user": сессия является сессией проверки пользователей (KYC). Ответ содержит массивы функций, специфичные для пользователя.
  • "business": сессия является сессией верификации бизнеса (KYB). Ответ содержит массивы функций, специфичные для бизнеса.
Используйте это поле, чтобы на вашей стороне выбирать структуру данных.
Значения перечисления — короткие идентификаторы "user" и "business". Мы сделали их короткими для удобства API. Полные названия Проверка пользователей (KYC) и Верификация бизнеса (KYB) используются во всей документации для ясности.

​
Массивы функций по типу

Массивы функций в решении зависят от типа. Поля, которых нет у одного из типов, просто не появляются в ответе (без null и заглушек):

​
Общие поля верхнего уровня

Каждая сессия (обоих типов) содержит эти поля:

​
Охватываемые endpoint

Следующие endpoint принимают оба типа. Отдельных путей /v3/business-session/* нет.

​
Как работает поиск

Сессии проверки пользователей и верификации бизнеса — это два разных типа. Для ID используются UUID, поэтому коллизии исключены. Когда вы вызываете endpoint с session_id, Didit:
  1. Сначала ищет ID в таблице проверки пользователей (там большая часть трафика).
  2. Если ID не найден, ищет в таблице верификации бизнеса.
  3. Возвращает 404, если ни в одной таблице совпадения нет.
Вам не нужно указывать API, какой тип сессии вы ищете.

​
Статусы одинаковые

Значения статусов одинаковы для обоих типов. API возвращает их ровно так, как указано здесь: "Not Started", "In Progress", "Approved", "Declined", "In Review", "Abandoned", "Expired", "Kyc Expired", "Resubmitted", "Awaiting User". Сопоставление выполняется точно и с учётом регистра. Полный справочник см. в разделе статусы верификации.

​
Webhooks

События webhook уже содержат поле session_kind, чтобы ваши обработчики webhook могли маршрутизировать события по типу: См. webhooks для проверки подписи и семантики повторных попыток, а также KYB webhooks для каталога событий верификации бизнеса (KYB).

​
Следующие шаги

Создать сессию

Запустите верификацию — Проверка пользователей или Верификация бизнеса (KYB).

Получить сессию

Получите решение. Работает для обоих типов.

Список сессий

Фильтрация по session_kind.

Обновить статус

Одобрить, отклонить, проверить, отправить повторно.

Создать PDF

PDF-отчёты по типу сессии.

Передача и импорт

Перенос сессий между приложениями.
Последнее изменение 7 ноября 2026 г.