> ## 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. # Validação de base de dados: KYC em registos oficiais > A API da Didit valida em registos oficiais desde $0.05/check em 60+ países, com correspondência facial biométrica onde existir foto no registo. A **Validação de base de dados** da Didit verifica os dados de identidade de uma pessoa face à fonte oficial desse país — o registo civil nacional, a autoridade tributária, o caderno eleitoral, uma central de crédito ou o registo biométrico que emitiu originalmente o documento. Cada verificação devolve uma correspondência campo a campo (`identification_number`, `first_name`, `last_name`, `date_of_birth` e campos de morada quando o serviço os utiliza), para além de um resultado agregado e dos detalhes do registo subjacente quando disponíveis.É a defesa mais sólida contra a fraude de identidade sintética: um DNI ou CPF real roubado falhará a consulta no registo, e um número fabricado não constará de todo na base de dados oficial. A Validação de base de dados combina-se com a nossa correspondência facial biométrica em países onde o registo possui uma fotografia oficial arquivada (Argentina via RENAPER, Panamá via Tribunal Electoral SIB / SIB Plus), para que possa confirmar não apenas que um número é real, mas que a **pessoa em frente à câmara é titular do mesmo**. Prompt de integração de Validação de base de dados \

\````# Goal
Integrate Didit Database Validation (verify identity data against authoritative national registries) into your app. Pick ONE mode.

\# Mode A — Session-based
Use this when Database Validation runs as a step in a hosted Didit flow. Fields are auto-fed into the registry lookup from the steps in front of it — ID Verification, NFC, Liveness, Phone/Email Verification, Proof of Address, Document AI or a Questionnaire. An ID Verification step is not required.

1\. Add the DATABASE_VALIDATION feature to the workflow (Business Console or POST /v3/workflows/). Optionally pin specific services per country.
2\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. See /sessions-api/create-session.
3\. Open session.url for the user (or mount the Web/Mobile SDK).
4\. Fetch the decision — GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated.

Decision surface: `database_validations[]` array on the decision payload.

\# Mode B — Standalone API (server-to-server)
Use when you already have the identity data and want a one-shot registry check.

POST https://verification.didit.me/v3/database-validation/
multipart/form-data — x-api-key: YOUR_API_KEY

