database_validations[] представляет собой один полный отчёт о проверке по базам данных — один запуск узла проверки по базам данных для одного государства выдачи. Результаты по отдельным реестрам находятся во вложенном массиве validations[] этой записи. На этой странице описана структура JSON, чтобы вы могли парсить результаты сопоставления, исходные данные из реестра и биометрические оценки, возвращаемые каждым сервисом.

Обзор
Отчёт о проверке по базам данных формируется каждый раз, когда узел сценария выполняет функцию «Проверка по базам данных». Каждая запись в массивеdatabase_validations[] представляет собой один запуск узла для одного государства выдачи; если узел запускает несколько сервисов для этой страны (например, CPF + CNH в Бразилии), каждый сервис отображается как отдельный элемент во вложенном массиве validations[] этой записи. Каждый отчёт содержит:
- Общий
statusфункции — значениеFeatureStatusChoices(Not Finished,Approved,Declined,In Review). - Сводный
match_type(full_match,partial_match,no_matchилиnull, если ни один сервис не вернул пригодный результат), агрегированный по сервисам с помощью метода сопоставления. issuing_state(ISO 3166-1 alpha-3) и производныйvalidation_type(one_by_one,two_by_twoилиnot_enabled— никогда неnull).- Блок
screened_data— предоставленные пользователем данные, отправленные в реестр. - Массив
validations[]— по одной записи на каждый сервис, выдавший результат, с каталожнымиservice_id/service_name, вендор-нейтральным кодомoutcome_code, опциональнымoutcome_detail, картойvalidationс результатами по каждому полю и очищенными исходными даннымиsource_data, полученными из ответа реестра. - Массив
errors[]— ошибки по каждому сервису при сбое или пропуске проверки; при отсутствии ошибок ключ полностью опускается. - Массив
warnings[]— события риска, зафиксированные в ходе проверки (см. предупреждения проверки по базам данных). - Поле
node_id, определяющее, какой узел графа сценария создал отчёт (только для сессий V3).
Где он отображается в ответах API
Отчёт отображается какdatabase_validations[] в GET /v3/session/{sessionId}/decision/ — всегда в виде массива JSON, а не одиночного объекта. Массив содержит по одной записи на каждый узел проверки по базам данных в графе сценария; в свою очередь, вложенный массив validations[] каждой записи содержит по одному элементу для каждого сервиса реестра, вернувшего результат.
null означает, что шаг проверки по базам данных ещё не выполнялся.
Схема
Каноническая схема с описанием каждого поля находится на странице Модели данных. Она формируется с помощьюDatabaseValidationV3Serializer.
Значения статуса
Полеstatus использует стандартное перечисление на уровне функции (см. Перечисления статусов) — см. Справочник перечислений статусов. Это перечисление также определяет значение Resub Requested, которое на практике не создаётся Проверкой по базам данных.
Пользовательские правила статусов для конкретных узлов применяются поверх этого базового статуса. См. настраиваемые действия и их значения по умолчанию в разделе Предупреждения проверки по базам данных.
Коды результатов
Каждая запись вvalidations[] содержит независимый от поставщиков outcome_code — одно из значений: MATCH, PARTIAL_MATCH, NO_MATCH, DOCUMENT_NOT_FOUND, INVALID_DOCUMENT_FORMAT, INVALID_INPUT, MINOR_BLOCKED, DECEASED, BIOMETRIC_NO_MATCH, BIOMETRIC_IMAGE_UNUSABLE, INCONCLUSIVE, DOCUMENT_SUPERSEDED, REGISTRY_UNAVAILABLE, REGISTRY_ERROR. Обратите внимание на различия: NO_MATCH означает, что реестр однозначно не подтвердил данные; INCONCLUSIVE означает, что реестр не смог сделать однозначный вывод (следует направить на проверку, а не отклонять); а BIOMETRIC_IMAGE_UNUSABLE указывает на техническую проблему с селфи (требуется повторная съёмка) — в отличие от окончательного BIOMETRIC_NO_MATCH. Полную классификацию и рекомендации по обработке см. на странице Коды результатов.
По одной записи на сервис
Массивvalidations[] содержит по одному элементу для каждого сервиса, вернувшего payload с результатом (объект validation, source_data, outcome_code или outcome_detail). Если ваш сценарий запускает несколько сервисов для одной страны (например, CPF Бразилии + CNH Бразилии), каждый из них отображается отдельно со своими service_id, outcome_code и source_data. Итоговое поле match_type агрегирует результаты по всем сервисам (любое полное совпадение → full_match; иначе любое частичное совпадение → partial_match; иначе no_match), а validation_type определяется тем, сколько различных сервисов вернули полное совпадение — см. Методы сопоставления.
Предварительно подписанные URL изображений
Поля изображений вsource_data (photo, signature) и screened_data (selfie, cnh_qr_code_image, document_image) возвращаются в виде предварительно подписанных URL с ограниченным сроком действия — обновляйте их, повторно вызывая endpoint принятия решения. Исходный payload стороннего сервиса намеренно не раскрывается через API.
Примеры
Одобрена — проверка статуса CPF Бразилии (Receita Federal)
Одобрена — биометрическая проверка DNI Аргентины (RENAPER)
Для Аргентины проверка использует RENAPER с биометрическим сравнением лиц. Ответ содержитface_match_score и дополнительные поля удостоверения личности, возвращённые реестром.
На проверке — не удалось выполнить проверку в реестре
Когда ни один сервис не возвращает пригодный результат — обязательные поля отсутствуют или некорректны либо реестр недоступен — полеmatch_type остаётся null, validation_type принимает значение not_enabled, выдаётся предупреждение COULD_NOT_PERFORM_DATABASE_VALIDATION, а функция переходит в статус In Review до исправления данных. За пропущенные сервисы плата не взимается.
Связанные разделы
- Обзор проверки по базам данных — принципы сквозной работы API и поддерживаемые реестры.
- Методы сопоставления — определение результатов 1×1 / 2×2 (
validation_type: one_by_one/two_by_two). - Коды результатов — полная классификация результатов с кодами детализации по странам.
- Поддерживаемые страны и сервисы — все действующие реестры, обязательные поля и цена за вызов.
- Предупреждения проверки по базам данных — что отображается, если сервис не может запуститься.
- Модели данных — проверка по базам данных — каноническая схема с описанием полей.