Pular para o conteúdo principal
A Validação de banco de dados da Didit cruza os dados de identidade de cada usuário com a fonte oficial de cada país: RENAPER (Argentina), Receita Federal (Brasil), Tribunal Electoral (Panamá, com correspondência facial biométrica), Junta Central Electoral (República Dominicana) e outras. A cobrança é feita por consulta bem-sucedida, sem mínimos mensais. Cada entrada em 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.
Relatório de Validação de banco de dados da Didit mostrando os tipos de correspondência e os campos da resposta do registro

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 array database_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 status geral do recurso, um valor de FeatureStatusChoices (Not Finished, Approved, Declined, In Review).
  • Um match_type consolidado (full_match, partial_match, no_match ou null quando 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 o validation_type derivado (one_by_one, two_by_two ou not_enabled, nunca null).
  • 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 o service_id/service_name do catálogo, o outcome_code neutro em relação ao fornecedor, um outcome_detail opcional, o mapa validation por campo e o source_data tratado, 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_id que 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 como database_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.
Um valor 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 pelo DatabaseValidationV3Serializer.

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 em validations[] 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 array validations[] 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 em source_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 um face_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.
Preencha o campo ausente na página de detalhes da sessão no Console. Ao salvar, a verificação é disparada novamente de forma automática e o aviso é removido se ela for bem-sucedida.

Relacionados

Última modificação em 1 de novembro de 2026