Passaggio 1: Ottieni le tue credenziali
Hai due modi per ottenere unaapi_key:
Opzione A: Registrazione programmatica (senza browser)
Ideale per CI/CD e agenti AI. Due chiamate API,POST /programmatic/register/ e poi POST /programmatic/verify-email/, restituiscono la api_key direttamente nella risposta.
→ Vedi Registrazione programmatica per il flusso completo, le regole sulle password, la durata del JWT e la politica di blocco.
Opzione B: Dalla Didit Console
- Vai alla Didit Console.
- Crea o seleziona la tua organizzazione.
- Vai su Settings → API & Webhooks.
- Copia:
- API Key: viene usata come intestazione
x-api-keyin ogni chiamata di verifica. - Webhook Secret Key: viene usata per verificare le firme HMAC dei webhook.
- API Key: viene usata come intestazione
Variabili d’ambiente
Passaggio 2: Crea un workflow
Prima di creare le sessioni, ti serve un workflow di verifica. I workflow definiscono i passaggi di verifica che l’utente deve completare.Crea nella Console
- Vai alla Didit Console → Workflows
- Fai clic su Create Workflow
- Scegli un modello di base:
- Aggiungi le funzionalità facoltative:
- Copia l’ID del workflow
Vedi la Documentazione sui workflow per le opzioni di configurazione dettagliate.
Passaggio 3: Crea una sessione di verifica
Chiama l’API per creare una sessione per il tuo utente.Richiesta
Parametri della richiesta
Esempio completo con tutte le opzioni
expected_details.expected_document_types limita il passaggio di verifica
dell’identità a tipi di documento specifici: la schermata di selezione del
documento mostra solo i tipi richiesti. Valori ammessi: P (passaporto), ID
(carta d’identità nazionale), DL (patente di guida), RP (permesso di
soggiorno), HIC (tessera assicurativa sanitaria), TC (tessera fiscale) e
SSC (tessera previdenziale). I valori non distinguono maiuscole e minuscole e
i duplicati vengono eliminati; i valori sconosciuti restituiscono 400. Consulta
lo schema completo nel riferimento Create Session.Risposta
201 Created:
Campi principali della risposta
Idempotenza. Quando
vendor_data è fornito e nell’ultima versione pubblicata
del workflow esiste già una sessione non completata (Not Started, In Progress,
Resubmitted o Awaiting User) con lo stesso vendor_data, viene restituita
quella sessione (sempre con 201) invece di crearne un duplicato. Il suo
callback e i suoi metadata vengono aggiornati con i nuovi valori, e status
riflette lo stato della sessione esistente.Se manca
x-api-key, la risposta è 403 con
{"detail": "You do not have permission to perform this action."}, lo stesso
corpo restituito per una chiave valida ma senza autorizzazioni. Una chiave
errata, revocata o scaduta restituisce 401. Crediti insufficienti restituiscono
400. Consulta Create Session API Reference per la documentazione completa.Passaggio 4: Presenta la verifica all’utente
Scegli come presentare il flusso di verifica al tuo utente:Opzione A: SDK nativo (consigliato per il mobile)
Usa ilsession_token con gli SDK nativi per l’integrazione di fotocamera, NFC e biometria.
→ iOS SDK · Android SDK · React Native · Flutter
Opzione B: iframe InContext (consigliato per il web)
Incorpora la verifica nella tua pagina usando l’url restituito nel Passaggio 3.
Opzione C: Reindirizzamento
Reindirizza l’utente all’URL di verifica.Opzione D: WebView mobile
Per le app mobili senza SDK nativo.Step 5: Ricevere i risultati
Tramite webhook (consigliato)
I webhook notificano il tuo server in tempo reale quando lo stato di una verifica cambia. Configurazione:- Crea una destinazione webhook nella Console (API e Webhook) oppure tramite
POST /v3/webhook/destinations/conwebhook_version: "v3"e un arraysubscribed_events(ad esempio["status.updated"]) - Conserva il
secret_shared_keyrestituito alla creazione: è il segreto HMAC per tutte le varianti della firma - Implementa un endpoint webhook sul tuo server
decision, ogni risultato per singola funzionalità viene consegnato come array plurale (id_verifications[], nfc_verifications[], liveness_checks[], face_matches[], …), con una voce per ogni nodo del workflow. Questo è il contratto V3 ed è vincolante: non scrivere mai codice che usi le chiavi al singolare nfc / id_verification / liveness.
decision è presente solo quando status è Approved, Declined, In Review o Abandoned (un evento Resubmitted contiene invece resubmit_info). Didit riutilizza lo stesso event_id nei nuovi tentativi e nelle destinazioni multiple: usa quell’ID per gestire l’idempotenza. Consulta Modelli dei dati per tutti gli array plurali e i campi.
Verifica della firma (X-Signature-V2, consigliato):
X-Signature-V2 è un HMAC-SHA256 calcolato su una ricodifica canonica del corpo JSON: i float con valore intero vengono accorciati a interi, le chiavi vengono ordinate ricorsivamente, i separatori sono compatti e i caratteri Unicode vengono preservati.
X-Signature sui byte grezzi, la variante obsoleta X-Signature-Simple che copre solo l’envelope, e come scegliere tra le due. Didit ritenta le consegne fallite (5xx, 404, timeout) fino a 2 volte (dopo circa 1 minuto, poi dopo circa 4 minuti) e va in timeout dopo 5 secondi: restituisci 2xx rapidamente.
Tramite API (facoltativo)
Recupera in qualsiasi momento lo stesso payload della decisione:decision contenuto nel payload del webhook, e l’endpoint può essere chiamato in qualsiasi momento del ciclo di vita della sessione. Usa i webhook per gli aggiornamenti in tempo reale e riserva le chiamate API al recupero di dati pregressi, all’audit e alla ricostruzione: l’endpoint /decision/ è limitato a 600 richieste GET al minuto per chiave API (vedi Limitazione della frequenza). Gestione degli errori: un session_id sconosciuto restituisce 404 con {"detail": "Not found."}; gli errori di autenticazione restituiscono 403, mai 401. Gli URL dei media nella risposta sono link con firma preautorizzata a breve scadenza: recuperali subito invece di conservarli.
→ Riferimento API per il recupero della sessione
Esempi di codice completi
Node.js / Express
Python / FastAPI
Stati della sessione
Sono i 10 possibili valori distatus: stringhe esatte, sensibili alle maiuscole (nota che Kyc Expired ha una sola K maiuscola).
Consulta Stati di verifica per il ciclo di vita completo, le transizioni e il diagramma Mermaid.
Prossimi passi
- Scegli il metodo di integrazione:
- App mobili → SDK nativi
- App web → SDK web
- Configura i webhook: Webhook
- Pianifica la capacità: Limitazione della frequenza
- Gestisci ogni stato: Stati di verifica
- Personalizza il tuo workflow: Workflow
- Verifica che l’API sia raggiungibile: Healthcheck
Hai bisogno di aiuto?
- Supporto: support@didit.me
- Onboarding programmatico: Registrazione programmatica