> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Жизненный цикл сущностей: статусы пользователей и бизнеса > Состояния и переходы сущностей Didit «Пользователь» и «Бизнес»: создание, верификация, ACTIVE/FLAGGED/BLOCKED, удаление. Оплата за вызов. Каждая сущность User и Business в Didit проходит предсказуемый жизненный цикл. Понимание этого цикла помогает проектировать онбординг, постоянный мониторинг и сценарии устранения проблем. ## Диаграмма жизненного цикла ```mermaid theme={null} stateDiagram-v2 [*] --> ACTIVE: Created (API, console, or auto from session) ACTIVE --> FLAGGED: Rule match / analyst review / suspicious pattern FLAGGED --> ACTIVE: Analyst clears / remediation completed ACTIVE --> BLOCKED: Manual block / blocklist match FLAGGED --> BLOCKED: Investigation concludes blocked BLOCKED --> ACTIVE: Manual unblock (analyst only) ``` ## Статусы подробно | Статус | Значение | Как применяется | | - | - | - | | `ACTIVE` | По умолчанию: сущность в хорошем состоянии | Новые сессии и транзакции проходят через настроенные сценарии и правила | | `FLAGGED` | У сущности есть незакрытая проблема, требующая проверки | Новые сессии по-прежнему запускаются, но по умолчанию получают `IN_REVIEW`; транзакции могут автоматически эскалироваться в зависимости от правил | | `BLOCKED` | Сущность заблокирована на вашей платформе | Новые сессии и новые транзакции автоматически отклоняются; для этого `vendor_data` нельзя создавать новые ссылки на сессии | > [!NOTE] > > Изменение статуса через `PATCH /v3/users/{vendor_data}/update-status/` или `PATCH /v3/businesses/{vendor_data}/update-status/` отправляет webhook (`user.status.updated` / `business.status.updated`), чтобы смежные системы могли реагировать в реальном времени. ## Этапы жизненного цикла **1. Создание** Сущность создаётся одним из трёх способов: * **Создана автоматически** при запуске сессии с новым `vendor_data`. Сущность создаётся в статусе `ACTIVE`. * **Создана заранее через API** с помощью `POST /v3/users/create/` или `POST /v3/businesses/create/`. Статус по умолчанию: `ACTIVE`. * **Создана в консоли** комплаенс-оператором. Статус изначально `ACTIVE`, если оператор не указал иначе. Каждой сущности присваиваются `uuid`, генерируемый Didit, и идентификатор `vendor_data`, который принадлежит клиенту. **2. Верификация** К сущности привязываются сессии через `vendor_data`. Каждая сессия проходит через настроенный вами [сценарий](https://docs.didit.me/ru/console/workflows.md): верификация личности, проверка живости, сравнение лиц, 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`). **3. Активное использование** Когда у сущности есть одна или несколько одобренных сессий, вы можете: * **Отправлять транзакции**, ссылающиеся на сущность через `vendor_data` в теле транзакции * **Запускать постоянный AML-мониторинг**: периодические повторные проверки по спискам санкций, PEP и негативных публикаций в СМИ * **Повторно верифицировать по расписанию**: создавать новые сессии для того же `vendor_data` через регулярные интервалы * **Агрегировать сигналы риска** по сессиям и транзакциям **4. Переходы статусов** Статус сущности меняется автоматически или вручную. **Автоматические переходы** * `ACTIVE → FLAGGED`, когда транзакция превышает порог проверки или правило добавляет сущность в список наблюдения. * `ACTIVE → BLOCKED`, когда биометрические данные лица совпадают с записью в списке блокировки. Отклонённая сессия не вносит сущность в список блокировки, поэтому статус не меняется. Внесение отклонённого субъекта в список блокировки выполняется вручную: добавьте запись на [странице списка блокировки](https://docs.didit.me/ru/console/blocklist-users.md) или через [API списков](https://docs.didit.me/ru/management-api/lists/overview.md). Запись типа `USER` (`vendor_data`) переводит статус в `BLOCKED`. **Ручные переходы** происходят, когда аналитик меняет статус в консоли или когда вы вызываете endpoint `update-status`. Каждый переход отправляет webhook `user.status.updated` или `business.status.updated`. **5. Удаление** Сущности удаляются через `POST /v3/users/delete/` или `POST /v3/businesses/delete/` (пакетно). Запись сущности удаляется безвозвратно. Удаление User также очищает все [биометрические шаблоны](https://docs.didit.me/ru/management-api/biometric-templates/overview.md), сохранённые для него после удаления сессий, поэтому человек перестаёт совпадать при обнаружении дубликатов и в поиске по лицу. Эти endpoint'ы не распространяются на сессии верификации и на транзакции. Удаляйте сессии через [Удаление сессии](https://docs.didit.me/ru/sessions-api/delete-session.md) или [Пакетное удаление сессий](https://docs.didit.me/ru/management-api/sessions/batch-delete.md). Транзакции удаляются из консоли. ## Временные метки активности Сущности отслеживают активность, чтобы помочь вам выявлять неактивные и активные профили: | Метка времени | Обновляется при | | - | - | | `first_session_at` | Создана первая сессия для этой сущности | | `last_session_at` | Создана или обновлена последняя сессия | | `last_activity_at` | Произошло любое изменение: сессия, транзакция, смена статуса, обновление профиля | Используйте эти метки, чтобы фильтровать неактивные сущности, планировать повторные верификации или запускать постоянный мониторинг. ## События, отправляемые в ходе жизненного цикла | Этап жизненного цикла | Отправляемые webhook | | - | - | | Создание (автоматически из сессии) | `status.updated` (сессия), `user.data.updated` или `business.data.updated` | | Верификация | `status.updated` (сессия), `data.updated` | | Смена статуса | `user.status.updated` или `business.status.updated` | | Транзакция отправлена | `transaction.created` | | Статус транзакции изменён | `transaction.status.updated` | См. [webhook сущностей](https://docs.didit.me/ru/entities/webhooks.md) для форматов payload и семантики доставки. ## Следующие шаги > [card] [Связывание vendor\_data](https://docs.didit.me/ru/entities/vendor-data-linking.md) > > Как `vendor_data` связывает сессии, транзакции и сущности между собой. > [card] [Операции с User](https://docs.didit.me/ru/entities/users/operations.md) > > Создание, обновление, смена статуса и удаление сущностей User. > [card] [Операции с Business](https://docs.didit.me/ru/entities/businesses/operations.md) > > Создание, обновление, смена статуса и удаление сущностей Business. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.