Vai al contenuto principale
La funzionalità di Validazione su database di Didit confronta i dati di identità di ciascun utente con la fonte autorevole di quel paese — RENAPER (Argentina), Receita Federal (Brasile), Tribunal Electoral (Panama, con confronto facciale biometrico), Junta Central Electoral (Repubblica Dominicana) e altri — fatturata per interrogazione riuscita senza minimi mensili. Ogni voce in database_validations[] corrisponde a un report completo di Validazione su database: una singola esecuzione di un nodo di Validazione su database rispetto a un paese di emissione. Gli esiti dei singoli servizi di registro si trovano all’interno del sotto-array validations[] di tale voce. Questa pagina documenta la struttura JSON per consentirti di analizzare gli esiti di corrispondenza, i dati di origine del registro e i punteggi biometrici restituiti da ciascun servizio.
Report di validazione su database di Didit che mostra i tipi di corrispondenza e i campi di risposta del registro

Panoramica

Un report di Validazione su database viene generato ogni volta che un nodo del workflow esegue la funzionalità di Validazione su database. Ciascuna voce nell’array database_validations[] rappresenta un’esecuzione del nodo rispetto a un paese di emissione; se il nodo esegue più servizi per quel paese (ad esempio CPF + CNH in Brasile), ciascun servizio compare come elemento separato all’interno del sotto-array validations[] della voce. Ciascun report contiene:
  • Lo status complessivo della funzionalità: un valore di FeatureStatusChoices (Not Finished, Approved, Declined, In Review).
  • Un match_type riepilogativo (full_match, partial_match, no_match, oppure null quando nessun servizio ha restituito un risultato utilizzabile) aggregato tra i servizi tramite il metodo di corrispondenza.
  • L’issuing_state (ISO 3166-1 alpha-3) e il validation_type derivato (one_by_one, two_by_two o not_enabled — mai null).
  • Il blocco screened_data: i dati forniti dall’utente che sono stati inviati al registro.
  • Un array validations[]: una voce per ogni servizio che ha prodotto un risultato, con i campi di catalogo service_id/service_name, il codice indipendente dal fornitore outcome_code, un campo facoltativo outcome_detail, la mappa validation per singolo campo e i dati ripuliti source_data estratti dalla risposta del registro.
  • Un array errors[]: errori per singolo servizio nel caso in cui una ricerca non sia riuscita o sia stata saltata; la chiave viene omessa completamente quando non sono presenti errori.
  • Un array warnings[]: eventi di rischio generati durante la validazione (vedi Avvisi di validazione su database).
  • Un node_id che identifica quale nodo del grafo del workflow ha prodotto il report (solo per le sessioni V3).

Dove compare nelle risposte API

Il report compare come database_validations[] in GET /v3/session/{sessionId}/decision/ — sempre come array JSON, mai come oggetto singolo. L’array contiene una voce per ciascun nodo di Validazione su database nel grafo del workflow; a sua volta, il sotto-array validations[] di ciascuna voce contiene un elemento per ciascun servizio di registro che ha prodotto un risultato.
Un valore null indica che non è stato ancora eseguito alcun passaggio di Validazione su database.

Schema

Lo schema canonico campo per campo è disponibile nella pagina dei Modelli di dati. Viene generato da DatabaseValidationV3Serializer.

Valori di status

status utilizza l’enum standard a livello di funzionalità (consulta Enum di stato) — vedi il Riferimento degli enum di stato. L’enum definisce anche Resub Requested, che nella pratica non viene generato da Validazione su database. Le regole di stato personalizzate per singolo nodo vengono applicate al di sopra di questo stato di base. Consulta gli Avvisi di Validazione su database per le azioni configurabili e i relativi valori predefiniti.

Codici di esito

Ogni voce in validations[] include un outcome_code indipendente dal fornitore: uno tra 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. Nota le differenze: NO_MATCH significa che il registro non ha confermato i dati in modo definitivo, INCONCLUSIVE significa che il registro non è stato in grado di stabilirlo in alcun modo (instrada verso la revisione, non verso il rifiuto), e BIOMETRIC_IMAGE_UNUSABLE è un problema tecnico con il selfie (da ripetere) — a differenza del definitivo BIOMETRIC_NO_MATCH. Consulta la tassonomia completa e la gestione consigliata nella pagina dei Codici di esito.

Una voce per servizio

L’array validations[] contiene un elemento per ogni servizio che ha prodotto un payload di risultato (una mappa validation, source_data, outcome_code o outcome_detail). Se il tuo workflow esegue più servizi per lo stesso paese (ad esempio CPF Brasile + CNH Brasile), ciascuno compare separatamente con il proprio service_id, outcome_code e source_data. Il riepilogo match_type aggrega i risultati di tutti i servizi (qualsiasi corrispondenza completa → full_match; altrimenti qualsiasi corrispondenza parziale → partial_match; altrimenti no_match), mentre validation_type viene ricavato dal numero di servizi distinti con corrispondenza completa — consulta Metodi di corrispondenza.

URL pre-firmati delle immagini

I campi immagine in source_data (photo, signature) e screened_data (selfie, cnh_qr_code_image, document_image) vengono restituiti come URL pre-firmati che scadono — aggiornali chiamando nuovamente l’endpoint decisionale. Il payload grezzo a monte non viene intenzionalmente esposto tramite l’API.

Esempi

Approvata — verifica dello stato del CPF brasiliano (Receita Federal)

Approvata — DNI biometrico argentino (RENAPER)

Per l’Argentina, la validazione utilizza RENAPER con un confronto facciale biometrico. La risposta include un face_match_score e ulteriori campi di identità restituiti dal registro.

In revisione — impossibile eseguire la verifica sul registro

Quando nessun servizio restituisce un risultato utilizzabile — campi obbligatori mancanti o non validi, oppure registro non raggiungibile — match_type rimane null, validation_type è not_enabled, viene emesso un avviso COULD_NOT_PERFORM_DATABASE_VALIDATION e la funzionalità passa a In Review finché i dati non vengono corretti. Non viene applicato alcun addebito per i servizi saltati.
Compila il campo mancante nella pagina dei dettagli della sessione nella Console: il salvataggio riattiva automaticamente il controllo e cancella l’avviso in caso di esito positivo.

Correlati

Ultima modifica il 7 novembre 2026