Avisos de validação em base de dados e códigos de omissão

O recurso de Validação de banco de dados da Didit verifica dados de identidade em registros civis oficiais, como RENAPER (Argentina), Receita Federal (Brasil), Tribunal Electoral (Panamá, biométrico), Junta Central Electoral (República Dominicana) e outros. A cobrança é feita por consulta bem-sucedida, sem cobrança mínima mensal. Quando nenhum serviço pode ser executado (campos obrigatórios ausentes ou malformados, registro indisponível), quando o próprio documento não pode ser verificado (ele não contém o identificador de que os serviços configurados precisam, por exemplo, um passaporte sem número de identidade nacional) ou quando o resultado agregado não é conclusivo (correspondência parcial, sem correspondência), o recurso emite um aviso na sessão. Se o Estado emissor não estiver habilitado no fluxo de verificação (workflow), a etapa é ignorada silenciosamente, sem aviso e sem cobrança. Esta página documenta cada código de aviso, o que o aciona e como configurar a resposta do fluxo.

Visão geral

Os avisos são gerados tanto em sessões de workflow quanto pela API independente (POST /v3/database-validation/). Todos os cinco riscos são marcados com o recurso DATABASE_VALIDATION, aparecem no relatório em database_validations[].warnings[] e seguem o formato padrão do objeto de aviso (feature, risk, additional_data, log_type, short_description, long_description, node_id). Não há gatilhos fixos de recusa automática para a Validação de banco de dados. Os dois riscos de resultado de correspondência, o risco de documento substituído e o risco de não aplicabilidade são associados a uma ação configurável (DECLINE, REVIEW ou NO_ACTION); COULD_NOT_PERFORM_DATABASE_VALIDATION é o único comportamento fixo: ele sempre encaminha o recurso para In Review.

Riscos configuráveis

