Vai al contenuto principale
GET
cURL

​
Supporto KYC e KYB

Questo endpoint funziona sia per le sessioni di Verifica degli utenti (KYC) sia per quelle di Verifica aziendale (KYB). La risposta contiene sempre un campo di primo livello session_kind:
  • "user": sessione di Verifica degli utenti (KYC). La risposta contiene id_verifications, liveness_checks, face_matches, nfc_verifications, poa_verifications, database_validations.
  • "business": sessione di Verifica aziendale (KYB). La risposta contiene registry_checks, document_verifications, key_people_checks.
Entrambi i tipi condividono aml_screenings, phone_verifications, email_verifications, questionnaire_responses, ip_analyses, document_ai_documents, bank_verifications, reviews, contact_details, oltre ai campi comuni di primo livello (session_id, session_number, session_url, status, workflow_id, vendor_data, metadata, callback, features, expected_details, created_at, expires_at). Didit cerca il session_id in entrambi i tipi di sessione (prima Verifica degli utenti, poi Verifica aziendale) e restituisce quella che corrisponde. Gli UUID sono univoci per applicazione, quindi non c’è ambiguità. Consulta la panoramica delle sessioni per la matrice completa delle funzionalità specifiche per tipo.

​
Esempi

Risposta (troncata):

​
Come gestire la risposta dal tuo lato

​
Stato, tracciamento della decisione e campi di revisione

Ogni decisione spiega come è stato raggiunto il suo status.

​
Conservazione dei dati biometrici

biometric_retention è sempre presente. deletes_at è la data in cui vengono eliminati i dati biometrici attivi della sessione, e jurisdictions elenca gli stati USA le cui norme biometriche impongono un limite di cancellazione per la persona (US quando lo stato è sconosciuto). deletes_at è null quando non si applica ancora alcuna data.

​
Verifica della posizione

Quando il workflow contiene un passaggio di Verifica della posizione, la decisione include due array. geolocation_checks[] ha un elemento per passaggio: il tentativo accettato, con l’esito, le coordinate e la loro precisione, i controlli rispetto alla posizione IP e all’indirizzo registrato, e gli warnings del passaggio. geolocation_attempts[] elenca ogni tentativo di ogni passaggio, dal più vecchio, con la data di ricezione di ciascuno. I workflow senza il passaggio restituiscono entrambi come null. Ogni campo ed esito è descritto nel report di verifica della posizione.

​
Eventi di instradamento del workflow

?include=events aggiunge la timeline degli eventi della sessione. Oltre alle variazioni di passaggio e di stato, un workflow che instrada attraverso nodi di ramificazione lascia un evento per ogni decisione di instradamento. In questo modo un’integrazione (o la timeline della Console) può spiegare perché una sessione si è conclusa con un determinato esito senza che tu debba ripercorrere a mano il grafo del workflow: Entrambi gli eventi includono sent_at in millisecondi, come ogni altro evento, e non hanno component, feature_step né step: provengono dal motore del workflow, non dal dispositivo dell’utente. Un ramo “else” (un ramo senza condizioni) conta come ramo corrispondente; fallback è true solo quando nulla ha corrisposto. I nodi con un unico arco in uscita non prendono alcuna decisione e non lasciano alcun evento. Lo stesso schema riporta anche workflow_terminal_node_id: il node_id dell’ultimo nodo di stato del workflow registrato che ha impostato uno stato della sessione, oppure null se non è stato registrato alcun ID di nodo di questo tipo. Si tratta di una traccia storica del workflow. Approvazioni, rifiuti e ripresentazioni manuali non lo cancellano; un successivo nodo di stato del workflow lo sostituisce. Ad esempio, se un workflow manda una sessione a un nodo In revisione e un revisore la approva in seguito, lo status attuale è Approved mentre workflow_terminal_node_id continua a identificare il nodo In revisione. Il campo può anche restare valorizzato mentre è in corso una ripresentazione. Leggi lo status attuale e le timeline degli eventi e di activity_reviews per distinguere gli esiti del workflow dalle decisioni manuali successive.

