Avisos da Validação de base de dados e códigos de omissão

A funcionalidade de Validação de base de dados da Didit verifica dados de identidade em registos civis oficiais — RENAPER (Argentina), Receita Federal (Brasil), Tribunal Electoral (Panamá, biométrico), Junta Central Electoral (República Dominicana), e mais — faturada por consulta bem-sucedida sem mínimos mensais. Quando nenhum serviço consegue ser executado (campos obrigatórios em falta ou malformados, registo indisponível), o documento em si não pode ser verificado (não contém o identificador de que os serviços configurados precisam — por exemplo, um passaporte sem número de identificação nacional) ou o resultado agregado é inconclusivo (correspondência parcial, sem correspondência), a funcionalidade emite um aviso na sessão. Se o país emissor não estiver sequer ativado no fluxo, o passo é ignorado silenciosamente, sem aviso e sem qualquer cobrança. Esta página documenta todos os códigos de aviso, o que os aciona e como configurar a resposta do fluxo.

Visão geral

Os avisos são gerados tanto em sessões de fluxo como pela API autónoma (POST /v3/database-validation/). Todos os cinco riscos são etiquetados com a funcionalidade DATABASE_VALIDATION, surgem no relatório sob database_validations[].warnings[] e seguem a estrutura padrão do objeto de aviso (feature, risk, additional_data, log_type, short_description, long_description, node_id). Não existem acionadores automáticos e fixos de recusa para a Validação de base de dados. Os dois riscos relativos ao resultado da correspondência, o risco de documento substituído e o risco de não aplicabilidade associam-se a uma ação configurável (DECLINE, REVIEW ou NO_ACTION); COULD_NOT_PERFORM_DATABASE_VALIDATION é o único comportamento fixo — encaminha sempre a funcionalidade para Em análise.

Riscos configuráveis

