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

Обзор

Каждый отчёт по функции следует форме сериализатора V3, определённой в service-didit-verification. Один и тот же объект встречается в трёх местах, поэтому схема, которую вы видите здесь, является единственным источником истины для всех них:
  • GET /v3/session/{sessionId}/decision/: каждая функция возвращается как массив во множественном числе (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], poa_verifications[], phone_verifications[], email_verifications[], aml_screenings[], ip_analyses[], database_validations[], questionnaire_responses[], signatures[], bank_verifications[] (см. Методы верификации банка), а также KYB-аналоги registry_checks[], document_verifications[], key_people_checks[]).
  • Payload webhook-событий (status.updated, data.updated): та же форма внутри обёртки decision.
  • Отдельные API: ответы с одним объектом (Поиск по лицу, Оценка возраста, Биометрическая аутентификация) используют тот же набор полей.
V3 вводит многоэкземплярные сценарии: каждый объект функции содержит node_id, который привязывает отчёт к узлу графа сценария, создавшему его. Эндпоинты V2 (с формами единственного числа kyc, face, aml и т. д.) сохраняют обратную совместимость, но возвращают только первый экземпляр.

Общие поля

Каждый объект отчёта содержит следующие поля: Медиаполя (portrait_image, front_image, document_file, …) являются предподписанными URL с ограниченным сроком действия. Скачивайте их сразу, а не сохраняйте URL. В примерах они показаны как https://<media-host>/....

Объект предупреждения

Возвращается в каждом массиве warnings[]. Схема из logs/serializers/log.py:8-65 (LogV3Serializer).

Объекты отчётов

В остальных разделах описан каждый объект отчёта по отдельной функции. Текст заголовков H3 намеренно не меняется, чтобы на них могли ссылаться другие документы.

Верификация личности

Возвращается для каждого KYC-/ID-документа, отправленного пользователем. Появляется как id_verifications[] в GET /v3/session/{sessionId}/decision/ и внутри поля kyc в ответах V2. Источник: kyc/serializers/kyc.py:383-414 (IDVerificationV3Serializer, наследует IDVerificationV2Serializer из kyc/serializers/kyc.py:320-380).
Тот же объект при использовании метода, отличного от документа. Меняются только ключи, специфичные для метода: все поля, которые при чтении документа заполняются данными документа, вместо этого заполняются данными записи реестра или атрибутами кошелька, а неприменимые ключи равны null.

NFC-верификация

Возвращается для каждого чтения чипа документа, удостоверяющего личность: ePassport или eID-чип ICAO 9303 либо карта Japan My Number Card, считанная через JPKI (chip_protocol: "jpki"). Появляется как nfc_verifications[] в GET /v3/session/{sessionId}/decision/ (по одной на родительскую запись KYC). Источник: kyc/serializers/epassport.py:121-139 (NFCV3Serializer, расширяет NFCV2Serializer в kyc/serializers/epassport.py:83-118).

Проверка живости

Возвращается для каждой сессии проверки живости. Появляется как liveness_checks[] в GET /v3/session/{sessionId}/decision/. Источник: face/serializers/face.py:301-320 (LivenessV3Serializer, расширяет LivenessV2Serializer в face/serializers/face.py:216-298).
Пассивная сессия возвращает это поле, если при съёмке была сохранена запись, и null, если сессия запись не сохранила: пример выше относится к сессии без записи.

Сравнение лиц

Возвращается для каждого сравнения лиц (обычно лица пользователя из проверки живости с портретом из документа). Появляется как face_matches[] в GET /v3/session/{sessionId}/decision/. Источник: face/serializers/face.py:367-389 (FaceMatchV3Serializer, расширяет FaceMatchV2Serializer в face/serializers/face.py:323-364).

Поиск по лицу

Возвращается отдельным API поиска по лицу (POST /v3/face-search/). Поиск по лицу никогда не возвращается в виде массива в /v3/session/{sessionId}/decision/. Если указано save_api_request=true, сессия отображается там как элемент FACE_SEARCH в features[] и как элемент liveness_checks[] с сохранёнными matches. Источники: apis/serializers/face_search.py:8-79 (FaceSearchResponseSerializer, который оборачивает FaceSearchDetailsSerializer); словари совпадений формируются в face/utils/utils.py:869-884. Ответ верхнего уровня: Объект face_search:

Объект совпадения поиска по лицу

AML-скрининг

Возвращается для каждой проверенной сущности. Появляется как aml_screenings[] в GET /v3/session/{sessionId}/decision/ для сессий KYC и KYB. Источник: aml/serializers/aml.py:63-85 (AMLV3Serializer, наследует AMLV2Serializer из aml/serializers/aml.py:28-60).

Анализ IP

Возвращается для каждого зафиксированного сетевого местоположения. Появляется как ip_analyses[] в GET /v3/session/{sessionId}/decision/ для сессий KYC и KYB. Источник: kyc/serializers/location.py:196-243 (IPAnalysisSerializerV3).

Проверка местоположения

Возвращается для каждого шага Проверка местоположения. Появляется как geolocation_checks[] в GET /v3/session/{sessionId}/decision/: один элемент на шаг, его принятая попытка. geolocation_attempts[] перечисляет каждую попытку каждого шага, от самой ранней к самой поздней. Оба поля равны null для сценария без этого шага. Источник: GeolocationDecisionSerializer. Все поля и примеры приведены в отчёте о верификации местоположения.

Подтверждение адреса

Возвращается для каждого предоставленного документа с адресом. Появляется как poa_verifications[] в GET /v3/session/{sessionId}/decision/. Источник: poa/serializers/poa.py:212-227 (POAV3Serializer, расширяет POAV2Serializer в poa/serializers/poa.py:173-209).

Проверка телефона

Возвращается для каждой попытки верификации телефона. Появляется как phone_verifications[] в GET /v3/session/{sessionId}/decision/ для сессий KYC и KYB. Источник: phone/serializers/phone.py:251-266 (PhoneV3Serializer, наследует PhoneV2Serializer в phone/serializers/phone.py:103-248).

Проверка электронной почты

Возвращается для каждой попытки верификации адреса электронной почты. Появляется как email_verifications[] в GET /v3/session/{sessionId}/decision/ для сессий KYC и KYB. Источник: email_verification/serializers/email.py:149-164 (EmailV3Serializer, наследует EmailV2Serializer в email_verification/serializers/email.py:38-146).

Проверка по базам данных

Возвращается для каждого поиска по базам данных, выполненного по данным, которые отправил пользователь. Появляется как database_validations[] в GET /v3/session/{sessionId}/decision/. Источник: database_validation/serializers/database_validation.py:21-142 (DatabaseValidationV3Serializer, наследует DatabaseValidationV2Serializer).

Ответ на анкету

Возвращается для каждой отправки анкеты. Появляется как questionnaire_responses[] в GET /v3/session/{sessionId}/decision/ для сессий KYC и KYB. Источник: questionnaires/serializers/questionnaire.py:591-597 (QuestionnaireResponseV3Serializer, расширяет QuestionnaireResponseSerializer из questionnaires/serializers/questionnaire.py:520-588).

Электронная подпись

Возвращается для каждого подписанта шага Электронной подписи. Появляется как signatures[] в GET /v3/session/{sessionId}/decision/ для сессий KYC и KYB, только если в сценарии есть этот шаг. В отличие от других объектов отчетов, его status означает этап подписания, а результат находится в verdict. Элементы warnings[] имеют вид { code, node_id }, а не вид объектов предупреждений. Отчёт об электронной подписи содержит полный пример и все вложенные поля.

Оценка возраста

Возвращается отдельным API оценки возраста (POST /v3/age-estimation/). Ответ содержит подмножество структуры Liveness check внутри конверта age_estimation: status, method, score, age_estimation, warnings, а также блок обнаружения лица user_image, доступный только в автономном API. Он не включает reference_image, video_url, matches, face_quality и face_luminance. В сессиях сценария отдельного массива нет: расчётный возраст выводится в поле liveness_checks[].age_estimation в ответе GET /v3/session/{sessionId}/decision/. Источник: apis/serializers/age_estimation.py:50-55 (AgeEstimationResponseSerializer), конверт собирается в apis/views/age_estimation.py:138-174.