​
Ripresentazioni precedenti (?include=resubmissions)

Una ripresentazione riporta l’utente ai passaggi che selezioni e conserva ciò che quei passaggi avevano restituito in precedenza. ?include=resubmissions aggiunge un array resubmissions, dal più vecchio al più recente, con una voce per ogni richiesta di ripresentazione. Ogni voce riporta i risultati che la richiesta ha sostituito, così puoi sempre leggere ciò che l’utente ha inviato in precedenza. Funziona per le sessioni utente (KYC) e aziendali (KYB), e puoi combinarlo con gli eventi (?include=events,resubmissions). Senza il parametro la risposta non cambia. I risultati attuali (id_verifications e gli altri al primo livello) descrivono sempre l’ultimo invio. I passaggi che non sono stati rimandati mantengono lì un unico risultato.
Eliminare una sessione elimina i risultati di ogni invio che ne fa parte.

​
Metodi di verifica dell’identità

Ogni elemento di id_verifications[] indica quale dei tre metodi di verifica dell’identità lo ha prodotto. Così puoi distinguere una lettura di documento da una consultazione di un registro o da un accesso con wallet senza dover intuire dai campi che risultano valorizzati: Una sessione con documento riporta document e documentary e lascia gli altri campi a null, quindi le integrazioni esistenti non richiedono modifiche. I tipi di ogni campo sono in Modelli dati.

​
Consenso biometrico

Le decisioni di Verifica degli utenti contengono un oggetto biometric_consent: se la sessione richiedeva un consenso biometrico esplicito, il trigger che lo ha richiesto, lo status della risposta e le sue evidenze. Due valori indicano che il consenso non è stato raccolto: Quando compare il passaggio e cosa significa ciascun valore sono descritti in Consenso biometrico; ogni campo è in Modelli dati.

​
Verifica bancaria

Quando il workflow include un passaggio di Bank Verification, la decisione contiene bank_verifications[], per entrambi i tipi di sessione: un elemento per ogni passaggio, null finché un passaggio non produce un risultato. Per distinguere l’accesso alla banca dalla verifica del conto leggi method, non ownership.method: ownership.method è il confronto del nome che ha prodotto il punteggio. Ogni campo è presente nello schema BankVerificationResult della risposta di questo endpoint.

​
Firma elettronica

Quando il workflow include un passaggio di E-signature, la decisione contiene signatures[], per entrambi i tipi di sessione. Contiene un elemento per firmatario: uno per una Verifica degli utenti, uno per ogni persona chiave che firma in una Verifica aziendale (KYB). I workflow senza questo passaggio non restituiscono affatto la chiave. Scarica i file dai percorsi con la tua chiave API. Consulta il report sulla firma elettronica per tutti i campi.

​
Errori

​
Correlati

Autorizzazioni

​
x-api-key
string
header
obbligatorio

La chiave API della tua applicazione, da Developers -> API keys nella Business Console. La chiave primaria ha accesso completo. Una chiave con nome può avere un ambito definito: nessuno, lettura o scrittura per risorsa, limitata ad alcuni workflow o a sessioni approvate, a un elenco di indirizzi IP e a una data di scadenza. 401 indica che la chiave è errata, revocata o scaduta; 403 indica che non è stata inviata alcuna chiave, che la chiave non ha accesso a questa risorsa o azione, oppure che la richiesta proviene da un indirizzo non incluso nel suo elenco IP; 404 su una route di sessione indica che la sessione non rientra nei workflow o negli stati previsti dalla chiave. Una chiave senza accesso ai media riceve gli URL di immagini, video e PDF come null, e una chiave senza permessi di scrittura sulle sessioni riceve link e token di sessione come null. Consulta https://docs.didit.me/console/api-keys.

Parametri del percorso

​
sessionId
string<uuid>
obbligatorio

