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

Обзор

Каждый отчёт по функции следует форме сериализатора 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 намеренно не меняется, чтобы на него могли ссылаться другие документы.

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

Возвращается для каждого документа, удостоверяющего личность, который загрузил пользователь. Появляется как 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-верификация

Возвращается для каждого чтения чипа документа, удостоверяющего личность: электронный паспорт ICAO 9303 или чип eID, либо чтение карты My Number (Япония) через 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).

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

Возвращается для каждого сравнения лиц (обычно живого лица пользователя с портретом на документе). Появляется как 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.
Последнее изменение 7 ноября 2026 г.