> ## 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.

# API de validação de banco de dados: KYC governamental

> A Didit valida identidades em registros governamentais por chamada, a partir de $0.05, em 60+ países, com correspondência facial onde o registro tem foto.

A **Validação de banco de dados** da Didit verifica os dados de identidade de uma pessoa contra a fonte oficial de cada país - o registro civil nacional, a autoridade tributária, o cadastro eleitoral, o bureau de crédito ou o registro biométrico que emitiu o documento em primeiro lugar. Cada consulta retorna uma correspondência por campo (`identification_number`, `first_name`, `last_name`, `date_of_birth` e campos de endereço quando o serviço os utiliza), além de um resultado agregado e dos detalhes do registro subjacente quando disponíveis.É a defesa mais forte contra fraude de identidade sintética: um DNI ou CPF real roubado falhará na consulta ao registro, e um número fabricado simplesmente não estará na base oficial. A Validação de banco de dados é combinada com a nossa correspondência facial biométrica nos países em que o registro guarda uma foto oficial (Argentina via RENAPER, Panamá via Tribunal Electoral SIB / SIB Plus), para que você confirme não só que o número é real, mas que a **pessoa diante da câmera é a titular dele**.

Prompt de integração da Validação de banco de dados
        Copy prompt to clipboard



      
      

\<pre>

\````# 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````

\</pre>



      
      

Paste into