UUID della sessione di verifica di cui vuoi recuperare la decisione. Corrisponde al session_id restituito da POST /v3/session/. Lo stesso percorso funziona sia per le sessioni di Verifica degli utenti (KYC) sia per quelle di Verifica aziendale (KYB): il server risolve l'ID per entrambi i tipi di sessione.

Deve essere un UUID valido. La route trova corrispondenza solo con UUID corretti, pertanto un valore non conforme viene rifiutato dal router degli URL prima dell'esecuzione del codice dell'applicazione e la risposta è una pagina HTML 404 anziché il wrapper JSON {"detail": ...} mostrato di seguito. Valida il formato dell'UUID lato client per distinguere un errore di input da un autentico 404 per sessione mancante.

Esempio:

"11111111-2222-3333-4444-555555555555"

Parametri della query

​
include
enum<string>

Elenco separato da virgole di sezioni di payload aggiuntive. Valori supportati: events e resubmissions, singolarmente o insieme (events,resubmissions). Quando viene passato include=events, la risposta contiene inoltre la cronologia degli eventi della sessione (events, compresi gli eventi di routing WORKFLOW_BRANCH_EVALUATED / WORKFLOW_STATUS_NODE_REACHED descritti nella pagina Recupera sessione), il registro completo delle attività (activity_reviews), i flag di blocklist (blocklisted), un cost_breakdown per sessione, i metadati del workflow (workflow_type, workflow_version, workflow_version_id e workflow_terminal_node_id - l'ultimo nodo di stato del workflow registrato che ha impostato uno stato della sessione, o null se non ne è stato registrato alcuno; provenienza storica che non viene cancellata da approvazioni, rifiuti o nuovi invii manuali ed è sostituita da un nodo di stato del workflow successivo) e i metadati della sessione (api_service — stringa o null, impostato solo per le sessioni API autonome; session_type — API, HOSTED o MIGRATED; has_device_nfc_support — booleano). Due campi cambiano rispetto alla struttura standard: il discriminatore di primo livello session_kind viene omesso (la struttura degli eventi esiste solo per le sessioni utente) e l'array features passa da stringhe semplici a oggetti {feature, node_id} — dove la funzionalità email viene indicata come EMAIL invece di EMAIL_VERIFICATION. Questa struttura estesa è utilizzata principalmente dalla Console Didit; la maggior parte delle integrazioni API dovrebbe omettere il parametro. Limitazione KYB: include=events si applica solo alle sessioni utente (KYC). Le sessioni aziendali (session_kind = "business") restituiscono sempre la struttura standard della decisione aziendale — events, activity_reviews, blocklisted, cost_breakdown e i metadati aggiuntivi workflow_*/della sessione non vengono mai restituiti per le sessioni aziendali, e il loro array features rimane un semplice array di stringhe. Con include=resubmissions (sia per le sessioni utente che aziendali), la risposta contiene anche resubmissions: una voce per ciascuna richiesta di nuovo invio, dalla più vecchia alla più recente, ciascuna con number, created_at, previous_status, nodes, reasons, requested_by e results (ciò che i passaggi reinviati hanno restituito prima della richiesta, sotto le stesse chiavi e nella stessa struttura dei risultati attuali). Ciascun elemento di cost_breakdown include usage_type, price, details e created_at: un passaggio reinviato che viene eseguito nuovamente viene fatturato come nuovo elemento.

Opzioni disponibili:
events,
resubmissions,
events,resubmissions
Esempio:

"events"

Risposta

Report di decisione completo. session_kind distingue le due strutture: le sessioni user contengono gli array di funzionalità KYC mostrati di seguito; le sessioni business contengono invece registry_checks, document_verifications e key_people_checks insieme agli array condivisi. Gli array delle funzionalità sono null finché il workflow non ha eseguito tale funzionalità; gli URL dei contenuti multimediali sono link pre-firmati di breve durata.

​
session_id
string<uuid>

L'identificatore univoco della sessione.

​
session_kind
enum<string>

Discriminatore che indica se si tratta di una sessione di Verifica degli utenti (KYC) o di Verifica aziendale (KYB). Quando è user, si applicano gli array di funzionalità KYC (id_verifications, nfc_verifications, liveness_checks, face_matches, poa_verifications, document_ai_documents, database_validations, ...) e gli array aziendali sono assenti. Quando è business, il payload contiene invece registry_checks, document_verifications, key_people_checks oltre agli array condivisi (aml_screenings, phone_verifications, email_verifications, ip_analyses, questionnaire_responses). Omesso quando viene passato include=events — il formato degli eventi esiste solo per le sessioni utente, quindi il discriminatore viene rimosso da quella variante.

Opzioni disponibili:
user,
business
​
shared_from_session
string<uuid> | null

Per una sessione clonata con POST /v3/session/import-shared/: il session_id della sessione originale nell'applicazione di origine. null per qualsiasi altra sessione. Omesso quando viene passato include=events.

​
shared_from_session_number
integer | null

session_number della sessione di origine quando questa sessione è stata importata da un'altra applicazione della tua organizzazione. null altrimenti.

​
session_number
integer | null

Il numero della sessione.

​
session_url
string<uri> | null

L'URL della sessione.

​
status
enum<string>

Stato complessivo del ciclo di vita della sessione — il risultato aggregato del workflow. I valori finali sono Approved, Declined, In Review, Expired, Kyc Expired e Abandoned; Not Started, In Progress, Awaiting User e Resubmitted indicano che la sessione è ancora in corso nel workflow.

Opzioni disponibili:
Not Started,
In Progress,
Awaiting User,
In Review,
Approved,
Declined,
Resubmitted,
Expired,
Kyc Expired,
Abandoned
​
status_override
object | null

Presente quando un revisore ha impostato manualmente lo status. null quando lo stato è quello automatico. Utilizzalo per distinguere un'approvazione manuale da una automatica.

​
decision_trace
object

Come è stato raggiunto lo stato: chi lo ha impostato e quali avvisi lo hanno determinato.

​
linked_records
object | null

Un riepilogo di altri record collegati alla sessione. null quando non c'è nulla da mostrare e per i workflow che dichiarano uno standard di verifica dell'età.

​
workflow_id
string<uuid> | null

Identificatore stabile del gruppo di workflow che ha prodotto questa sessione. I workflow sono versionati: questo valore identifica il workflow stesso, non la versione specifica.

​
features
string[]

Elenco delle funzionalità di verifica configurate per questa sessione, come nomi visualizzati: ID_VERIFICATION, NFC, LIVENESS, FACE_MATCH, POA, PHONE, EMAIL_VERIFICATION, AML, IP_ANALYSIS, DATABASE_VALIDATION, QUESTIONNAIRE, AGE_ESTIMATION, FACE_SEARCH, GEOLOCATION (Verifica della posizione) (le sessioni di Verifica aziendale utilizzano il set di funzionalità KYB: KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE, AML, PHONE, EMAIL_VERIFICATION, IP_ANALYSIS, QUESTIONNAIRE). Con include=events ogni voce diventa un oggetto {feature, node_id} invece di una semplice stringa, e la funzionalità email viene rinominata: compare come EMAIL in modalità eventi invece dell'EMAIL_VERIFICATION utilizzato qui.

La funzionalità della sessione.

​
vendor_data
string | null

I dati del vendor della sessione.

​
metadata
object | null

I metadati della sessione.

​
expected_details
object | null

Dettagli previsti forniti al momento della creazione della sessione — utilizzati per la convalida incrociata rispetto ai dati estratti (KYC) o per precompilare la ricerca nel registro delle imprese (KYB). Restituisce esattamente le chiavi fornite; null se non ne è stata fornita alcuna. Le sessioni KYC contengono i campi della persona; le sessioni aziendali (KYB) contengono company_name, registry_country e registration_number.

​
contact_details
object | null

Dati di contatto forniti al momento della creazione della sessione (utilizzati per le email di notifica, la verifica precompilata di telefono/email e la lingua di comunicazione). null quando non sono stati forniti né un'email né un numero di telefono.

​
callback
string<uri> | null

L'URL di callback della sessione.

​
id_verifications
object[] | null

Array di report di verifica dell'identità (OCR) prodotti dai passaggi dei documenti di identità nel grafo del workflow. Sempre un array JSON — leggi id_verifications[0] e itera se il tuo workflow può eseguire più di un controllo dell'identità (ad esempio un controllo primario più uno step-up). null fino a quando almeno un passaggio di verifica dell'identità non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, campi estratti del documento, URL delle immagini, punteggi di qualità, MRZ, analisi dell'indirizzo, corrispondenze cross-sessione e warnings[].

​
nfc_skip_reason
enum<string> | null

Il motivo per cui la verifica del chip NFC non è stata eseguita, valorizzato ogni volta che il workflow include un passaggio NFC. null mentre l'NFC è in attesa o quando il chip è stato effettivamente letto. Valori: USER_SKIPPED - l'utente ha scelto di saltare su un dispositivo compatibile con NFC (consentito da allow_nfc_skip); DOCUMENT_WITHOUT_CHIP - il documento non ha un chip NFC leggibile (non è un documento elettronico ICAO 9303); CHIP_CERTIFICATE_UNAVAILABLE - il certificato di firma del paese di emissione (CSCA) che copre il periodo di emissione del documento non è disponibile, quindi la firma del chip non può essere verificata; DEVICE_WITHOUT_NFC - il dispositivo ha segnalato l'assenza di un lettore NFC; INTEGRATION_WITHOUT_NFC_ACCESS - la verifica è stata eseguita senza un SDK nativo (ad es. in un browser web), che non ha accesso al lettore NFC del telefono; MRZ_KEY_UNAVAILABLE - non è stato possibile derivare la chiave di accesso al chip dall'MRZ del documento; JPKI_UNAVAILABLE - il documento è una My Number Card giapponese, il cui chip viene letto tramite JPKI, e JPKI non era disponibile per questa verifica: non è abilitato, oppure l'SDK nativo dell'app non può leggere le My Number Card.

Opzioni disponibili:
USER_SKIPPED,
DOCUMENT_WITHOUT_CHIP,
CHIP_CERTIFICATE_UNAVAILABLE,
DEVICE_WITHOUT_NFC,
INTEGRATION_WITHOUT_NFC_ACCESS,
MRZ_KEY_UNAVAILABLE,
JPKI_UNAVAILABLE
​
nfc_verifications
object[] | null

Array di report NFC / passaporto elettronico prodotti dai passaggi NFC nel grafo del workflow. Questo è sempre un array JSON, mai un singolo oggetto nfc — leggi nfc_verifications[0] e itera se il tuo workflow può eseguire l'NFC più di una volta. null fino a quando almeno un passaggio NFC non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, chip_protocol, chip_data, authenticity (integrità SOD + DG), certificate_summary e warnings[]. Una Japan My Number Card viene letta tramite JPKI anziché ICAO 9303: il relativo elemento ha chip_protocol: "jpki", contiene le prove sotto jpki e lascia i campi ICAO null. Quando il passaggio NFC è stato ignorato prima ancora di poter essere proposto (documento senza chip, certificato mancante, nessuna funzionalità NFC segnalata, chiave MRZ illeggibile, JPKI non disponibile per una My Number Card), questo rimane null e nfc_skip_reason ne spiega il motivo; se viene ignorato durante il passaggio stesso (l'utente ha toccato il pulsante «Ignora» o il lettore è risultato non disponibile al momento della scansione) viene comunque prodotto un report con is_nfc_skipped: true.

