Перейти к основному содержанию
PATCH
curl

Что это делает

Сессия верификации состоит из отдельных функций (шагов): ID/OCR, Проверка живости, Сравнение лиц, AML, Подтверждение адреса, Проверка телефона и других. Этот endpoint позволяет задать статус одного из этих шагов: Approved, Declined или In Review. Используйте update-status, когда нужно одобрить, отклонить или снова открыть всю сессию целиком. Используйте этот endpoint, когда нужно зафиксировать решение только по одному шагу, например чтобы пометить шаг Сравнение лиц как Declined в вашем собственном процессе проверки. Сессия, у которой уже есть решение, его сохраняет: меняется только шаг. Если решения по сессии ещё нет, а её сценарий ждёт именно этот шаг, применение переопределения завершает шаг так же, как его обычное завершение. Сценарий продолжается, последующие шаги выполняются, а узел статуса может задать решение по сессии и отправить webhook status.updated.

Указание шага через node_id

В сценариях на основе графа у каждого шага есть node_id (например, feature_ocr_1, feature_liveness_1, feature_aml_1). Их можно найти в решении по сессии: каждая функция в решении V3 содержит свой node_id. Для сценариев без графа (из одного шага) у базовой функции нет идентификатора узла. Чтобы обратиться к ней, передайте буквальное значение default в nodeId. Поскольку ни один шаг такого сценария не имеет идентификатора узла, также передайте feature_type (например, LIVENESS, AML или FACE_MATCH), чтобы указать нужный шаг. Неизвестный feature_type возвращает 400.

Ожидание завершения прохождения пользователем

По умолчанию переопределение применяется сразу. Если пользователь ещё проходит сценарий, это меняет шаг в работающем сценарии; тогда переопределение записывается с forced: true. Установите defer_until_flow_finishes: true, чтобы дождаться завершения. Пока сессия находится в статусе Not Started, In Progress или Resubmitted и пользователь не завершил прохождение, переопределение сохраняется как pending_until_flow_finishes. Оно применяется, когда пользователь завершает прохождение, после того как сценарий принимает собственное решение. Если сценарий по сессии уже завершён, переопределение применяется сразу в любом случае. Ожидающее переопределение отменяется вместо применения, если:
  • пользователь повторно проходит шаг до завершения (check_changed),
  • новое переопределение того же шага заменяет его (replaced),
  • сессия завершается до окончания сценария: прервана, истекла или по ней принято решение посреди сценария (session_closed),
  • вы отменяете его с помощью Отмена переопределения функции (cancelled_by_reviewer).
В ответе поле override сообщает, что произошло: state принимает значение applied или pending_until_flow_finishes, а applied_at заполняется, когда переопределение применено. Верхнеуровневое поле new_status содержит сохранённый статус шага, поэтому пока переопределение ожидает, оно не меняется. Используйте Список переопределений функций, чтобы увидеть все переопределения сессии и то, находится ли пользователь ещё в сценарии.

Поддержка KYC и KYB

Работает одинаково для сессий типа Проверка пользователей (KYC) и Верификация бизнеса (KYB): Didit находит sessionId в обоих случаях. Поддерживаемые типы шагов: ID/OCR, Проверка живости, Сравнение лиц, NFC, AML, Подтверждение адреса, Проверка телефона, Проверка электронной почты, Проверка по базам данных, Анкеты, а также проверки реестра компаний, документов и ключевых лиц для KYB.
Самостоятельные API-сессии (созданные через отдельные API верификации, session_type = API) не могут менять статусы отдельных функций: endpoint возвращает 400.

Примеры

Что происходит после обновления

  • Webhook: событие data.updated отправляется, когда переопределение применяется: сразу или по завершении прохождения. Пока оно ожидает или если отменено, ничего не отправляется.
  • Активность: каждое переопределение записывается в разделе Активность сессии со статусом FEATURE_OVERRIDE_PENDING, FEATURE_OVERRIDE_APPLIED или FEATURE_OVERRIDE_CANCELLED, с указанием инициатора (API-ключ, пользователь или система, когда ожидающее переопределение применяется). В записи запроса причиной служит ваш comment. В массиве reviews решения по сессии эти записи отображаются с new_status: null, а причина из вашего запроса находится в comment.
  • Решение по сессии: сессия, у которой уже есть решение, его сохраняет. Чтобы изменить итоговое решение, вызовите update-status отдельно.