curl example (Brazil CPF):
\```bash
curl -X POST 'https://verification.didit.me/v3/database-validation/' \
-H "x-api-key: $DIDIT_API_KEY" \
-F "issuing_state=BRA" \
-F "identification_number=00000000191" \
-F "first_name=Jane" \
-F "last_name=Doe" \
-F "date_of_birth=1990-01-15" \
-F "vendor_data=user-1234"
\```
Returns: { request_id, database_validation: { match_type: "full_match"|"partial_match"|"no_match", validation_type, services_used, match_score, validations: [{ service, status, matched_fields, record_details }], warnings: [...] } }.

\# Important behaviour
\- Use `identification_number` (universal field) — Didit maps it to CPF/RUT/CURP/DNI/etc. by issuing_state.
\- Omit `services` to run the country's default service only. Pass `services=["bra_cpf"]` (etc.) to choose which services run — list several to run more than one.
\- Argentina (`arg_renaper`) and Panama (`pan_sib`) take an extra `selfie` (JPG/PNG/WebP up to 2 MB) and `gender` for biometric face-match against the registry photo.
\- Services flagged `requires_consent=true` in the catalog require `consent=true` (HTTP 400 otherwise).
\- Billing is **per successful service hit** — multi-service requests can produce multiple usage events.

\# Status / match_type
status: "Approved" | "In Review" | "Declined" (per the partial-match / no-match actions configured on the workflow)
match_type: "full_match" | "partial_match" | "no_match"

\# Warnings (LogWarningChoices.DATABASE_VALIDATION)
warnings[] risk codes include:
DATABASE_VALIDATION_NO_MATCH, DATABASE_VALIDATION_PARTIAL_MATCH, COULD_NOT_PERFORM_DATABASE_VALIDATION (biometric outcomes surface via per-service outcome_code, e.g. BIOMETRIC_NO_MATCH).
Full catalogue: /core-technology/database-validation/database-validation-warnings.

\# Failure modes to handle
\- HTTP 400 — service id not eligible for issuing_state, missing required field, missing consent for PAYGO services.
\- HTTP 502 with validation_errors[] — every selected upstream service failed; request is **not billed** and a COULD_NOT_PERFORM_DATABASE_VALIDATION log is written. Retry later or fall back to OCR-only.
\- match_type="no_match" — record not in registry; treat as synthetic identity per policy.
\- match_type="partial_match" — some fields match, others don't (e.g. DOB matches, name doesn't); route to review.

\# See also
\- Canonical schema: /reference/data-models#database-validation
\- Per-feature report: /core-technology/database-validation/database-validation-report
\- Risk catalogue: /core-technology/database-validation/database-validation-warnings
\- Outcome codes: /core-technology/database-validation/database-validation-outcome-codes
\- Full integration playbook: /integration/integration-prompt````

\
## Porquê a Didit- **Preços mais baixos por chamada.** Desde **\$0.05** por verificação (República Dominicana) até **\$7.00** para as fontes especializadas mais dispendiosas. O preço é definido por serviço e não por país — um registo que cobra uma tarifa grossista elevada tem o preço ajustado em conformidade (o documento de identificação nacional da Finlândia custa **\$2.10**). Consulte sempre a tarifa para o serviço exato que planeia chamar na [tabela de preços por serviço](https://docs.didit.me/pt/getting-started/database-validation-pricing.md). Sem mínimos mensais, sem taxas de plataforma, sem faturação por lugar — cobram-se apenas as consultas bem-sucedidas. - **A mais rápida de integrar.** [Registe-se](https://business.didit.me/), obtenha uma chave de API na consola e poderá chamar `POST /v3/database-validation/` em poucos minutos. Sem chamadas comerciais, sem ciclos de contratação, sem burocracia de prova de conceito — a Didit funciona totalmente em regime de autosserviço. - **Consultas diretas à fonte oficial.** RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — e não extrações de agregadores. - **Correspondência facial biométrica quando o registo tem uma fotografia oficial arquivada.** Confiança superior à do OCR sem trabalho adicional de integração. - **Latência adequada para produção.** p95 tipicamente abaixo de 1.5 s de ponta a ponta, 99.9% de disponibilidade trimestral.A aula da Academy sobre a leitura de um resultado de verificação aborda a validação de base de dados às 11:05 e apresenta resultados de correspondência total, parcial e sem correspondência.[Validação de base de dados: correspondência total, parcial e sem correspondência — Didit Academy](https://www.youtube.com/embed/7htTWCWsl60?start=665\&rel=0\&playsinline=1)## Cobertura globalPasse o cursor sobre qualquer país destacado para ver todos os serviços de Validação de base de dados que disponibilizamos nesse país, o domínio de dados (Identidade, Financeiro, Biométrico, Morada, Telecomunicações, …) e o preço por chamada. Os países ativos já se encontram prontos para produção hoje; os restantes são integrados a pedido assim que um cliente o solicitar.Live Database Validation coverageProduction-ready countries and the cheapest live service available in each.LIVE
Show on-demand catalog countries ()
> [!TIP] > > **Não encontra o seu país?** Fale connosco — o nosso catálogo abrange 60+ países com centenas de serviços que ativamos a pedido assim que um cliente necessitar. Novas integrações ficam normalmente ativas em 2–3 semanas.## Como é executada uma Validação de base de dadosUma Validação de base de dados nunca é acionada de forma especulativa. Só é executada quando **todas** as seguintes condições se verificam:1) A sessão determinou um país para consultar — a partir do `issuing_state` de uma [Verificação de identidade](https://docs.didit.me/pt/core-technology/id-verification/overview.md) ou, quando o fluxo de verificação (workflow) não inclui um passo de Verificação de identidade, a partir do país único para o qual o passo de Validação de base de dados está configurado. 2) Esse país tem pelo menos um serviço de Validação de base de dados ativado no fluxo. 3) Os passos anteriores ao passo de Validação de base de dados forneceram **todos os campos obrigatórios** de que o serviço escolhido necessita.Se um serviço estiver ativado mas os campos obrigatórios nunca tiverem chegado (por exemplo, o CPF não pôde ser extraído de um RG brasileiro manchado), o serviço é ignorado, **não lhe é cobrado qualquer valor** e é emitido um aviso na sessão: `DATABASE_VALIDATION_NOT_APPLICABLE` quando o documento simplesmente não inclui o identificador pelo qual esse serviço consulta, ou `COULD_NOT_PERFORM_DATABASE_VALIDATION` quando o identificador deveria estar disponível, mas não estava. Ambos estão listados no [catálogo de avisos](https://docs.didit.me/pt/core-technology/database-validation/database-validation-warnings.md).Alguém da sua equipa com acesso de revisão à sessão pode preencher manualmente o campo em falta a partir da página de detalhes da sessão na Console; guardar a alteração aciona novamente a verificação de forma automática. Esta é uma ação de revisor e não algo que o utilizador final possa fazer — para permitir que o **utilizador** forneça um campo que o seu documento não contém, solicite-o num Questionário (ou numa extração com o Document AI, ou num valor enviado quando cria a sessão) e mapeie-o no passo de Validação de base de dados, tal como descrito abaixo.### A Validação de base de dados não requer uma Verificação de identidadeAnteriormente, um passo de Validação de base de dados pressupunha a existência de um passo de Verificação de identidade antes dele, uma vez que o OCR de um documento de identificação era a única forma integrada de obter os dados do utilizador final. Já não é esse o caso: **cada campo obrigatório declara que passos o podem fornecer**, e um serviço fica disponível assim que o seu fluxo contiver um passo que forneça todos os campos de que necessita.| Fonte de entrada | Fornece | | - | - | | Verificação de identidade | Nomes, data de nascimento, morada, número do documento/número pessoal e os identificadores específicos de cada país impressos num documento de identificação (número de identificação fiscal, documento de identificação nacional, número de passaporte, número da carta de condução, …) | | NFC | O subconjunto dos dados acima lido a partir do chip, com maior nível de confiança | | Prova de vida | A selfie em tempo real, para serviços de registo biométrico facial | | Verificação de telefone | O número de telefone verificado | | Verificação de e-mail | O endereço de e-mail verificado | | Comprovativo de morada | A morada de residência verificada e os seus componentes | | Document AI | Qualquer campo que mapeie para uma das suas chaves de campos de extração | | Questionário | Qualquer campo que mapeie para uma das suas perguntas | | Entrada via API | Qualquer valor, na API autónoma — o emissor da chamada fornece os valores diretamente |Isto significa que um **serviço biométrico facial pode ser executado apenas a partir de um passo de Prova de vida**, sem qualquer documento de identificação no fluxo, e um serviço baseado num número de identificação fiscal, número de telefone ou e-mail pode ser satisfeito a partir da resposta a um questionário, de um passo de Verificação de telefone/e-mail ou de uma extração do Document AI.Duas regras garantem a segurança deste processo:- **Um fluxo sem Verificação de identidade tem de configurar exatamente um país** no passo de Validação de base de dados. Sem um `issuing_state` de um documento, esse é o único sinal inequívoco sobre qual o registo nacional a consultar, pelo que uma configuração de vários países sem Verificação de identidade não executa nada em vez de tentar adivinhar. - **A verificação de campos obrigatórios mantém-se inalterada.** Um serviço cujos campos não estejam todos presentes no momento da execução é ignorado antes de qualquer fornecedor ser consultado, pelo que nunca é faturado por uma base de dados que nunca chegou a ser consultada.#### Mapear campos do Document AI e de questionáriosOs campos de extração do Document AI e as perguntas de questionários utilizam os nomes de chave que definiu, não os da Didit. Uma chave que corresponda exatamente ao nome de entrada de uma Validação de base de dados (`tax_number`, `date_of_birth`, `phone`, …) é mapeada automaticamente e não requer configuração. Para qualquer outra chave, o editor de fluxos apresenta um seletor no passo de Validação de base de dados para os campos ainda por preencher, onde aponta cada um deles para a chave de campo do Document AI ou para a resposta do questionário que o fornece.Na Console, um serviço que o seu fluxo ainda não consiga executar é apresentado como desativado com o respetivo motivo — que campos estão em falta e que passo os forneceria — e o editor oferece-se para adicionar esse passo. Adicioná-lo ativa de imediato todos os serviços que desbloqueia.> [!TIP] > > **Exemplo prático — um identificador que o documento não contém.** O serviço de identificação nacional da Nigéria efetua consultas através do NIN de 11 dígitos, que frequentemente não se encontra impresso nos documentos que os utilizadores carregam, pelo que depender apenas do documento de identificação faz com que a verificação seja ignorada por não ser aplicável para uma grande parte dos utilizadores. Adicione um passo de **Questionário** antes do passo de Validação de base de dados a solicitar o NIN e, em seguida, mapeie `national_id` para essa pergunta no passo de Validação de base de dados. Este mesmo mapeamento permite que um identificador que nunca consta num documento — como um número de verificação bancária ou um número de registo de empresa — possa ser utilizado dentro de um fluxo.Para serviços baseados em moradas, a Didit divide automaticamente o campo único `address` do documento de identificação em elementos de morada estruturados:| Campo da Didit | Significado | | - | - | | `address_element_1` | Morada de rua, incluindo número de polícia e tipo de via | | `address_element_2` | Fração, edifício, piso ou linha de morada adicional opcional | | `address_element_3` | Subúrbio, distrito, localidade ou bairro | | `address_element_4` | Cidade, localidade, estado, província ou região | | `address_element_5` | Código postal |Ao chamar a API autónoma, pode enviar um único campo `address` ou estes campos estruturados diretamente. Quando ambos estão presentes, os campos estruturados têm prioridade. Os serviços que exigem pesquisa de morada necessitam de `address_element_1` mais pelo menos um outro elemento de morada; se a Didit não conseguir derivá-los do documento de identificação ou do Comprovativo de morada no fluxo, o serviço é ignorado e não é faturado.Se o país determinado não estiver de todo ativado, o passo é ignorado silenciosamente, sem aviso e sem custos.![Fluxo de validação de base de dados da Didit que verifica os dados do utilizador em registos de identidade governamentais](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-how-it-works.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=3d5bb0df058265af0d8728cd60a78416)## O resultado de correspondênciaCada serviço ativado devolve uma validação por campo:| Campo | Resultados | | - | - | | `identification_number` | `full_match` · `partial_match` · `no_match` | | `first_name` | `full_match` · `partial_match` · `no_match` | | `last_name` | `full_match` · `partial_match` · `no_match` | | `date_of_birth` | `full_match` · `no_match` | | `address` | `full_match` · `partial_match` · `no_match` |O `match_type` agregado resume-se a:- **`full_match`** — todos os campos solicitados coincidem com pelo menos uma fonte. - **`partial_match`** — alguma correspondência; reencaminhe para uma fila de revisão de acordo com as regras do seu fluxo. - **`no_match`** — nenhuma fonte confirmou os dados; geralmente recusar.## Como a correspondência é derivada (1×1 / 2×2)Já não lhe pedimos que escolha previamente "1×1" ou "2×2" — esses valores são derivados de quantos serviços distintos obtiveram uma correspondência total com os dados de entrada:- **Resultado 1×1** — um serviço devolveu uma correspondência total (uma única fonte oficial confirmou os dados). - **Resultado 2×2** — dois ou mais serviços devolveram uma correspondência total (corroboração independente; a pontuação de confiança mais elevada que podemos expressar).Um fluxo pode ativar qualquer número de serviços por país; a faturação é feita por serviço que efetivamente devolveu um resultado. Os serviços cujos campos obrigatórios não puderam ser extraídos são ignorados sem qualquer custo.➡️ Consulte **[Métodos de Correspondência](https://docs.didit.me/pt/core-technology/database-validation/database-validation-matching-methods.md)** para obter a lógica de decisão completa e como esta interage com `partialMatchAction` / `noMatchAction`.## Validação de Base de Dados BiométricaOs registos civis de alguns países disponibilizam um template biométrico (um retrato ou uma impressão digital). Quando disponível, associamos a consulta ao registo a uma **correspondência facial biométrica** com a selfie do utilizador:- **Argentina (`arg_renaper`)** — correspondência facial biométrica com a fotografia oficial do RENAPER em arquivo. Cobertura de 100% da população; todos os cidadãos argentinos com DNI constam da base de dados. - **Panamá (`pan_cedula_sib`, `pan_cedula_sib_plus`)** — correspondência facial biométrica com o serviço SIB do Tribunal Electoral. O SIB Plus é a variante de nível superior, com limiares biométricos mais rigorosos e metadados de correspondência mais ricos.Para estes serviços, o campo `selfie` é **obrigatório**. Dentro de um fluxo de sessão, reutilizamos a selfie de prova de vida (qualidade mais elevada) e recorremos ao retrato do documento como alternativa. Fora de uma sessão, ao chamar a API autónoma (`POST /v3/database-validation/`, Modo B acima), fornece o JPEG/PNG diretamente.## Enriquecimento global de identidade`glb_identity_enrichment` é um serviço de Validação de base de dados **global e exclusivo para modo autónomo**. A partir de um e-mail e/ou número de telefone, resolve pessoas associadas (nomes, datas de nascimento, moradas, telefones, e-mails e documentos de identificação nacionais) e devolve uma pontuação de correspondência de nome, mapeada para os [códigos de resultado](https://docs.didit.me/pt/core-technology/database-validation/database-validation-outcome-codes.md) padrão `MATCH` / `PARTIAL_MATCH` / `NO_MATCH` / `DOCUMENT_NOT_FOUND` (com o `match_type` correspondente de `full_match` / `partial_match` / `no_match`).Por ser um serviço global (`GLB`) baseado em e-mail/telefone e não no país emissor de um documento, **não está disponível no construtor de fluxos**. Chame-o diretamente através da API autónoma com `issuing_state` definido como `GLB`:```json theme={null} POST /v3/database-validation/ { "issuing_state": "GLB", "services": ["glb_identity_enrichment"], "email": "john.doe@example.com", "phone": "+14155552671" } ```A faturação é de **\$0.20 por pedido** (cobrada apenas quando o fornecedor devolve um resultado).## ConfiguraçãoA Validação de base de dados é configurada por fluxo a partir da Consola. Para cada país, seleciona os serviços específicos que pretende executar; os campos de entrada obrigatórios e opcionais derivam da união desses serviços. A ação aplicada aos resultados `partial_match` e `no_match` é configurada separadamente e pode ser `approve`, `review` ou `decline`.![Definições da consola de validação de bases de dados da Didit para selecionar serviços de registo por país e regras de resultados](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-console.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2e1ac27f07fa9ca9c54108c6fd19a6b3)## Notificações de disponibilidadeOs registos governamentais e outras fontes ficam indisponíveis de tempos a tempos. Enquanto uma base de dados estiver inacessível, as verificações efetuadas contra a mesma não devolvem qualquer resposta e não são faturadas. Dentro de um fluxo, o serviço resulta em [`REGISTRY_UNAVAILABLE`](https://docs.didit.me/pt/core-technology/database-validation/database-validation-outcome-codes). Na API autónoma, a mesma interrupção manifesta-se de três formas possíveis, pelo que deve ler os resultados por serviço **e** `database_validation.errors[]`, nunca o estado HTTP isoladamente:- `200` com `outcome_code: "REGISTRY_UNAVAILABLE"` nesse serviço em `validations`, quando a Didit guardou um resultado para reportar sobre o mesmo. - `200` com esse serviço em `database_validation.errors[]` como `code: "empty_provider_response"`, `retryable: true`, quando não produziu nenhuma resposta utilizável e outro serviço selecionado o fez. O serviço com falha fica ausente de `validations` e de `services_used`, pelo que `errors[]` é o único local onde surge. - `502` com `validation_errors[].code: "empty_provider_response"` e `retryable: true`, quando nenhum serviço selecionado devolveu um resultado utilizável (consulte [dados de entrada rejeitados e resultados indisponíveis](https://docs.didit.me/pt/standalone-apis/database-validation.md#entrada-rejeitada-e-resultados-indisponíveis)).O `status` geral segue os serviços que responderam, pelo que não constitui um sinal fiável de indisponibilidade por si só. Um pedido que fique sem nada para comparar passa para `In Review`, mas um pedido que tenha selecionado vários serviços pode regressar como `Approved` com base na correspondência de outro serviço enquanto uma das suas fontes esteve indisponível. Tente novamente o serviço que falhou a partir de `errors[]`, em vez de repetir o pedido completo.Nenhuma destas situações diz o que quer que seja sobre a pessoa que está a ser verificada.A Didit monitoriza os resultados em tempo real das verificações reais, base de dados por base de dados, e envia um e-mail à sua organização quando uma interrupção é prolongada e não apenas um único pedido com falha:| E-mail | Quando é enviado | O que lhe indica | | - | - | - | | **Interrupção de base de dados** | Uma base de dados apresenta falhas há pelo menos dez minutos, com quase todas as verificações nesse período a ficarem sem resposta. Um pico breve ou uma falha isolada nunca aciona este alerta. | A base de dados e o país afetados e quando as falhas foram observadas pela primeira vez. As verificações podem não devolver nenhum resultado até que o acesso seja restabelecido; isto não significa que as identidades submetidas sejam inválidas. | | **Acesso à base de dados restabelecido** | As verificações reais voltaram a responder há pelo menos cinco minutos sem falhas. Períodos sem tráfego nunca contam como recuperação, pelo que uma base de dados com pouco tráfego demora mais tempo a confirmar ambos os estados. | Quando a recuperação foi confirmada. As verificações que não puderam ser concluídas durante a interrupção **não** são reprocessadas automaticamente: reveja-as e tente novamente. |As notificações são enviadas para os membros e contactos de faturação de todas as organizações que executaram uma verificação nessa mesma base de dados nas 48 horas anteriores. Não é necessário configurar nada e não há adesão voluntária (opt-in). O tráfego de sandbox nunca as aciona, tal como as falhas provocadas pelos dados enviados (dados rejeitados ou mal formatados) ou por serviços que funcionam com credenciais cuja ligação é feita pela sua própria organização. Uma verificação respondida através de uma fonte alternativa conta como disponível, assim como uma não correspondência conclusiva.## Preços — pague apenas pelo que utilizarA Validação de base de dados é faturada **por consulta bem-sucedida, por serviço**, à tarifa publicada para esse serviço. As tarifas variam entre **\$0.05** por verificação (República Dominicana através da Junta Central Electoral) até **\$7.00** para as fontes especializadas mais caras. Muitas consultas a registos governamentais situam-se na faixa de **USD 0.20 a USD 0.30**, mas um número considerável custa bastante mais porque a própria fonte cobra mais — o Finland National ID (`fin_national_id`) custa **\$2.10** por consulta bem-sucedida. Consulte o preço de um país na sua respetiva linha da [tabela de preços](https://docs.didit.me/pt/getting-started/database-validation-pricing.md), nunca a partir de um intervalo. Não existem consumos mínimos mensais, compromissos nem taxas de plataforma.Apenas paga quando um serviço devolve um resultado. Os serviços ignorados devido a dados de entrada em falta não são faturados, e o mesmo se aplica a um serviço cuja chamada à fonte falhe - um erro do registo ou um registo inacessível (`REGISTRY_ERROR` / `REGISTRY_UNAVAILABLE`) significa que a consulta nunca foi respondida, pelo que não constitui um resultado passível de cobrança.Cada consulta bem-sucedida a um registo é cobrada logo a partir da primeira, quer seja executada dentro de um fluxo ou através da API autónoma `POST /v3/database-validation/`. É paga a partir do crédito do seu plano ou do saldo carregado, como qualquer outra verificação, e o desconto do seu plano aplica-se ao preço total. Consulte a [página de preços](https://docs.didit.me/pt/getting-started/pricing.md#descontos).➡️ [Preços da Validação de base de dados](https://docs.didit.me/pt/getting-started/database-validation-pricing.md) · [Registe-se e obtenha uma chave de API](https://business.didit.me/)## Todos os serviços \ \ \ \ \ \
PaísISO3ServiçoDescriçãoPreço (USD)
## Continue a ler- [Métodos de correspondência](https://docs.didit.me/pt/core-technology/database-validation/database-validation-matching-methods.md) — como os resultados 1×1 / 2×2 são calculados e como reagir aos mesmos. - [Códigos de resultado](https://docs.didit.me/pt/core-technology/database-validation/database-validation-outcome-codes.md) — a lista completa de códigos de resposta do fornecedor (falecido, menor de idade, documento não encontrado, discrepância biométrica, …) e como correspondem às decisões da sessão. - [Avisos](https://docs.didit.me/pt/core-technology/database-validation/database-validation-warnings.md) — o que apresentamos quando um serviço não pode ser executado devido a dados em falta. - [Relatórios](https://docs.didit.me/pt/core-technology/database-validation/database-validation-report.md) — exportações mensais de faturação por serviço com país, ID do serviço, utilização, preço unitário e custo total. - [Países suportados](https://docs.didit.me/pt/core-technology/database-validation/database-validation-supported-countries.md) — uma visualização estática em tabela de todos os países que cobrimos atualmente. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.