Перейти к основному содержанию
Каждая сущность User и Business в Didit проходит предсказуемый жизненный цикл. Понимание этого цикла помогает проектировать онбординг, постоянный мониторинг и сценарии устранения проблем.

Диаграмма жизненного цикла

Статусы подробно

Изменение статуса через PATCH /v3/users/{vendor_data}/update-status/ или PATCH /v3/businesses/{vendor_data}/update-status/ отправляет webhook (user.status.updated / business.status.updated), чтобы смежные системы могли реагировать в реальном времени.

Этапы жизненного цикла

Создание

Сущность создаётся одним из трёх способов:
  • Создана автоматически при запуске сессии с новым vendor_data. Сущность создаётся в статусе ACTIVE.
  • Создана заранее через API с помощью POST /v3/users/create/ или POST /v3/businesses/create/. Статус по умолчанию: ACTIVE.
  • Создана в консоли комплаенс-оператором. Статус изначально ACTIVE, если оператор не указал иначе.
Каждой сущности присваиваются uuid, генерируемый Didit, и идентификатор vendor_data, который принадлежит клиенту.

Верификация

К сущности привязываются сессии через vendor_data. Каждая сессия проходит через настроенный вами сценарий: верификация личности, проверка живости, сравнение лиц, AML, документы, поиск в реестре для KYB и так далее.Завершённые сессии обновляют агрегированные счётчики сущности:
  • session_count, approved_count, declined_count, in_review_count
  • карта features: последний статус каждой функции по всем сессиям (например, { "id_verification": "APPROVED", "aml": "IN_REVIEW" })
  • поля профиля берутся из последней одобренной сессии (например, full_name, date_of_birth, portrait_image).

Активное использование

Когда у сущности есть одна или несколько одобренных сессий, вы можете:
  • Отправлять транзакции, ссылающиеся на сущность через vendor_data в теле транзакции
  • Запускать постоянный AML-мониторинг: периодические повторные проверки по спискам санкций, PEP и негативных публикаций в СМИ
  • Повторно верифицировать по расписанию: создавать новые сессии для того же vendor_data через регулярные интервалы
  • Агрегировать сигналы риска по сессиям и транзакциям

Переходы статусов

Статус сущности меняется автоматически или вручную.Автоматические переходы
  • ACTIVE → FLAGGED, когда транзакция превышает порог проверки или правило добавляет сущность в список наблюдения.
  • ACTIVE → BLOCKED, когда биометрические данные лица совпадают с записью в списке блокировки.
Отклонённая сессия не вносит сущность в список блокировки, поэтому статус не меняется. Внесение отклонённого субъекта в список блокировки выполняется вручную: добавьте запись на странице списка блокировки или через API списков. Запись типа USER (vendor_data) переводит статус в BLOCKED.Ручные переходы происходят, когда аналитик меняет статус в консоли или когда вы вызываете endpoint update-status.Каждый переход отправляет webhook user.status.updated или business.status.updated.

Удаление

Сущности удаляются через POST /v3/users/delete/ или POST /v3/businesses/delete/ (пакетно). Запись сущности удаляется безвозвратно. Удаление User также очищает все биометрические шаблоны, сохранённые для него после удаления сессий, поэтому человек перестаёт совпадать при обнаружении дубликатов и в поиске по лицу.Эти endpoint’ы не распространяются на сессии верификации и на транзакции. Удаляйте сессии через Удаление сессии или Пакетное удаление сессий. Транзакции удаляются из консоли.

Временные метки активности

Сущности отслеживают активность, чтобы помочь вам выявлять неактивные и активные профили: Используйте эти метки, чтобы фильтровать неактивные сущности, планировать повторные верификации или запускать постоянный мониторинг.

События, отправляемые в ходе жизненного цикла

См. webhook сущностей для форматов payload и семантики доставки.

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

Связывание vendor_data

Как vendor_data связывает сессии, транзакции и сущности между собой.

Операции с User

Создание, обновление, смена статуса и удаление сущностей User.

Операции с Business

Создание, обновление, смена статуса и удаление сущностей Business.
Последнее изменение 7 ноября 2026 г.