Разрешения

Требуется привилегия write:sessions с клиентским API-ключом (x-api-key) или заголовком авторизации пользователя. API-ключ с ограниченными правами должен иметь доступ на запись к решениям.

Связанные материалы

Авторизации

x-api-key
string
header
обязательно

API-ключ вашего приложения из раздела «Разработчикам» -> «API-ключи» в Business Console. Основной ключ имеет полный доступ. Именованный ключ может иметь ограниченную область действия: без доступа, чтение или запись для каждого ресурса, ограничение определенными сценариями или одобренными сессиями, списком IP-адресов и сроком действия. 401 означает, что ключ неверен, отозван или его срок действия истек; 403 означает, что ключ не был передан, у ключа нет доступа к этому ресурсу или действию, либо запрос поступил с адреса вне его списка IP-адресов; 404 на маршруте сессии означает, что сессия не входит в сценарии или статусы ключа. Ключ без доступа к медиа получает URL изображений, видео и PDF как null, а ключ без прав на запись сессий получает ссылки на сессии и токены как null. См. https://docs.didit.me/console/api-keys.

Параметры пути

sessionId
string<uuid>
обязательно

UUID сессии верификации. Принимает ID сессий как пользователей (KYC), так и компаний (KYB) — сервис сопоставляет ID для обоих типов сессий.

Пример:

"11111111-2222-3333-4444-555555555555"

nodeId
string
обязательно

ID узла графа сценария для обновляемой функции (например, feature_ocr_1). Используйте строковое значение default для сценариев без графа (одношаговых), где у функции нет ID узла.

Пример:

"feature_ocr_1"

Тело

application/json
new_status
enum<string>
обязательно

Целевой статус для этой функции. Должен отличаться от текущего значения.

Доступные опции:
Approved,
Declined,
In Review
Пример:

"Approved"

comment
string

Необязательная текстовая заметка в свободной форме, фиксируемая в журнале проверки сессии при изменении этой функции.

Пример:

"Document manually verified by compliance."

feature_type
enum<string>

На какой тип шага нацелено действие. Требуется в неграфовых сценариях (nodeId = default), где шаги не привязаны к общему узлу; в остальных случаях необязательно. Неизвестное значение возвращает 400.

Доступные опции:
ID_VERIFICATION,
OCR,
OCR_BACK,
NFC,
LIVENESS,
FACE,
AGE_ESTIMATION,
AGE_VERIFICATION,
FACE_SEARCH,
FACE_MATCH,
IP_ANALYSIS,
AML,
PHONE,
PHONE_VERIFICATION,
EMAIL,
EMAIL_VERIFICATION,
POA,
PROOF_OF_ADDRESS,
DATABASE_VALIDATION,
DATA_VALIDATION,
QUESTIONNAIRE,
DOCUMENT_AI,
KYB_REGISTRY,
KYB_DOCUMENTS,
KYB_KEY_PEOPLE,
BANK_VERIFICATION,
GEOLOCATION
Пример:

"LIVENESS"

defer_until_flow_finishes
boolean
по умолчанию:false

Пока человек всё ещё проходит сценарий, сохранить переопределение как pending_until_flow_finishes и применить его после завершения сценария, а не сразу. Если параметр опущен или равен false, переопределение применяется сразу. В сессии, сценарий которой уже завершился, оно применяется сразу в любом случае.

Пример:

false

Ответ

Переопределение сохранено. new_status представляет собой сохранённый статус проверки: запрошенный статус после применения переопределения либо неизменённый статус, пока ожидается завершение сценария. override указывает, что именно произошло.

session_id
string<uuid>
обязательно
node_id
string | null
обязательно

Узел сценария для обновлённого шага или null для шага без узла (путь default в сценарии без графа).

Пример:

"feature_ocr_1"

feature_type
string
обязательно

Название модели обновленной функции (например, KYC, Face, FaceMatch, AML, POA).

Пример:

"KYC"

new_status
string
обязательно

Сохранённый статус проверки: запрошенный после применения переопределения либо неизменённый, пока переопределение ожидает завершения сценария.

Пример:

"Approved"

override
object
обязательно

Одно переопределение статуса проверки (функции), выполненное с помощью PATCH /v3/session/{sessionId}/features/{nodeId}/update-status/: что оно меняет, применено ли оно или всё ещё ожидает завершения сценария пользователем, кто запросил и почему.

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