​
liveness_checks
object[] | null

Array di report di rilevamento della vitalità prodotti dai passaggi di rilevamento della vitalità nel grafo del workflow. Sempre un array JSON — mai un singolo oggetto liveness. null fino a quando almeno un passaggio di rilevamento della vitalità non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, method, score, reference_image, video_url, age_estimation opzionale, matches[] cross-sessione e warnings[].

​
face_matches
object[] | null

Array di report di confronto facciale prodotti dai passaggi di confronto facciale nel grafo del workflow. Sempre un array JSON — mai un singolo oggetto face_match. null fino a quando almeno un passaggio di confronto facciale non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, lo score di similarità, source_image, target_image e warnings[].

​
phone_verifications
object[] | null

Array di report di verifica telefonica — sempre un array JSON, mai un singolo oggetto phone. null fino a quando almeno un passaggio telefonico non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, il numero di telefono e i metadati del paese, lifecycle[], matches[] e warnings[].

​
email_verifications
object[] | null

Array di report di verifica email — sempre un array JSON, mai un singolo oggetto email. null fino a quando almeno un passaggio email non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, l'indirizzo email, i dati sulle violazioni, lifecycle[], matches[] e warnings[].

​
poa_verifications
object[] | null

Array di report di Prova di residenza (POA) — sempre un array JSON, mai un singolo oggetto poa. null fino a quando almeno un passaggio POA non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, l'URL del file del documento, l'ente emittente, le date, l'indirizzo analizzato e warnings[].

