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

# Validazione su database: API KYC con registri governativi

> Valida l'identità sui registri ufficiali con Didit: pay-per-call da $0.05/controllo, 60+ paesi attivi e confronto facciale biometrico.

La **Validazione su database** di Didit verifica i dati di identità di una persona rispetto alla fonte autorevole di quel paese: l'anagrafe nazionale, l'autorità fiscale, le liste elettorali, la centrale rischi o il registro biometrico che ha originariamente emesso il documento. Ogni controllo restituisce una corrispondenza campo per campo (`identification_number`, `first_name`, `last_name`, `date_of_birth` e campi relativi all'indirizzo quando il servizio li utilizza), oltre a un esito aggregato e ai dettagli del record sottostante, se disponibili.È la difesa più efficace contro le frodi basate su identità sintetiche: un DNI o un CPF reale rubato non supererà la ricerca nel registro, e un numero fabbricato non sarà affatto presente nel database ufficiale. La Validazione su database si abbina al nostro confronto facciale biometrico nei paesi in cui il registro conserva una foto ufficiale (Argentina tramite RENAPER, Panama tramite Tribunal Electoral SIB / SIB Plus), permettendoti di confermare non solo che il numero è reale, ma anche che la **persona davanti alla fotocamera ne è la titolare**.

Prompt di integrazione della Validazione su database



      
      

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

## Perché Didit- **Prezzi per chiamata più bassi.** Da **\$0.05** per controllo (Repubblica Dominicana) fino a **\$7.00** per le fonti specialistiche più costose. Il prezzo è stabilito per servizio, non per paese: il prezzo del servizio è adeguato di conseguenza quando il registro applica una tariffa all'ingrosso elevata (la carta d'identità nazionale della Finlandia costa **\$2.10**). Consulta sempre la tariffa per l'esatto servizio che intendi chiamare nella [tabella dei prezzi per servizio](https://docs.didit.me/it/getting-started/database-validation-pricing.md). Nessun minimo mensile, nessun costo di piattaforma, nessuna fatturazione per postazione: vengono addebitate solo le richieste riuscite.
- **La più rapida da integrare.** [Registrati](https://business.didit.me/), ottieni una chiave API dalla console e puoi chiamare `POST /v3/database-validation/` in pochi minuti. Nessuna chiamata commerciale, nessun ciclo di approvvigionamento, nessuna trafila burocratica per la prova di concetto: Didit è completamente autonoma.
- **Interrogazioni dirette alla fonte autorevole.** 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 — non dati estratti da aggregatori.
- **Confronto facciale biometrico dove il registro dispone di una foto ufficiale archiviata.** Affidabilità superiore all'OCR senza alcun lavoro di integrazione aggiuntivo.
- **Latenza pronta per la produzione.** p95 tipicamente inferiore a 1.5 s complessiva, disponibilità trimestrale del 99.9%.La lezione dell'Academy sulla lettura dei risultati di verifica affronta la validazione su database al minuto 11:05 e mostra gli esiti di corrispondenza totale, parziale e assente.[Validazione su database: corrispondenza totale, parziale e assente — Didit Academy](https://www.youtube.com/embed/7htTWCWsl60?start=665\&rel=0\&playsinline=1)## Copertura globalePassa il cursore su qualsiasi paese evidenziato per visualizzare ogni servizio di Validazione su database disponibile, il dominio dei dati (Identità, Finanziario, Biometrico, Indirizzo, Telecomunicazioni, …) e il prezzo per chiamata. I paesi attivi sono già pronti per la produzione; i restanti vengono collegati su richiesta non appena un cliente ne fa domanda.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]
>
> **Non trovi il tuo paese?** Contattaci: il nostro catalogo copre 60+ paesi con centinaia di servizi che attiviamo su richiesta quando un cliente ne ha bisogno. Le nuove integrazioni diventano tipicamente operative in 2–3 settimane.## Come viene eseguita una Validazione su databaseUna Validazione su database non viene mai eseguita in modo speculativo. Viene eseguita solo quando **tutte** le seguenti condizioni sono vere:1) La sessione ha determinato un paese da interrogare — a partire dall'`issuing_state` di una [Verifica dell'identità](https://docs.didit.me/it/core-technology/id-verification/overview.md) oppure, quando il workflow non contiene un passaggio di Verifica dell'identità, dal singolo paese per cui è configurato il passaggio di Validazione su database.
2) Quel paese ha almeno un servizio di Validazione su database abilitato nel workflow.
3) I passaggi precedenti al passaggio di Validazione su database hanno fornito **ogni campo richiesto** necessario per il servizio scelto.Se un servizio è abilitato ma i campi richiesti non sono mai arrivati (ad es. non è stato possibile estrarre il CPF da un RG brasiliano sbavato), il servizio viene saltato, **non ti viene addebitato alcun costo** e viene generato un avviso sulla sessione: `DATABASE_VALIDATION_NOT_APPLICABLE` quando il documento semplicemente non contiene l'identificativo con cui il servizio effettua l'interrogazione, `COULD_NOT_PERFORM_DATABASE_VALIDATION` quando avrebbe dovuto essere disponibile e non lo era. Entrambi sono elencati nel [catalogo degli avvisi](https://docs.didit.me/it/core-technology/database-validation/database-validation-warnings.md).Qualcuno nel tuo team con accesso di revisione alla sessione può quindi inserire manualmente il campo mancante dalla pagina dei dettagli della sessione nella Console, e il salvataggio riattiva automaticamente il controllo. Questa è un'azione del revisore, non qualcosa che l'utente finale possa fare — per consentire all'**utente** di fornire un campo non presente sul suo documento, richiedilo tramite un Questionario (oppure ottienilo tramite un'estrazione di Document AI o usa un valore che invii quando crei la sessione) e mappalo nel passaggio di Validazione su database, come descritto di seguito.### La Validazione su database non richiede la Verifica dell'identitàIn passato, un passaggio di Validazione su database implicava necessariamente un passaggio di Verifica dell'identità a monte, poiché l'OCR di un documento d'identità era l'unico modo integrato per ottenere i dati dell'utente finale. Oggi non è più così: **ogni campo richiesto dichiara quali passaggi possono fornirlo**, e un servizio diventa disponibile non appena il tuo workflow contiene un passaggio che fornisce tutti i campi necessari.| Origine dell'input | Fornisce |
| - | - |
| Verifica dell'identità | Nomi, data di nascita, indirizzo, numero del documento o numero personale e gli identificativi specifici per paese stampati sul documento d'identità (identificativo fiscale, ID nazionale, numero di passaporto, numero di patente, …) |
| NFC | Il sottoinsieme dei dati di cui sopra letto da chip, con un livello di affidabilità più elevato |
| Rilevamento della vitalità | Il selfie in tempo reale, per i servizi di registro biometrico facciale |
| Verifica telefonica | Il numero di telefono verificato |
| Verifica email | L'indirizzo email verificato |
| Prova di residenza | L'indirizzo di residenza verificato e i relativi elementi |
| Document AI | Qualsiasi campo mappato su una delle chiavi dei tuoi campi di estrazione |
| Questionario | Qualsiasi campo mappato su una delle tue domande |
| Input API | Qualsiasi dato, sull'API autonoma — il chiamante fornisce direttamente i valori |Ciò significa che un **servizio biometrico facciale può essere eseguito a partire dal solo passaggio di Rilevamento della vitalità**, senza alcun documento d'identità nel workflow, e un servizio basato su un identificativo fiscale, un numero di telefono o un indirizzo email può essere soddisfatto dalla risposta a un questionario, da un passaggio di Verifica telefonica o Verifica email o da un'estrazione di Document AI.Due regole garantiscono la sicurezza di questo approccio:- **Un workflow senza Verifica dell'identità deve configurare esattamente un paese** nel passaggio di Validazione su database. Senza un `issuing_state` fornito da un documento, questo è l'unico segnale univoco per determinare quale registro nazionale interrogare; pertanto, una configurazione multi-paese senza Verifica dell'identità non esegue alcuna operazione invece di tentare di indovinare.
- **Il controllo dei campi richiesti resta invariato.** Un servizio i cui campi non sono tutti presenti al momento dell'esecuzione viene saltato prima di interrogare qualsiasi provider, garantendo così che non ti venga mai addebitato un database che non è mai stato interrogato.#### Mappatura dei campi di Document AI e dei questionariI campi di estrazione di Document AI e le domande dei questionari utilizzano i *tuoi* nomi di chiave, non quelli di Didit. Una chiave che corrisponde esattamente al nome di input di una Validazione su database (`tax_number`, `date_of_birth`, `phone`, …) viene mappata automaticamente e non richiede alcuna configurazione. Per tutto il resto, l'editor del workflow mostra un selettore nel passaggio di Validazione su database per i campi ancora non compilati, dove puoi collegare ciascuno di essi alla chiave di campo di Document AI o alla risposta del questionario che lo fornisce.Nella Console, un servizio che il tuo workflow non può ancora eseguire viene mostrato disabilitato con il relativo motivo — quali campi mancano e quale passaggio li fornirebbe — e l'editor propone di aggiungere tale passaggio per te. L'aggiunta del passaggio attiva immediatamente ogni servizio sbloccato.> [!TIP]
>
> **Esempio pratico — un identificativo non presente sul documento.** Il servizio National ID della Nigeria effettua l'interrogazione tramite il NIN di 11 cifre, che spesso non è stampato sui documenti caricati dagli utenti; affidarsi al solo documento d'identità fa sì che il controllo venga saltato come non applicabile per una quota consistente di utenti. Inserisci un passaggio di tipo **Questionario** prima del passaggio di Validazione su database per richiedere il NIN, quindi mappa `national_id` su tale domanda nel passaggio di Validazione su database. Questa stessa mappatura rende utilizzabile all'interno di un workflow qualsiasi identificativo che non compare mai su un documento, come un numero di verifica bancaria o un numero di registrazione aziendale.Per i servizi basati sull'indirizzo, Didit suddivide automaticamente il singolo campo `address` del documento d'identità in elementi di indirizzo strutturati:| Campo Didit | Significato |
| - | - |
| `address_element_1` | Indirizzo stradale, inclusi numero civico e tipologia di via |
| `address_element_2` | Unità opzionale, edificio, piano o riga di indirizzo aggiuntiva |
| `address_element_3` | Periferia, distretto, località o quartiere |
| `address_element_4` | Città, comune, stato, provincia o regione |
| `address_element_5` | Codice postale (CAP) |Quando chiami l'API autonoma, puoi inviare un singolo campo `address` oppure direttamente questi campi strutturati. Quando sono presenti entrambi, i campi strutturati hanno la precedenza. I servizi che richiedono la ricerca dell'indirizzo necessitano di `address_element_1` oltre ad almeno un altro elemento di indirizzo; se Didit non riesce a ricavarli dal documento d'identità o dalla Prova di residenza nel workflow, il servizio viene saltato e non fatturato.Se il paese determinato non è affatto abilitato, il passaggio viene saltato silenziosamente, senza alcun avviso e senza alcun addebito.![Flusso di validazione su database Didit che verifica i dati utente rispetto ai registri di identità governativi](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)## Il risultato della corrispondenzaOgni servizio abilitato restituisce una validazione per singolo campo:| Campo | Risultati |
| - | - |
| `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` |Il valore aggregato di `match_type` si articola nei seguenti valori:- **`full_match`** — ogni campo richiesto corrisponde ad almeno una fonte.
- **`partial_match`** — corrispondenza parziale; instrada verso una coda di revisione in base alle regole del tuo workflow.
- **`no_match`** — nessuna fonte ha confermato i dati; solitamente rifiutata.## Come viene ricavata la corrispondenza (1×1 / 2×2)Non ti chiediamo più di preselezionare "1×1" o "2×2": questi valori vengono ricavati dal numero di servizi distinti che hanno trovato una corrispondenza completa con i dati inseriti:- **Risultato 1×1** — un servizio ha restituito una corrispondenza completa (una singola fonte autorevole ha confermato i dati).
- **Risultato 2×2** — due o più servizi hanno restituito una corrispondenza completa (conferma indipendente; il livello massimo di affidabilità esprimibile).Un workflow può abilitare qualsiasi numero di servizi per paese; la fatturazione avviene per ogni servizio che ha effettivamente restituito un risultato. I servizi i cui campi obbligatori non sono stati estratti vengono ignorati senza alcun addebito.➡️ Consulta **[Metodi di corrispondenza](https://docs.didit.me/it/core-technology/database-validation/database-validation-matching-methods.md)** per la logica decisionale completa e la sua interazione con `partialMatchAction` / `noMatchAction`.## Validazione su database biometricaI registri civili di alcuni paesi rilasciano un modello biometrico (un ritratto o un'impronta digitale). Quando è disponibile, associamo la ricerca nel registro a un **confronto facciale biometrico** rispetto al selfie dell'utente:- **Argentina (`arg_renaper`)** — confronto facciale biometrico rispetto alla foto ufficiale RENAPER presente in archivio. Copertura della popolazione al 100%; ogni cittadino argentino dotato di DNI è presente nel database.
- **Panama (`pan_cedula_sib`, `pan_cedula_sib_plus`)** — confronto facciale biometrico rispetto al servizio SIB del Tribunal Electoral. SIB Plus è la variante di livello superiore con soglie biometriche più restrittive e metadati di corrispondenza più dettagliati.Per questi servizi il campo `selfie` è **obbligatorio**. All'interno del flusso di una sessione riutilizziamo il selfie del rilevamento della vitalità (massima qualità) e ricorriamo alla foto del documento come alternativa. Al di fuori di una sessione, quando chiami l'API standalone (`POST /v3/database-validation/`, Modalità B sopra descritta), fornisci tu stesso il file JPEG/PNG.## Arricchimento globale dell'identità`glb_identity_enrichment` è un servizio di Validazione su database **globale, solo standalone**. A partire da un indirizzo email e/o un numero di telefono, risale alle persone associate (nomi, date di nascita, indirizzi, numeri di telefono, email e documenti di identità nazionali) e restituisce un punteggio di corrispondenza del nome, mappato sui [codici di risultato](https://docs.didit.me/it/core-technology/database-validation/database-validation-outcome-codes.md) standard `MATCH` / `PARTIAL_MATCH` / `NO_MATCH` / `DOCUMENT_NOT_FOUND` (con il corrispondente `match_type` impostato su `full_match` / `partial_match` / `no_match`).Poiché si tratta di un servizio globale (`GLB`) basato su email/telefono anziché sul paese di emissione del documento, **non è disponibile nel generatore di workflow**. Chiamalo direttamente tramite l'API standalone impostando `issuing_state` su `GLB`:```json theme={null}
POST /v3/database-validation/
{
  "issuing_state": "GLB",
  "services": ["glb_identity_enrichment"],
  "email": "john.doe@example.com",
  "phone": "+14155552671"
}
```Viene fatturato a **\$0.20 per richiesta** (addebitato solo quando il provider restituisce un risultato).## ConfigurazioneLa Validazione su database viene configurata per ciascun workflow dalla Console. Per ogni paese selezioni i servizi specifici da eseguire; i campi di input obbligatori e opzionali derivano dall'unione di tali servizi. L'azione intrapresa sui risultati `partial_match` e `no_match` viene configurata separatamente e può essere `approve`, `review` o `decline`.![Didit database validation console settings selecting per-country registry services and outcome rules](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)## Notifiche di disponibilitàI registri governativi e le altre fonti possono presentare interruzioni di tanto in tanto. Quando un database non è raggiungibile, i controlli eseguiti su di esso non restituiscono alcuna risposta e non vengono fatturati. All'interno di un workflow il servizio si risolve in [`REGISTRY_UNAVAILABLE`](https://docs.didit.me/it/core-technology/database-validation/database-validation-outcome-codes). Sull'API autonoma la stessa interruzione si presenta in una di tre forme, quindi leggi gli esiti per servizio **e** `database_validation.errors[]`, mai il solo stato HTTP:- `200` con `outcome_code: "REGISTRY_UNAVAILABLE"` su quel servizio in `validations`, quando Didit ha mantenuto un risultato da segnalare al riguardo.
- `200` con quel servizio in `database_validation.errors[]` come `code: "empty_provider_response"`, `retryable: true`, quando non ha prodotto alcuna risposta utilizzabile e un altro servizio selezionato l'ha fatto. Il servizio non riuscito è quindi assente da `validations` e da `services_used`, per cui `errors[]` è l'unico punto in cui compare.
- `502` con `validation_errors[].code: "empty_provider_response"` e `retryable: true`, quando nessun servizio selezionato ha restituito un risultato utilizzabile (vedi [dati di input rifiutati e risultati non disponibili](https://docs.didit.me/it/standalone-apis/database-validation.md#input-rifiutato-e-risultati-non-disponibili)).Lo `status` complessivo segue i servizi che hanno risposto, quindi non è un segnale affidabile di interruzione se considerato da solo. Una richiesta rimasta senza nulla con cui effettuare il confronto passa a `In Review`, ma una richiesta che ha selezionato più servizi può tornare come `Approved` sulla corrispondenza di un altro servizio mentre una delle sue fonti non era disponibile. Riprova il servizio non riuscito da `errors[]` anziché l'intera richiesta.Nessuna di queste forme indica alcunché sulla persona sottoposta a verifica.Didit monitora i risultati in tempo reale dei controlli effettivi, database per database, e invia un'email alla tua organizzazione quando un'interruzione è prolungata anziché trattarsi di una singola richiesta non riuscita:| Email | Quando viene inviata | Cosa ti comunica |
| - | - | - |
| **Interruzione del database** | Un database presenta errori da almeno dieci minuti, con la quasi totalità dei controlli in tale periodo rimasta senza risposta. Una breve serie di errori o un singolo errore non la attiva mai. | Il database e il paese interessati e quando sono stati rilevati per la prima volta gli errori. I controlli potrebbero non restituire alcun risultato fino al ripristino dell'accesso; questo non significa che le identità inviate non siano valide. |
| **Accesso al database ripristinato** | I controlli effettivi rispondono nuovamente da almeno cinque minuti senza errori. I periodi di inattività non contano mai come ripristino, quindi un database a basso traffico richiede più tempo per confermare entrambi gli stati. | Quando è stato confermato il ripristino. Le verifiche che non è stato possibile completare durante l'interruzione **non** vengono rielaborate automaticamente: esaminale e riprova. |Le notifiche vengono inviate ai membri e ai contatti di fatturazione di ogni organizzazione che ha eseguito un controllo su quello specifico database nelle 48 ore precedenti. Non è necessario configurare nulla e non è richiesto alcun consenso esplicito. Il traffico di sandbox non le attiva mai, così come non le attivano gli errori causati dai dati inviati (input rifiutato o malformato) o da servizi che utilizzano credenziali collegate dalla tua organizzazione. Un controllo a cui è stata fornita risposta tramite una fonte alternativa conta come disponibile, così come una mancata corrispondenza definitiva.## Prezzi - paga solo per ciò che usiLa Validazione su database viene fatturata **per query riuscita, per servizio**, alla tariffa pubblicata per tale servizio. Le tariffe vanno da **\$0.05** per controllo (Repubblica Dominicana tramite Junta Central Electoral) fino a **\$7.00** per le fonti specialistiche più costose. Molte consultazioni di registri governativi si collocano nella fascia **da USD 0.20 a USD 0.30**, ma un buon numero costa notevolmente di più perché la fonte stessa applica un prezzo più elevato - Finland National ID (`fin_national_id`) costa **\$2.10** per query riuscita. Determina il prezzo per un paese in base alla relativa riga nella [tabella dei prezzi](https://docs.didit.me/it/getting-started/database-validation-pricing.md), mai da una fascia. Non sono previsti minimi mensili, impegni o costi di piattaforma.Paghi solo quando un servizio restituisce un risultato. I servizi ignorati a causa di dati di input mancanti non vengono fatturati, così come non viene fatturato un servizio la cui chiamata alla fonte fallisce - un errore del registro o un registro non raggiungibile (`REGISTRY_ERROR` / `REGISTRY_UNAVAILABLE`) indica che alla query non è mai stata data risposta, quindi non è un risultato fatturabile.Ogni query del registro riuscita viene addebitata fin dalla prima, sia che venga eseguita all'interno di un workflow sia tramite l'API autonoma `POST /v3/database-validation/`. Viene pagata tramite il credito del tuo piano o il saldo delle ricariche come qualsiasi altro controllo, e lo sconto del tuo piano si applica all'intero prezzo. Consulta la [pagina dei prezzi](https://docs.didit.me/it/getting-started/pricing.md#sconti).➡️ [Prezzi della Validazione su database](https://docs.didit.me/it/getting-started/database-validation-pricing.md) · [Registrati e ottieni una chiave API](https://business.didit.me/)## Tutti i servizi

\<table><thead><tr><th>Paese</th>
            \<th>ISO3</th>
            \<th>Servizio</th>
            \<th>Descrizione</th>
            \<th>Prezzo (USD)</th></tr></thead>
        \<tbody /></table>

## Continua a leggere- [Metodi di corrispondenza](https://docs.didit.me/it/core-technology/database-validation/database-validation-matching-methods.md) - come vengono derivati gli esiti 1×1 / 2×2 e come reagire ad essi.
- [Codici di esito](https://docs.didit.me/it/core-technology/database-validation/database-validation-outcome-codes.md) - l'elenco completo dei codici di risposta del fornitore (deceduto, minore, documento non trovato, mancata corrispondenza biometrica, …) e come corrispondono alle decisioni della sessione.
- [Avvisi](https://docs.didit.me/it/core-technology/database-validation/database-validation-warnings.md) - cosa segnaliamo quando un servizio non può essere eseguito a causa di dati mancanti.
- [Report](https://docs.didit.me/it/core-technology/database-validation/database-validation-report.md) - esportazioni mensili di fatturazione per servizio con paese, ID servizio, utilizzo, prezzo unitario e costo totale.
- [Paesi supportati](https://docs.didit.me/it/core-technology/database-validation/database-validation-supported-countries.md) - una visualizzazione tabellare statica di ogni paese coperto attualmente.


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