Definição	Código de risco	Comportamento
Ação para ausência de correspondência	`DATABASE_VALIDATION_NO_MATCH`	`REVIEW` (predefinição do fluxo) define a funcionalidade como Em análise; `DECLINE` recusa; `NO_ACTION` regista o aviso sem afetar o estado. O parâmetro `no_match_action` da API autónoma tem como predefinição `DECLINE`.
Ação para correspondência parcial	`DATABASE_VALIDATION_PARTIAL_MATCH`	`NO_ACTION` (predefinição) regista o aviso sem afetar o estado; `REVIEW` define a funcionalidade como Em análise; `DECLINE` recusa.
Ação para ausência de correspondência	`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Partilha a definição de Ação para ausência de correspondência — não existe um seletor separado. O registo contradisse o que foi submetido; logo, uma organização que recuse em caso de ausência de correspondência também recusa quando a credencial está obsoleta.
Ação de não aplicabilidade	`DATABASE_VALIDATION_NOT_APPLICABLE`	`NO_ACTION` (predefinição) regista o aviso sem afetar o estado; `REVIEW` define a funcionalidade como Em análise; `DECLINE` recusa. É acionado quando o documento não pode de todo ser verificado — não contém o identificador que os serviços configurados consultam (por exemplo, um passaporte sem número de identificação nacional).

A ação configurada também determina o log_type do aviso: DECLINE → error, REVIEW → warning, NO_ACTION → information. O resultado de correspondência em si é agregado a partir das entradas de validation por 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 conhecer a lógica de decisão completa que obtém 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 base de dados	Nenhum serviço devolveu um resultado utilizável (`match_type` permanece `null`) — normalmente porque faltam campos obrigatórios ou estes estão malformados, ou o registo devolveu um erro. O campo `additional_data` contém o resumo, por serviço, dos motivos pelos quais o serviço foi ignorado (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`); a API autónoma utiliza `{ "validation_errors": [...] }`. Não lhe é cobrado nada quando este aviso é acionado; a funcionalidade passa para em análise até que os dados sejam corrigidos.
`DATABASE_VALIDATION_NOT_APPLICABLE`	Validação de base de dados não aplicável a este documento	O documento fornecido não contém o identificador exigido pelos serviços de base de dados configurados (`match_type` permanece `null`) — por exemplo, um passaporte brasileiro não contém CPF, pelo que o registo de CPF não pode ser consultado. Isto é esperado para o tipo de documento e não indica um problema com o documento. O campo `additional_data` contém o resumo, por serviço, dos motivos pelos quais o serviço foi ignorado. Não lhe é cobrado nada quando este aviso é acionado. Ação configurável (o valor predefinido é `NO_ACTION`).
`DATABASE_VALIDATION_PARTIAL_MATCH`	Correspondência parcial na validação de base de dados	O `match_type` agregado é `partial_match` — alguns campos verificados coincidiram com os dados do registo, mas não todos. Ação configurável (o valor predefinido é `NO_ACTION`).
`DATABASE_VALIDATION_NO_MATCH`	Sem correspondência na validação de base de dados	O `match_type` agregado é `no_match` — o registo não conseguiu confirmar a identidade verificada. Ação configurável (o valor predefinido é `REVIEW` em fluxos, `DECLINE` na API autónoma).
`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Edição de documento substituída	Um serviço devolveu `DOCUMENT_SUPERSEDED`: o registo confirmou a pessoa, mas a edição do documento apresentado não é a que consta no registo — entretanto foi emitida uma edição mais recente. É emitido independentemente do `match_type`, que permanece `full_match` porque todos os campos pessoais coincidiram, pelo que o resultado, de outro modo, ficaria invisível. O campo `additional_data` indica os serviços que o reportaram. Segue a definição No Match Action.

O aviso COULD_NOT_PERFORM_DATABASE_VALIDATION cobre duas situações diferentes, e o campo long_description do aviso (e, para uma falha por serviço, database_validation_errors[].message) indica agora qual delas se aplicou em vez de apresentar uma única frase genérica: os dados verificados estavam em falta ou malformados antes de qualquer serviço poder ser consultado, ou um serviço foi consultado e não devolveu um resultado utilizável. No segundo caso, quando o registo reportou o seu próprio detalhe de diagnóstico para essa tentativa, esse detalhe é incluído na mensagem para que não tenha de contactar o suporte para saber o motivo. O serviço a montante nunca é identificado na resposta.

Quando COULD_NOT_PERFORM_DATABASE_VALIDATION ou DATABASE_VALIDATION_NOT_APPLICABLE é acionado numa sessão de fluxo, a verificação é automaticamente acionada de novo assim que os dados em falta forem preenchidos na página de detalhes da sessão na Console — guardar o campo executa novamente a validação, e o aviso é removido em caso de sucesso. Isto também funciona quando a ação configurada para este aviso recusou a sessão, pelo que uma sessão recusada pode ser remediada através da correção dos dados. Para DATABASE_VALIDATION_NOT_APPLICABLE, a nova execução ajuda quando o documento pode conter o identificador mas este não foi lido (por exemplo, um título de residência cujo número de identificação nacional não foi extraído); os tipos de documento que nunca contêm o identificador (por exemplo, passaportes sem número de identificação nacional) mantêm o aviso. Não é cobrada qualquer taxa pelos serviços ignorados; apenas paga quando um serviço devolve um resultado faturá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 avisos

Cada risco tem atribuída uma gravidade com base na configuração da sua aplicação. As gravidades dividem-se em três categorias:

Relacionados

Visão geral da validação de base de dados — como a funcionalidade funciona de ponta a ponta e quais os registos suportados.
Relatório de validação de base de dados — formato completo 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 de 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 suportados — todos os registos em produção, campos obrigatórios e preço por chamada.
Modelos de dados — validação de base de dados — esquema canónico campo a campo.

Autenticação

Verificação

Monitorização

Plataforma

Avisos da Validação de base de dados e códigos de omissão

Visão geral

Riscos configuráveis

Avisos gerados

Exemplo

Tipos de avisos

Relacionados

​Visão geral

​Riscos configuráveis

​Avisos gerados

​Exemplo

​Tipos de avisos

​Relacionados

Visão geral

Riscos configuráveis

Avisos gerados

Exemplo

Tipos de avisos

Relacionados