​
document_ai_documents
object[] | null

Report di Document AI raggruppati per nodo del workflow — sempre un array JSON, mai un singolo oggetto. null finché almeno un passaggio di Document AI non ha prodotto dati. Presente solo quando session_kind = user. Ogni elemento è un gruppo di nodi con uno status aggregato, il node_id, un array items[] dei risultati per documento (dati estratti indicizzati dalla chiave di campo configurata) e warnings.

​
questionnaire_responses
object[] | null

Array di report delle risposte ai questionari — sempre un array JSON, mai un singolo oggetto questionnaire. null fino a quando almeno un passaggio con questionario non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, i metadati del questionario, le sezioni con gli elementi del modulo e le risposte dell'utente.

​
bank_verifications
object[] | null

Risultati della verifica bancaria, un elemento per ciascun passaggio di verifica bancaria, per la Verifica degli utenti e la Verifica aziendale. null finché un passaggio non ne produce uno. Il parametro method di ciascun elemento indica come è stato verificato il conto: open_banking (accesso bancario) o account_lookup (controllo del conto), oppure un'alternativa tramite statement o microdeposits, e none quando la persona ha proseguito senza una banca prima della valutazione di qualsiasi tentativo (continued_without_bank). Consulta Metodi di verifica bancaria.

​
signatures
object[]