Биометрическая аутентификация

Биометрическая аутентификация выполняет тот же конвейер проверки живости и сравнения лиц, что и стандартная KYC-верификация, но настроена на сравнение снятого лица с эталонным изображением существующего пользователя, а не с портретом из документа, извлечённым через OCR. Отдельного сериализатора нет: GET /v3/session/{sessionId}/decision/ возвращает стандартные объекты Проверка живости и Сравнение лиц в полях liveness_checks[] и face_matches[]. Сценарий сессии настраивается с workflow_type = "biometric_authentication" (WorkflowTypeChoices, common/config/choices.py:636).

Реестр KYB

Возвращается для каждой компании, подтверждённой реестром, в сценарии KYB. Отображается как registry_checks[] в GET /v3/session/{sessionId}/decision/ для сессий компаний. Источник: kyb/serializers/kyb.py:939-964 (RegistryCheckV3Serializer).

Объект компании

Источник: kyb/serializers/kyb.py:220-321 (KYBCompanyResponseSerializer).

KYB-документ

Возвращается для каждого узла, который собирает подтверждающие KYB-документы. Появляется как document_verifications[] в GET /v3/session/{sessionId}/decision/ для сессий компаний: один элемент на каждый node_id, а в items[] перечислен каждый загруженный документ. Источник: kyb/serializers/kyb.py:1053-1068 (DocumentVerificationV3Serializer); каждый элемент соответствует kyb/serializers/kyb.py:811-851 (KYBDocumentResponseSerializer).

Объект элемента KYB-документа

KYB: ключевое лицо

Возвращается для каждого узла «Ключевые лица» в сценарии KYB. Появляется как key_people_checks[] в GET /v3/session/{sessionId}/decision/ для сессий компаний. Источник: kyb/serializers/kyb.py:967-1050 (KeyPeopleCheckV3Serializer).

Поля уровня решения

Эти ключи находятся рядом с массивами функций в GET /v3/session/{sessionId}/decision/ и внутри decision в webhook. Подробнее о том, как читать эти поля, см. в разделе Получение сессии.

Согласие на биометрические данные

Каждое решение по проверке пользователей и webhook сессии содержат один объект biometric_consent (не массив). В нём указано, требовалось ли для сессии явно получить согласие на обработку биометрических данных, по какой причине и какие данные подтверждают этот ответ. Значение null, если сессия никогда не оценивалась, например для сценария без захвата лица. Источник: BiometricConsentDecisionSerializer (sessions/serializers/biometric_consent.py). Когда появляется этот шаг и что означает каждый случай, описано в разделе Согласие на биометрические данные. Поля без записанного значения равны null, но никогда не являются пустой строкой. Сессия в штате Иллинойс, проведённая на нативном SDK версии ниже 4.10.0, который снял селфи без этого шага:
Человек с VPN, выход которого находится за пределами США и который дал согласие на размещённой странице верификации:

Справочник значений перечисления status

Два связанных набора значений используют одно и то же имя поля status. Каждый объект отчёта по отдельной функции на этой странице использует перечисление уровня функции. Верхнеуровневое поле status родительской сессии использует более широкое перечисление уровня сессии.

Статусы на уровне функций

Используется в поле status каждого объекта отчёта. Источник: common/config/choices.py:343-348 (FeatureStatusChoices). Верификация телефона, электронной почты и личности может дополнительно возвращать Expired, когда истекает время, отведённое на соответствующий шаг (PhoneStatusChoices в common/config/choices.py:377-382, EmailStatusChoices в common/config/choices.py:434-439).

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

Используется в верхнеуровневом поле status родительской сессии. Источник: common/config/choices.py:106-117 (StatusChoices).
Конечными значениями сессии являются Approved, Declined, In Review, Expired, Kyc Expired и Abandoned. Сессия может получить общее решение, пока отдельная функция остаётся в статусе In Review.
Последнее изменение 14 ноября 2026 г.