## Por que a Didit- **O menor preço por chamada.** A partir de **\$0.05** por consulta (República Dominicana) até **\$7.00** para as fontes especializadas mais caras. O preço é definido por serviço, não por país - um registro que cobra uma tarifa de atacado alta tem preço proporcional (o Documento Nacional de Identidade da Finlândia custa **\$2.10**). Consulte sempre a tarifa do serviço exato que você pretende chamar na [tabela de preços por serviço](https://docs.didit.me/getting-started/database-validation-pricing.md). Sem mínimos mensais, sem taxas de plataforma, sem cobrança por usuário - só as consultas bem-sucedidas são cobradas.
- **A integração mais rápida.** [Cadastre-se](https://business.didit.me/), pegue uma chave de API no console e você poderá chamar `POST /v3/database-validation/` em minutos. Sem ligação comercial, sem processo de compras, sem burocracia de prova de conceito - a Didit é totalmente self-service.
- **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 - não raspagens de agregadores.
- **Correspondência facial biométrica onde o registro tem uma foto oficial.** Confiança maior que a do OCR, sem nenhum trabalho extra de integração.
- **Latência pronta para produção.** p95 normalmente abaixo de 1.5 s de ponta a ponta, 99.9% de disponibilidade trimestral.A aula da Academy sobre como ler o resultado de uma verificação chega à validação de banco de dados em 11:05 e mostra os resultados de correspondência total, parcial e nenhuma correspondência.[Validação de banco de dados: correspondência total, parcial e nenhuma — Didit Academy](https://www.youtube.com/embed/7htTWCWsl60?start=665\&rel=0\&playsinline=1)## Cobertura globalPasse o mouse sobre qualquer país destacado para ver todos os serviços de Validação de banco de dados que operamos ali, o domínio dos dados (Identidade, Financeiro, Biométrico, Endereço, Telecom, …) e o preço por chamada. Os países ativos estão prontos para produção hoje; os demais são conectados sob demanda quando um cliente pede.Live Database Validation coverageProduction-ready countries and the cheapest live service available in each.LIVE<details><summary>Show on-demand catalog countries ()</summary></details>> [!TIP]
>
> **Não encontrou o seu país?** Fale conosco - nosso catálogo acompanha 60+ países com centenas de serviços que ativamos sob demanda quando um cliente precisa. As novas integrações normalmente entram no ar em 2–3 semanas.## Como uma Validação de banco de dados é executadaUma Validação de banco de dados nunca dispara de forma especulativa. Ela só é executada quando **todas** as condições abaixo são verdadeiras:1) A sessão definiu um país a consultar - a partir do `issuing_state` de uma [Verificação de identidade](https://docs.didit.me/pt-br/core-technology/id-verification/overview.md) ou, quando o fluxo não tem etapa de Verificação de identidade, do único país para o qual a etapa de Validação de banco de dados está configurada.
2) Esse país tem pelo menos um serviço de Validação de banco de dados ativado no fluxo.
3) As etapas anteriores à de Validação de banco de dados forneceram **todos os campos obrigatórios** de que o serviço escolhido precisa.Se um serviço está ativado mas os campos obrigatórios nunca chegaram (por exemplo, o CPF não pôde ser extraído de um RG brasileiro manchado), o serviço é ignorado, **você não é cobrado** e um aviso é gerado na sessão: `DATABASE_VALIDATION_NOT_APPLICABLE` quando o documento simplesmente não traz o identificador pelo qual aquele serviço consulta, `COULD_NOT_PERFORM_DATABASE_VALIDATION` quando ele deveria estar disponível e não estava. Ambos estão listados no [catálogo de avisos](https://docs.didit.me/core-technology/database-validation/database-validation-warnings.md).Alguém da sua equipe com acesso de revisão à sessão pode então preencher o campo ausente manualmente na página de detalhes da sessão no Console, e ao salvar a verificação é reexecutada automaticamente. Essa é uma ação do revisor, não algo que o usuário final possa fazer - para que o **usuário** forneça um campo que o documento não traz, peça-o em um Questionário (ou em uma extração do Document AI, ou em um valor que você envia ao criar a sessão) e mapeie-o na etapa de Validação de banco de dados, como descrito abaixo.### A Validação de banco de dados não exige Verificação de identidadeAntes, uma etapa de Validação de banco de dados pressupunha uma etapa de Verificação de identidade antes dela, porque o OCR de um documento de identidade era a única forma ligada de obter os dados do usuário final. Isso não é mais verdade: **cada campo obrigatório declara quais etapas podem fornecê-lo**, e um serviço fica disponível assim que o seu fluxo contém uma etapa que fornece todos os campos de que ele precisa.| Fonte de entrada | Fornece |
| - | - |
| Verificação de identidade | Nomes, data de nascimento, endereço, número do documento/pessoal e os identificadores específicos do país impressos em um documento de identidade (número fiscal, documento nacional, número de passaporte, número da carteira de motorista, …) |
| NFC | O subconjunto lido do chip dos itens acima, com maior confiança |
| Prova de vida | A selfie ao vivo, para serviços de registro com biometria facial |
| Verificação de telefone | O número de telefone verificado |
| Verificação de e-mail | O endereço de e-mail verificado |
| Comprovante de endereço | O endereço residencial verificado e seus componentes |
| Document AI | Qualquer campo que você mapeie para uma das suas chaves de campo de extração |
| Questionário | Qualquer campo que você mapeie para uma das suas perguntas |
| Entrada da API | Qualquer coisa, na API independente - quem chama fornece os valores diretamente |Isso significa que um **serviço de biometria facial pode ser executado apenas com uma etapa de Prova de vida**, sem nenhum documento de identidade no fluxo, e um serviço baseado em número fiscal, telefone ou e-mail pode ser atendido por uma resposta de questionário, uma etapa de Verificação de telefone/e-mail ou uma extração do Document AI.Duas regras mantêm isso seguro:- **Um fluxo sem Verificação de identidade deve configurar exatamente um país** na etapa de Validação de banco de dados. Sem um `issuing_state` vindo de um documento, esse é o único sinal inequívoco de qual registro nacional consultar, então uma configuração com vários países e sem Verificação de identidade não executa nada em vez de adivinhar.
- **A verificação de campos obrigatórios não muda.** Um serviço cujos campos não estão todos presentes na execução é ignorado antes de qualquer provedor ser consultado, então você nunca é cobrado por uma base que nunca foi consultada.#### Mapeando campos do Document AI e de questionáriosOs campos de extração do Document AI e as perguntas de questionário usam os *seus* nomes de chave, não os da Didit. Uma chave que corresponde exatamente a um nome de entrada da Validação de banco de dados (`tax_number`, `date_of_birth`, `phone`, …) é mapeada automaticamente e não precisa de configuração. Para qualquer outra, o editor de fluxos mostra na etapa de Validação de banco de dados um seletor para os campos ainda não preenchidos, onde você aponta cada um para a chave de campo do Document AI ou a resposta do questionário que o fornece.No Console, um serviço que o seu fluxo ainda não consegue executar aparece desativado com o motivo - quais campos faltam e qual etapa os forneceria - e o editor se oferece para adicionar essa etapa para você. Adicioná-la liga imediatamente todos os serviços que ela desbloqueia.> [!TIP]
>
> **Exemplo prático - um identificador que o documento não traz.** O serviço de Documento Nacional de Identidade da Nigéria consulta pelo NIN de 11 dígitos, que muitas vezes não está impresso nos documentos que as pessoas enviam, então depender só do documento de identidade deixa a verificação ignorada como não aplicável para uma grande parte dos usuários. Coloque uma etapa de **Questionário** antes da etapa de Validação de banco de dados pedindo o NIN e depois mapeie `national_id` para essa pergunta na etapa de Validação de banco de dados. O mesmo mapeamento é o que torna utilizável em um fluxo um identificador que nunca consta em nenhum documento - um número de verificação bancária, um número de registro de empresa.Para serviços baseados em endereço, a Didit divide automaticamente o único `address` do documento de identidade em elementos de endereço estruturados:| Campo da Didit | Significado |
| - | - |
| `address_element_1` | Endereço da rua, incluindo número e tipo de logradouro |
| `address_element_2` | Unidade, edifício, andar ou linha de endereço extra (opcional) |
| `address_element_3` | Bairro, distrito, localidade ou vizinhança |
| `address_element_4` | Cidade, município, estado, província ou região |
| `address_element_5` | Código postal ou CEP |Ao chamar a API independente, você pode enviar um único `address` ou esses campos estruturados diretamente. Os campos estruturados prevalecem quando ambos estão presentes. Os serviços que exigem busca por endereço precisam de `address_element_1` mais pelo menos outro elemento de endereço; se a Didit não conseguir derivá-los do documento de identidade ou do Comprovante de endereço do fluxo, o serviço é ignorado e não é cobrado.Se o país resolvido não está ativado, a etapa é ignorada silenciosamente, sem aviso e sem cobrança.![Fluxo de validação de banco de dados da Didit conferindo os dados do usuário em registros governamentais de identidade](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 da correspondênciaCada serviço ativado retorna 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 resulta em:- **`full_match`** - todos os campos solicitados concordam com pelo menos uma fonte.
- **`partial_match`** - alguma concordância; encaminhe para uma fila de revisão conforme as regras do seu fluxo.
- **`no_match`** - nenhuma fonte confirmou os dados; normalmente, recuse.## Como a correspondência é derivada (1×1 / 2×2)Não pedimos mais que você escolha previamente "1×1" ou "2×2" - eles são derivados de quantos serviços distintos tiveram correspondência total com os dados de entrada:- **Resultado 1×1** - um serviço retornou correspondência total (uma única fonte oficial confirmou os dados).
- **Resultado 2×2** - dois ou mais serviços retornaram correspondência total (corroboração independente; a maior confiança que conseguimos expressar).Um fluxo pode ativar qualquer número de serviços por país; você é cobrado por serviço que realmente retornou um resultado. Os serviços cujos campos obrigatórios não puderam ser extraídos são ignorados, sem cobrança.➡️ Veja **[Métodos de correspondência](https://docs.didit.me/core-technology/database-validation/database-validation-matching-methods.md)** para a lógica de decisão completa e como ela interage com `partialMatchAction` / `noMatchAction`.## Validação de banco de dados biométricaOs registros civis de alguns países publicam um template biométrico (um retrato ou uma impressão digital). Quando isso está disponível, combinamos a consulta ao registro com uma **correspondência facial biométrica** contra a selfie do usuário:- **Argentina (`arg_renaper`)** - correspondência facial biométrica contra a foto oficial do RENAPER. Cobertura de 100% da população; todo cidadão argentino com DNI está na base.
- **Panamá (`pan_cedula_sib`, `pan_cedula_sib_plus`)** - correspondência facial biométrica contra o serviço SIB do Tribunal Electoral. O SIB Plus é a variante de nível elevado, com limites biométricos mais rigorosos e metadados de correspondência mais ricos.Para esses serviços, o campo `selfie` é **obrigatório**. Dentro de um fluxo de sessão, reutilizamos a selfie da prova de vida (a de maior qualidade) e recorremos ao retrato do documento. Fora de uma sessão, ao chamar a API independente (`POST /v3/database-validation/`, Modo B acima), você mesmo fornece o JPEG/PNG.## Enriquecimento global de identidade`glb_identity_enrichment` é um serviço de Validação de banco de dados **global e exclusivo da API independente**. A partir de um e-mail e/ou número de telefone, ele identifica as pessoas associadas (nomes, datas de nascimento, endereços, telefones, e-mails e documentos nacionais) e retorna uma pontuação de correspondência de nome, mapeada para os [códigos de resultado](https://docs.didit.me/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, ele **não está disponível no construtor de fluxos**. Chame-o diretamente pela API independente 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"
}
```Ele é cobrado a **\$0.20 por requisição** (cobrado apenas quando o provedor retorna um resultado).## ConfiguraçãoA Validação de banco de dados é configurada por fluxo no Console. Para cada país, você seleciona os serviços específicos que quer executar; os campos de entrada obrigatórios e opcionais são derivados da união desses serviços. A ação tomada nos resultados `partial_match` e `no_match` é configurada separadamente e pode ser `approve`, `review` ou `decline`.![Configurações de validação de banco de dados da Didit no console, selecionando serviços de registro por país e regras de resultado](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 disponibilidadeRegistros governamentais e outras fontes saem do ar de tempos em tempos. Enquanto uma base está inacessível, as consultas a ela não retornam resposta e não são cobradas. Dentro de um fluxo, o serviço é resolvido como [`REGISTRY_UNAVAILABLE`](https://docs.didit.me/core-technology/database-validation/database-validation-outcome-codes). Na API independente, a mesma indisponibilidade chega de uma de três formas, então leia os resultados por serviço **e** `database_validation.errors[]`, nunca apenas o status HTTP:- `200` com `outcome_code: "REGISTRY_UNAVAILABLE"` naquele serviço em `validations`, quando a Didit manteve um resultado para informar sobre ele.
- `200` com aquele serviço em `database_validation.errors[]` como `code: "empty_provider_response"`, `retryable: true`, quando ele não produziu nenhuma resposta utilizável e outro serviço selecionado produziu. O serviço com falha fica então ausente de `validations` e de `services_used`, de modo que `errors[]` é o único lugar em que ele aparece.
- `502` com `validation_errors[].code: "empty_provider_response"` e `retryable: true`, quando nenhum serviço selecionado retornou um resultado utilizável (veja [entrada rejeitada e resultados indisponíveis](https://docs.didit.me/standalone-apis/database-validation.md#rejected-input-and-unavailable-results)).O `status` geral segue os serviços que responderam, então não é, por si só, um sinal confiável de indisponibilidade. Uma requisição que fica sem nada para comparar vai para `In Review`, mas uma requisição que selecionou vários serviços pode voltar `Approved` pela correspondência de outro serviço enquanto uma de suas fontes estava indisponível. Repita o serviço com falha listado em `errors[]` em vez da requisição inteira.Nenhuma dessas formas diz algo sobre a pessoa que está sendo verificada.A Didit acompanha os resultados ao vivo de verificações reais, base por base, e envia um e-mail à sua organização quando uma interrupção é sustentada, e não uma única requisição com falha:| E-mail | Quando é enviado | O que ele informa |
| - | - | - |
| **Interrupção de banco de dados** | Uma base está falhando há pelo menos dez minutos, com quase todas as consultas desse período sem resposta. Uma rajada curta ou uma única falha nunca o aciona. | A base e o país afetados e quando as falhas foram observadas pela primeira vez. As consultas podem não retornar resultado até que o acesso seja restabelecido; isso não significa que as identidades enviadas sejam inválidas. |
| **Acesso ao banco de dados restabelecido** | Consultas reais voltaram a responder por pelo menos cinco minutos sem falhas. Períodos sem tráfego nunca contam como recuperação, então uma base com pouco tráfego leva mais tempo para confirmar os dois 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: revise-as e tente novamente. |Os avisos vão para os membros e contatos de cobrança de toda organização que executou uma consulta àquela base exata nas 48 horas anteriores. Nada precisa ser configurado e não há adesão (opt-in). O tráfego de sandbox nunca os aciona, nem as falhas causadas pelos dados que você enviou (entrada rejeitada ou malformada) ou por serviços que rodam com credenciais que a sua própria organização conecta. Uma consulta respondida por uma fonte alternativa conta como disponível, assim como uma ausência de correspondência conclusiva.## Preços - pague apenas pelo que usarA Validação de banco de dados é cobrada **por consulta bem-sucedida, por serviço**, pela tarifa publicada para aquele serviço. As tarifas vão de **\$0.05** por consulta (República Dominicana via Junta Central Electoral) até **\$7.00** para as fontes especializadas mais caras. Muitas consultas a registros governamentais ficam na faixa de **USD 0.20 a USD 0.30**, mas um bom número custa bem mais porque a própria fonte cobra mais - o Documento Nacional de Identidade da Finlândia (`fin_national_id`) custa **\$2.10** por consulta bem-sucedida. Calcule o preço de um país pela linha dele na [tabela de preços](https://docs.didit.me/getting-started/database-validation-pricing.md), nunca por uma faixa. Não há mínimos mensais, compromissos nem taxas de plataforma.Você só paga quando um serviço retorna um resultado. Serviços ignorados por falta de dados de entrada não são cobrados, nem um serviço cuja própria chamada à fonte falha - um erro do registro ou um registro inacessível (`REGISTRY_ERROR` / `REGISTRY_UNAVAILABLE`) significa que a consulta nunca foi respondida, então não é um resultado cobrável.Toda consulta bem-sucedida a um registro é cobrada desde a primeira, seja executada dentro de um fluxo ou pela API independente `POST /v3/database-validation/`. Ela é paga com o crédito do seu plano ou com o saldo de recarga, como qualquer outra verificação, e o desconto do seu plano se aplica ao preço inteiro. Veja a [página de preços](https://docs.didit.me/getting-started/pricing.md#discounts).➡️ [Preços da Validação de banco de dados](https://docs.didit.me/getting-started/database-validation-pricing.md) · [Cadastre-se e obtenha uma chave de API](https://business.didit.me/)## Todos os serviços

\<table><thead><tr><th>Country</th>
            \<th>ISO3</th>
            \<th>Service</th>
            \<th>Description</th>
            \<th>Price (USD)</th></tr></thead>
        \<tbody /></table>

## Continue lendo- [Métodos de correspondência](https://docs.didit.me/core-technology/database-validation/database-validation-matching-methods.md) - como os resultados 1×1 / 2×2 são derivados e como reagir a eles.
- [Códigos de resultado](https://docs.didit.me/core-technology/database-validation/database-validation-outcome-codes.md) - a lista completa de códigos de resposta dos provedores (falecido, menor de idade, documento não encontrado, divergência biométrica, …) e como eles se mapeiam para as decisões de sessão.
- [Avisos](https://docs.didit.me/core-technology/database-validation/database-validation-warnings.md) - o que exibimos quando um serviço não pode ser executado por falta de dados.
- [Relatórios](https://docs.didit.me/core-technology/database-validation/database-validation-report.md) - exportações mensais de cobrança por serviço, com país, ID do serviço, uso, preço unitário e custo total.
- [Países compatíveis](https://docs.didit.me/core-technology/database-validation/database-validation-supported-countries.md) - uma visão em tabela estática de todos os países que cobrimos hoje.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.