Risultati di Firma elettronica, un elemento per ciascun firmatario e passaggio di firma, per la Verifica degli utenti e la Verifica aziendale (KYB). Presente solo quando il workflow ha un passaggio di Firma elettronica; un array vuoto finché un firmatario non lo raggiunge. Consulta il report di Firma elettronica.

​
aml_screenings
object[] | null

Array di report di screening AML — sempre un array JSON, mai un singolo oggetto aml. null finché almeno un passaggio AML non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, total_hits, entity_type, hits[], score, screened_data, is_ongoing_monitoring_enabled e warnings[].

​
ip_analyses
object[] | null

Array di report di Analisi dispositivo e IP — sempre un array JSON, mai un singolo oggetto ip_analysis. null fino a quando almeno un passaggio di analisi IP non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, status a livello di funzionalità, dati IP e di geolocalizzazione, fingerprint del dispositivo e warnings[]. Le voci con (node_id, ip_address, device_fingerprint) duplicati vengono deduplicate lato server.

​
geolocation_checks
object[] | null

Array di risultati della verifica della posizione, uno per ciascun passaggio di verifica della posizione: il tentativo accettato di quel passaggio. null fino a quando un passaggio di verifica della posizione non ha prodotto dati. I tentativi precedenti dello stesso passaggio si trovano in geolocation_attempts.

​
geolocation_attempts
object[] | null

