Vai al contenuto principale
Le sessioni sono l’unità di verifica su Didit. Quando avvii una verifica, viene creata una sessione; al termine della verifica, la sessione contiene il payload completo della decisione. La stessa API delle sessioni gestisce entrambi i tipi: Nella lezione dell’Academy su ciò che vedono gli utenti, il capitolo al minuto 5:34 mette a confronto il flusso ospitato e la creazione di schermate proprie, ed è esattamente il compromesso che questa API decide al posto tuo.

​
Il tipo è determinato dal workflow

Quando crei una sessione, passi un workflow_id. Il tipo del workflow determina se la sessione è una Verifica degli utenti o una Verifica aziendale: chi chiama l’API non sceglie il tipo separatamente. I workflow KYB creano sessioni di Verifica aziendale; i workflow KYC creano sessioni di Verifica degli utenti.

​
Discriminante session_kind

Ogni risposta relativa a una sessione (da creazione, lettura, elenco, aggiornamento dello stato, condivisione e importazione) include un campo di primo livello:
  • "user": la sessione è una Sessione di Verifica degli utenti (KYC). La risposta contiene gli array di funzionalità specifici per l’utente.
  • "business": la sessione è una Sessione di Verifica aziendale (KYB). La risposta contiene gli array di funzionalità specifici per l’azienda.
Usa questo campo per determinare la struttura della risposta lato client.
I valori dell’enum sono gli identificativi brevi "user" e "business", che teniamo brevi per comodità dell’API. I nomi completi Verifica degli utenti (KYC) e Verifica aziendale (KYB) sono usati nella documentazione per chiarezza.

​
Array di funzionalità per tipo

Gli array di funzionalità presenti in una decisione dipendono dal tipo. I campi assenti in un tipo non compaiono nella risposta di quel tipo (nessun null, nessun segnaposto):

​
Campi di primo livello comuni

Ogni sessione (di entrambi i tipi) include questi campi:

​
Endpoint supportati

Gli endpoint seguenti accettano entrambi i tipi. Non esistono percorsi separati /v3/business-session/*.

​
Come funzionano le ricerche

Le sessioni di Verifica degli utenti e di Verifica aziendale sono due tipi distinti. Gli ID sono UUID, quindi le collisioni sono impossibili. Quando chiami un endpoint con un session_id, Didit:
  1. Cerca l’id prima nella tabella delle Verifiche degli utenti (copre la maggior parte del traffico).
  2. Se non lo trova, cerca nella tabella delle Verifiche aziendali.
  3. Restituisce 404 se nessuna delle due tabelle contiene una corrispondenza.
Non è mai necessario indicare all’API quale tipo stai cercando.

​
Gli stati sono identici

I valori di stato sono gli stessi per entrambi i tipi, e l’API li restituisce esattamente come scritti qui: "Not Started", "In Progress", "Approved", "Declined", "In Review", "Abandoned", "Expired", "Kyc Expired", "Resubmitted", "Awaiting User". La corrispondenza è esatta e distingue maiuscole e minuscole. Consulta stati di verifica per il riferimento completo.

​
Webhook

Gli eventi webhook includono già un campo session_kind, così i gestori dei webhook possono smistare per tipo: Per la verifica della firma e la semantica dei nuovi tentativi, consulta webhook. Per il catalogo degli eventi della Verifica aziendale, consulta webhook KYB.

​
Prossimi passi

Crea sessione

Avvia una verifica: Verifica degli utenti o Verifica aziendale.

Recupera sessione

Recupera la decisione. Funziona per entrambi i tipi.

Elenca sessioni

Filtra per session_kind.

Aggiorna stato

Approva, rifiuta, metti in revisione, invia di nuovo.

Genera PDF

Report PDF per tipo.

Condividi e importa

Sposta le sessioni tra applicazioni.
Ultima modifica il 7 novembre 2026