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.

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’arraydatabase_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
statuscomplessivo della funzionalità: un valore diFeatureStatusChoices(Not Finished,Approved,Declined,In Review). - Un
match_typeriepilogativo (full_match,partial_match,no_match, oppurenullquando 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 ilvalidation_typederivato (one_by_one,two_by_twoonot_enabled— mainull). - 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 catalogoservice_id/service_name, il codice indipendente dal fornitoreoutcome_code, un campo facoltativooutcome_detail, la mappavalidationper singolo campo e i dati ripulitisource_dataestratti 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_idche identifica quale nodo del grafo del workflow ha prodotto il report (solo per le sessioni V3).
Dove compare nelle risposte API
Il report compare comedatabase_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.
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 daDatabaseValidationV3Serializer.
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 invalidations[] 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’arrayvalidations[] 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 insource_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 unface_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.
Correlati
- Panoramica di Validazione su database — funzionamento end-to-end dell’API e registri supportati.
- Metodi di corrispondenza — come vengono ricavati gli esiti 1×1 / 2×2 (
validation_type: one_by_one/two_by_two). - Codici di esito — tassonomia completa per ciascun risultato con codici di dettaglio specifici per paese.
- Paesi e servizi supportati — tutti i registri attivi, campi obbligatori e prezzo per chiamata.
- Avvisi di Validazione su database — cosa segnaliamo quando un servizio non può essere eseguito.
- Modelli di dati — validazione su database — schema canonico campo per campo.