Ogni tentativo di ciascun passaggio di verifica della posizione di questa sessione, dal più vecchio al più recente. I tentativi sostituiti da un nuovo invio vengono omessi. Un workflow che esclude geolocation_checks tramite i propri attributi di risposta esclude anche questo elenco.

​
database_validations
object[] | null

Array di report di Validazione su database — sempre un array JSON, mai un singolo oggetto database_validation. null finché almeno un passaggio di validazione su DB non ha prodotto dati. Ciascun elemento è il report completo, inclusi node_id, lo status a livello di funzionalità, screened_data, i validations[] per servizio (ciascuno con i relativi source_data del registro) e warnings[]. I campi screened_data e source_data variano in base al paese:

ARG (Argentina): screened_data: {document_number, selfie, gender, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, date_of_death, tax_id, tax_id_type, face_match_score, sit_1_since, banks, last_position, highest_position, rejected_checks}. Utilizza la validazione biometrica di confronto facciale RENAPER. Il genere viene dedotto automaticamente dall'analisi del volto o dal nome proprio quando non è presente nel documento (es. patenti di guida)

BOL (Bolivia): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender}

BRA (Brasile): screened_data: {tax_number, first_name, last_name, date_of_birth}. source_data include sempre {identification_number, first_name, last_name, date_of_birth, lgpd_minor, minor_under_18, minor_under_16} per corrispondenze CPF riuscite. Le ricerche riuscite per adulti impostano tali flag su false. Il servizio Consulta CPF della Receita Federal può restituire HTTP 422 (minore di 18 anni) o 451 (minore di 16 anni) con dati omessi in conformità alla LGPD; in tali casi source_data imposta i flag per minori su true come opportuno, include il codice di stato HTTP del servizio upstream e la validazione a livello di campo è no_match. Consulta la sezione Brasile del riferimento Database Validation Outcome Codes per l'elenco completo dei codici.

CHL (Cile): screened_data: {personal_number, first_name, last_name, date_of_birth}. source_data: {identification_number, first_name, last_name, date_of_birth, gender}

COL (Colombia): screened_data: {document_number, document_type, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, document_type}

CRI (Costa Rica): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

DOM (Repubblica Dominicana): screened_data: {personal_number}. source_data: {identification_number} (restituisce solo valid/invalid)

ECU (Ecuador): screened_data: {personal_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, street, formatted_address, gender, nationality, education, marital_status, spouse, mother_name, father_name, profession}

ESP (Spagna): screened_data: {personal_number, document_type, expiration_date, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, document_type, expiration_date}

GTM (Guatemala): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

HND (Honduras): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

MEX (Messico): screened_data: {personal_number (CURP), first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, date_of_birth, gender, nationality, curp_status, state_of_birth, doc_probatorio, registration_year, registration_state, registration_municipality, num_acta, crip, issuing_state_code, foreign_registry_number, folio_carta, folio_certificado}. Utilizza il registro civile RENAPO. È inoltre disponibile un servizio separato di controllo validità INE per MEX come validazione aggiuntiva una per volta.

PAN (Panama): screened_data: {personal_number, selfie}. source_data: {identification_number}. Utilizza la validazione biometrica SIB

PER (Perù): screened_data: {personal_number (DNI), first_name, last_name}. source_data: {identification_number, first_name, last_name, paternal_name, maternal_name, verification_number, verification_letter}

PRY (Paraguay): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

