database_validations[] é um relatório completo de Validação de banco de dados, ou seja, uma execução de um nó de Validação de banco de dados em relação a um único estado emissor. Os resultados do registro de cada serviço ficam no subarray validations[] dessa entrada. Esta página documenta o formato do JSON para que você possa interpretar os resultados de correspondência, os dados da fonte de registro e as pontuações biométricas retornados por cada serviço.

Visão geral
Um relatório de validação de banco de dados é gerado sempre que um nó do fluxo de verificação (workflow) executa o recurso de Validação de banco de dados. Cada entrada no arraydatabase_validations[] representa uma execução de nó para um estado emissor. Se o nó executar vários serviços para esse país (por exemplo, CPF + CNH no Brasil), cada serviço aparece como um item separado no subarray validations[] da entrada. Cada relatório contém:
- O
statusgeral do recurso, um valor deFeatureStatusChoices(Not Finished,Approved,Declined,In Review). - Um
match_typeconsolidado (full_match,partial_match,no_matchounullquando nenhum serviço retornou um resultado utilizável), agregado entre os serviços pelo método de correspondência. - O
issuing_state(ISO 3166-1 alpha-3) e ovalidation_typederivado (one_by_one,two_by_twoounot_enabled, nuncanull). - O bloco
screened_data, com os dados fornecidos pelo usuário que foram enviados ao registro. - Um array
validations[], com uma entrada por serviço que produziu um resultado, contendo oservice_id/service_namedo catálogo, ooutcome_codeneutro em relação ao fornecedor, umoutcome_detailopcional, o mapavalidationpor campo e osource_datatratado, extraído da resposta do registro. - Um array
errors[], com os erros por serviço quando uma consulta falhou ou foi ignorada. A chave é omitida por completo quando não há erros. - Um array
warnings[], com os eventos de risco emitidos durante a validação (consulte avisos da Validação de banco de dados). - Um
node_idque identifica qual nó do grafo do fluxo gerou o relatório (somente sessões V3).
Onde aparece nas respostas da API
O relatório aparece comodatabase_validations[] em GET /v3/session/{sessionId}/decision/. É sempre um array JSON, nunca um objeto único. O array contém uma entrada por nó de Validação de banco de dados no grafo do fluxo de trabalho. Por sua vez, o subarray validations[] de cada entrada contém um item por serviço de registro que produziu um resultado.
null significa que nenhuma etapa de Validação de banco de dados foi executada ainda.
Schema
O schema canônico, campo a campo, está na página Modelos de dados. Ele é gerado peloDatabaseValidationV3Serializer.
Valores de status
status usa o enum padrão de nível de recurso (consulte Enums de status). Veja a referência do enum de status. O enum também define Resub Requested, que na prática não é gerado pela Validação de banco de dados.
Regras de status personalizadas por nó são aplicadas sobre esse status base. Consulte Avisos da Validação de banco de dados para ver as ações configuráveis e seus padrões.
Códigos de resultado
Cada item emvalidations[] traz um outcome_code independente de fornecedor, que é um destes: 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. Observe as diferenças. NO_MATCH significa que o registro definitivamente não confirmou os dados. INCONCLUSIVE significa que o registro não conseguiu determinar nem uma coisa nem outra (encaminhe para revisão, não recuse). BIOMETRIC_IMAGE_UNUSABLE é um problema técnico da selfie (capture novamente), ao contrário do resultado definitivo BIOMETRIC_NO_MATCH. Veja a taxonomia completa e o tratamento recomendado na página Códigos de resultado.
Um item por serviço
O arrayvalidations[] contém um item para cada serviço que gerou um payload de resultado (um mapa validation, source_data, outcome_code ou outcome_detail). Se o seu fluxo executa vários serviços para o mesmo país (por exemplo, CPF e CNH no Brasil), cada um aparece separadamente, com seus próprios service_id, outcome_code e source_data. O match_type consolidado agrega todos os serviços: qualquer correspondência completa resulta em full_match; caso contrário, qualquer correspondência parcial resulta em partial_match; caso contrário, no_match. Já o validation_type é derivado de quantos serviços distintos tiveram correspondência completa. Consulte Métodos de correspondência.
URLs de imagem pré-assinadas
Os campos de imagem emsource_data (photo, signature) e em screened_data (selfie, cnh_qr_code_image, document_image) são retornados como URLs pré-assinadas que expiram. Para renová-las, chame o endpoint de decisão novamente. O payload bruto recebido do provedor não é exposto pela API, de forma intencional.
Exemplos
Aprovado: consulta da situação do CPF no Brasil (Receita Federal)
Aprovado: biometria do DNI na Argentina (RENAPER)
Na Argentina, a validação usa o RENAPER com correspondência facial biométrica. A resposta inclui umface_match_score e campos de identidade adicionais retornados pelo registro.
Em revisão: o registro não pôde ser consultado
Quando nenhum serviço retorna um resultado utilizável, seja por campos obrigatórios ausentes ou malformados, seja porque o registro está inacessível, acontece o seguinte:match_type permanece null, validation_type fica como not_enabled, um aviso COULD_NOT_PERFORM_DATABASE_VALIDATION é emitido e o recurso passa para In Review até que os dados sejam corrigidos. Nenhuma cobrança é feita pelos serviços ignorados.
Relacionados
- Visão geral da Validação de banco de dados: como a API funciona de ponta a ponta e quais registros são suportados.
- Métodos de correspondência: como os resultados 1×1 / 2×2 (
validation_type: one_by_one/two_by_two) são derivados. - Códigos de resultado: taxonomia completa por resultado, com códigos de detalhe específicos de cada país.
- Países e serviços suportados: todos os registros em produção, campos obrigatórios e preço por chamada.
- Avisos da Validação de banco de dados: o que informamos quando um serviço não pode ser executado.
- Modelos de dados: validação de banco de dados: schema canônico, campo a campo.