Configuração	Código de risco	Comportamento
No Match Action	`DATABASE_VALIDATION_NO_MATCH`	`REVIEW` (padrão do fluxo) define o recurso como Em Revisão; `DECLINE` recusa; `NO_ACTION` registra o aviso sem afetar o status. Na API independente, o parâmetro `no_match_action` tem `DECLINE` como padrão.
Partial Match Action	`DATABASE_VALIDATION_PARTIAL_MATCH`	`NO_ACTION` (padrão) registra o aviso sem afetar o status; `REVIEW` define o recurso como Em Revisão; `DECLINE` recusa.
No Match Action	`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Compartilha a configuração No Match Action; não há um ajuste separado. O registro contradisse o que foi enviado, então uma organização que recusa em caso de ausência de correspondência também recusa uma credencial desatualizada.
Not Applicable Action	`DATABASE_VALIDATION_NOT_APPLICABLE`	`NO_ACTION` (padrão) registra o aviso sem afetar o status; `REVIEW` define o recurso como Em Revisão; `DECLINE` recusa. É acionado quando o documento não pode ser verificado de forma alguma, porque não contém o identificador usado pelos serviços configurados para consulta (por exemplo, um passaporte sem número de identidade nacional).

A ação configurada também determina o log_type do aviso: DECLINE → error, REVIEW → warning, NO_ACTION → information. O próprio resultado de correspondência é agregado a partir das entradas validation de cada serviço (qualquer correspondência total → full_match; caso contrário, qualquer parcial → partial_match; caso contrário, no_match). Consulte Métodos de correspondência para ver a lógica de decisão completa que gera os resultados 1×1 / 2×2.

Avisos gerados

Tag	Descrição curta	Descrição
`COULD_NOT_PERFORM_DATABASE_VALIDATION`	Não foi possível realizar a validação de banco de dados	Nenhum serviço retornou um resultado utilizável (`match_type` permanece `null`), geralmente porque campos obrigatórios estão ausentes ou malformados, ou porque o registro retornou um erro. `additional_data` traz o resumo dos serviços ignorados, por serviço (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`); a API autônoma usa `{ "validation_errors": [...] }` no lugar. Você não é cobrado quando este aviso é gerado; o recurso passa para In Review até que os dados sejam corrigidos.
`DATABASE_VALIDATION_NOT_APPLICABLE`	Validação de banco de dados não aplicável a este documento	O documento fornecido não contém o identificador exigido pelo(s) serviço(s) de banco de dados configurado(s) (`match_type` permanece `null`). Por exemplo, um passaporte brasileiro não contém CPF, então o registro de CPF não pode ser consultado. Isso é esperado para o tipo de documento e não indica um problema com o documento. `additional_data` traz o resumo dos serviços ignorados, por serviço. Você não é cobrado quando este aviso é gerado. Ação configurável (padrão `NO_ACTION`).
`DATABASE_VALIDATION_PARTIAL_MATCH`	Correspondência parcial na validação de banco de dados	O `match_type` agregado é `partial_match`: alguns dos campos verificados corresponderam ao registro, mas não todos. Ação configurável (padrão `NO_ACTION`).
`DATABASE_VALIDATION_NO_MATCH`	Nenhuma correspondência na validação de banco de dados	O `match_type` agregado é `no_match`: o registro não conseguiu confirmar a identidade verificada. Ação configurável (padrão `REVIEW` em fluxos de verificação (workflows), `DECLINE` na API autônoma).
`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Edição do documento substituída	Um serviço retornou `DOCUMENT_SUPERSEDED`: o registro confirmou a pessoa, mas a edição do documento apresentado não é a que consta nos registros, pois uma edição mais recente foi emitida desde então. É gerado independentemente do `match_type`, que permanece `full_match` porque todos os campos pessoais corresponderam; caso contrário, a constatação ficaria invisível. `additional_data` informa os serviços que a reportaram. Segue a configuração No Match Action.

COULD_NOT_PERFORM_DATABASE_VALIDATION abrange duas situações diferentes, e o long_description do aviso (e, no caso de uma falha por serviço, database_validation_errors[].message) agora indica qual delas se aplicou, em vez de uma única frase genérica: os dados verificados estavam ausentes ou malformados antes que qualquer serviço pudesse ser consultado, ou um serviço foi consultado e não retornou um resultado utilizável. No segundo caso, quando o registro informou seu próprio detalhe de diagnóstico para aquela tentativa, esse detalhe é incluído na mensagem, para que você não precise entrar em contato com o suporte para saber o motivo. O serviço de origem nunca é nomeado na resposta.

Quando COULD_NOT_PERFORM_DATABASE_VALIDATION ou DATABASE_VALIDATION_NOT_APPLICABLE é gerado em uma sessão de workflow, a verificação é acionada novamente de forma automática assim que os dados ausentes são preenchidos na página de detalhes da sessão no Console: salvar o campo executa a validação novamente, e o aviso é removido em caso de sucesso. Isso também funciona quando a ação para casos não aplicáveis recusou a sessão, de modo que uma sessão recusada pode ser corrigida ajustando os dados. Para DATABASE_VALIDATION_NOT_APPLICABLE, a nova execução ajuda quando o documento pode conter o identificador, mas ele não foi lido (por exemplo, uma autorização de residência cujo número de identidade nacional não foi extraído); tipos de documento que nunca contêm o identificador (por exemplo, passaportes sem número de identidade nacional) mantêm o aviso. Nenhuma cobrança é aplicada aos serviços ignorados; você só paga quando um serviço retorna um resultado cobrável.

Exemplo

{
  "warnings": [
    {
      "feature": "DATABASE_VALIDATION",
      "risk": "DATABASE_VALIDATION_NO_MATCH",
      "additional_data": null,
      "log_type": "warning",
      "short_description": "Database validation no match",
      "long_description": "The system identified a no match in the database validation, requiring further investigation.",
      "node_id": "feature_db_validation_1"
    }
  ]
}

Tipos de aviso

Cada risco recebe uma severidade com base na configuração da sua aplicação. As severidades se dividem em três categorias:

Relacionados

Visão geral da Validação de banco de dados: como o recurso funciona de ponta a ponta e os registros compatíveis.
Relatório de Validação de banco de dados: estrutura completa da resposta, incluindo validations[] por serviço.
Métodos de correspondência: como os resultados 1×1 / 2×2 (validation_type: one_by_one / two_by_two) são derivados das correspondências por serviço.
Códigos de resultado: taxonomia completa por resultado, com códigos de detalhe específicos por país.
Países e serviços compatíveis: todos os registros em produção, campos obrigatórios e preço por chamada.
Modelos de dados: validação de banco de dados: esquema canônico, campo a campo.

Autenticação

Verificação

Monitoramento

Plataforma

Avisos de validação em base de dados e códigos de omissão

Visão geral

Riscos configuráveis

Avisos gerados

Exemplo

Tipos de aviso

Relacionados

​Visão geral

​Riscos configuráveis

​Avisos gerados

​Exemplo

​Tipos de aviso

​Relacionados

Visão geral

Riscos configuráveis

Avisos gerados

Exemplo

Tipos de aviso

Relacionados