SLV (El Salvador): screened_data: {document_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

URY (Uruguay): screened_data: {personal_number, date_of_birth, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name}

VEN (Venezuela): screened_data: {document_number, first_name, last_name}. source_data: {identification_number, first_name, last_name, full_name, gender, date_of_birth, document_type}

​
database_validation_not_performed_reason
object | null

Il motivo per cui una validazione su database configurata non ha prodotto alcun risultato, sotto forma di {code, message} più i campi di contesto. Presente solo quando database_validations è null per un workflow che include il passaggio, consentendoti di distinguere "il registro ha confermato" da "non è stato eseguito nulla". null altrimenti.

​
reviews
object[]
​
assignee
object | null

Il revisore della Console a cui è assegnata la sessione, oppure null se non è assegnata a nessuno.

​
waiting_since
string<date-time> | null

Quando la sessione ha iniziato l'attesa per la revisione. null a meno che la sessione non sia In Review e la tua applicazione imposti una scadenza di revisione.

​
sla_due_at
string<date-time> | null

Termine entro cui la revisione deve essere completata. null a meno che la sessione non sia In Review e la tua applicazione imposti una scadenza di revisione.

​
created_at
string<date-time>

Timestamp di creazione della sessione (ISO 8601, UTC).

​
expires_at
string<date-time> | null

Timestamp in cui è prevista la scadenza di questa sessione. Impostato sulle sessioni di Verifica degli utenti (KYC) quando è stata configurata una scadenza al momento della creazione (o una volta che lo stato Approved attiva il calcolo della scadenza del KYC). null per le sessioni senza una scadenza configurata e per le tipologie che non utilizzano la scadenza (ad es. sessioni di Verifica aziendale (KYB) che non hanno mai ricevuto un expires_at).

​
registry_checks
object[] | null

Controlli del registro delle imprese. Presente solo quando session_kind = business. Ciascun elemento include l'intero payload del registro delle imprese.

​
key_people_checks
object[] | null

Controlli aggregati sulle persone chiave. Presente solo quando session_kind = business. Ciascun elemento utilizza la struttura a due contenitori (registry, submitted, ubo_kyc_summary).

​
document_verifications
object[] | null

Controlli di verifica del documento raggruppati per nodo del workflow. Presenti solo quando session_kind = business.

​
environment
enum<string>

Indica se la sessione è stata creata da un'applicazione di produzione (live) o da un'applicazione sandbox (sandbox). Le sessioni sandbox sono gratuite, interamente simulate e non consumano mai crediti.

Opzioni disponibili:
live,
sandbox
​
sandbox_scenario
string | null

Lo scenario sandbox con cui è stata creata la sessione. null per le sessioni di produzione e per le sessioni sandbox create senza di esso.

​
resubmissions
object[]

Restituito solo con include=resubmissions, per sessioni utente e aziendali. Una voce per ogni richiesta di nuovo invio, dalla meno recente alla più recente. Ogni voce include i risultati restituiti dai passaggi reinviati prima della richiesta, in modo che i precedenti invii rimangano leggibili. L'eliminazione della sessione elimina tutti gli invii.

​
biometric_consent
object | null

Indica se la sessione ha richiesto un consenso biometrico esplicito prima dell'acquisizione del volto, per quale motivo e la prova della risposta. Solo sessioni di Verifica degli utenti (KYC); lo stesso oggetto è presente in decision dei webhook di sessione. null se la sessione non è mai stata valutata, ad esempio in un workflow senza acquisizione del volto. I campi senza alcun valore registrato sono null. Un SDK nativo inferiore a 4.10.0, o che non segnala la propria versione, non può mostrare il passaggio di consenso: le acquisizioni del volto proseguono come prima e una sessione che richiedeva il consenso segnala quindi status: "pending" con reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK". Consulta Consenso biometrico.

​
investigator
object | null

L'ultima revisione Investigator dell'elemento, o null se non ne ha mai avuta una. Inclusa nella decisione della sessione V3 e della sessione aziendale (e quindi dai webhook status.updated).

​
biometric_retention
object

Quando i dati biometrici acquisiti durante questa sessione vengono eliminati.

​
fraud_check
object | null

Il risultato di una chiamata alla Fraud Check API. null per qualsiasi altra sessione.

​
full_session_video
string<uri> | null

URL con scadenza della registrazione completa della sessione. Restituito solo quando la tua organizzazione registra il video dell'intera sessione.

​
full_session_video_recorded_at
string<date-time> | null

Data e ora di registrazione dell'intera sessione. Restituito solo quando la tua organizzazione registra il video dell'intera sessione.

Ultima modifica il 7 novembre 2026