> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Relatório de validação em base de dados: resposta JSON > Leia a resposta de validação em base de dados da Didit: resultado por serviço, dados da fonte, pontuação facial e avisos. Desde $0.05 por consulta. A [Validação de banco de dados](https://docs.didit.me/pt-br/core-technology/database-validation/overview.md) 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](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-report.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=56284966659e33d1c74385647537e5d9) ## 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`](https://docs.didit.me/pt-br/reference/data-models#referência-do-enum-de-status) (`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](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-matching-methods.md). * 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](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-warnings.md)). * 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. ```json theme={null} { "session_id": "11111111-1111-1111-1111-111111111111", "status": "Approved", "database_validations": [ { "node_id": "feature_db_validation_1", "status": "Approved", "...": "..." } ] } ``` 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](https://docs.didit.me/pt-br/reference/data-models.md#validação-de-banco-de-dados). Ele é gerado pelo `DatabaseValidationV3Serializer`. ```typescript theme={null} interface DatabaseValidation { node_id: string | null; status: "Not Finished" | "Approved" | "Declined" | "In Review"; // FeatureStatusChoices issuing_state: string | null; // ISO 3166-1 alpha-3, e.g. "ARG" validation_type: "one_by_one" | "two_by_two" | "not_enabled"; // derived, never null match_type: "full_match" | "partial_match" | "no_match" | null; // null when no service returned a usable result screened_data: { // What we sent to the registry (varies by country/service) tax_number?: string; personal_number?: string; document_number?: string; first_name?: string; last_name?: string; date_of_birth?: string; // YYYY-MM-DD selfie?: string; // Presigned URL (biometric services) cnh_qr_code_image?: string; // Presigned URL (Brazil CNH QR + face match) document_image?: string; // Presigned URL (services that take a document image) gender?: string; // Biometric registry services (e.g. Argentina RENAPER) }; validations: Array<{ // Catalog metadata service_id?: string; // e.g. "arg_renaper" service_name?: string; // e.g. "Argentina - DNI verification (RENAPER)" // Per-field match outcome — keys vary by service // (full_name, first_name, last_name, date_of_birth, identification_number, address, …) validation?: Record; outcome_code?: string; // Vendor-neutral outcome, see below outcome_detail?: string; // Raw upstream status detail backing the outcome code source_data?: { // Cleaned registry record identification_number?: string; first_name?: string; last_name?: string; full_name?: string; date_of_birth?: string; place_of_birth?: string; gender?: string; nationality?: string; issue_date?: string; expiration_date?: string; photo?: string; // Pre-signed JPEG URL signature?: string; // Pre-signed JPEG URL face_match_score?: number; // Biometric services only (0-100) }; }>; errors?: Array<{ // Omitted entirely when empty service_id: string; code?: string; // e.g. "invalid_screened_data", "empty_provider_response" message?: string; missing_required_fields?: string[]; invalid_format_fields?: string[]; field_reasons?: Record; }>; warnings: Warning[]; // See /reference/data-models#warning-object } ``` ### Valores de status `status` usa o enum padrão de nível de recurso (consulte [Enums de status](https://docs.didit.me/pt-br/reference/data-models.md#referência-do-enum-de-status)). Veja a [referência do enum de status](https://docs.didit.me/pt-br/reference/data-models.md#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. | Status | Significado | | - | - | | `Not Finished` | A validação ainda não produziu resultado (estado inicial; também registrado quando uma chamada avulsa falha em todos os serviços). | | `Approved` | Nenhum risco foi disparado, ou os únicos riscos disparados estão configurados como `NO_ACTION` (o padrão para correspondência parcial). | | `Declined` | Um resultado sem correspondência ou com correspondência parcial cuja ação configurada é `DECLINE`. | | `In Review` | Um resultado sem correspondência ou com correspondência parcial cuja ação configurada é `REVIEW`, ou a validação não pôde ser executada (`COULD_NOT_PERFORM_DATABASE_VALIDATION`, sempre vai para revisão). | Regras de status personalizadas por nó são aplicadas sobre esse status base. Consulte [Avisos da Validação de banco de dados](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-warnings.md) 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](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-outcome-codes.md). ### 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](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-matching-methods.md). ### 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) ```json theme={null} { "node_id": "feature_db_validation_1", "status": "Approved", "issuing_state": "BRA", "validation_type": "one_by_one", "match_type": "full_match", "screened_data": { "tax_number": "12345678900", "first_name": "John", "last_name": "Doe", "date_of_birth": "1980-01-01" }, "validations": [ { "service_id": "bra_cpf", "service_name": "Brazil - CPF status check", "outcome_code": "MATCH", "outcome_detail": "200", "validation": { "full_name": "full_match", "date_of_birth": "full_match", "identification_number": "full_match" }, "source_data": { "identification_number": "12345678900", "first_name": "JOHN", "last_name": "DOE", "date_of_birth": "1980-01-01", "lgpd_minor": false, "minor_under_16": false, "minor_under_18": false } } ], "warnings": [] } ``` ### 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. ```json theme={null} { "node_id": "feature_db_validation_1", "status": "Approved", "issuing_state": "ARG", "validation_type": "one_by_one", "match_type": "full_match", "screened_data": { "document_number": "12345678", "selfie": "https:///sessions//selfie.jpg?X-Amz-Signature=...", "gender": "M", "first_name": "John", "last_name": "Doe" }, "validations": [ { "service_id": "arg_renaper", "service_name": "Argentina - DNI verification (RENAPER)", "outcome_code": "MATCH", "validation": { "full_name": "full_match", "identification_number": "full_match" }, "source_data": { "identification_number": "12345678", "first_name": "John", "last_name": "Doe", "full_name": "John Doe", "date_of_birth": "1990-01-01", "tax_id": "20000000019", "tax_id_type": "CUIT", "face_match_score": 97 } } ], "warnings": [] } ``` ### 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. ```json theme={null} { "node_id": "feature_db_validation_1", "status": "In Review", "issuing_state": "PAN", "validation_type": "not_enabled", "match_type": null, "screened_data": { "first_name": "John", "last_name": "Doe", "date_of_birth": "1990-01-01", "selfie": "https:///sessions//selfie.jpg?X-Amz-Signature=..." }, "validations": [], "errors": [ { "code": "invalid_screened_data", "message": "Database validation was skipped before calling the provider because the screened data has missing required fields: personal_number.", "missing_required_fields": ["personal_number"], "service_id": "pan_cedula_sib_plus" } ], "warnings": [ { "feature": "DATABASE_VALIDATION", "risk": "COULD_NOT_PERFORM_DATABASE_VALIDATION", "additional_data": { "reason": "Database validation was skipped before any provider request because the screened data is incomplete or invalid.", "database_validation_errors": [ { "code": "invalid_screened_data", "message": "Database validation was skipped before calling the provider because the screened data has missing required fields: personal_number.", "missing_required_fields": ["personal_number"], "service_id": "pan_cedula_sib_plus" } ], "missing_required_fields_by_service": { "pan_cedula_sib_plus": ["personal_number"] }, "invalid_format_fields_by_service": {}, "field_reasons_by_service": {} }, "log_type": "warning", "short_description": "Could not perform database validation", "long_description": "The system couldn't perform the database validation, please fill the required fields for this country to automatically proceed with database validation.", "node_id": "feature_db_validation_1" } ] } ``` 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 * [Visão geral da Validação de banco de dados](https://docs.didit.me/pt-br/core-technology/database-validation/overview.md): como a API funciona de ponta a ponta e quais registros são suportados. * [Métodos de correspondência](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-matching-methods.md): como os resultados 1×1 / 2×2 (`validation_type: one_by_one` / `two_by_two`) são derivados. * [Códigos de resultado](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-outcome-codes.md): taxonomia completa por resultado, com códigos de detalhe específicos de cada país. * [Países e serviços suportados](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-supported-countries.md): todos os registros em produção, campos obrigatórios e preço por chamada. * [Avisos da Validação de banco de dados](https://docs.didit.me/pt-br/core-technology/database-validation/database-validation-warnings.md): o que informamos quando um serviço não pode ser executado. * [Modelos de dados: validação de banco de dados](https://docs.didit.me/pt-br/reference/data-models.md#validação-de-banco-de-dados): schema canônico, campo a campo. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.