Vai al contenuto principale
Questa guida ti accompagna nel flusso completo per integrare la verifica dell’identità Didit tramite la REST API: ottieni le credenziali, crea una sessione, presentala all’utente e ricevi i risultati.

Passaggio 1: Ottieni le tue credenziali

Hai due modi per ottenere una api_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

  1. Vai alla Didit Console.
  2. Crea o seleziona la tua organizzazione.
  3. Vai su Settings → API & Webhooks.
  4. Copia:
    • API Key: viene usata come intestazione x-api-key in ogni chiamata di verifica.
    • Webhook Secret Key: viene usata per verificare le firme HMAC dei webhook.

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

  1. Vai alla Didit Console → Workflows
  2. Fai clic su Create Workflow
  3. Scegli un modello di base:
  1. Aggiungi le funzionalità facoltative:
  1. 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 il session_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.
→ iframe InContext

Opzione C: Reindirizzamento

Reindirizza l’utente all’URL di verifica.
→ Reindirizzamento web

Opzione D: WebView mobile

Per le app mobili senza SDK nativo.
→ WebView in iOS/Android

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:
  1. Crea una destinazione webhook nella Console (API e Webhook) oppure tramite POST /v3/webhook/destinations/ con webhook_version: "v3" e un array subscribed_events (ad esempio ["status.updated"])
  2. Conserva il secret_shared_key restituito alla creazione: è il segreto HMAC per tutte le varianti della firma
  3. Implementa un endpoint webhook sul tuo server
Esempio di payload webhook: All’interno di 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.
L’oggetto 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.
→ Documentazione completa sui webhook, inclusi la 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:
La struttura della risposta (array plurali) è identica all’oggetto 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 di status: 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

  1. Scegli il metodo di integrazione:
  2. Configura i webhook: Webhook
  3. Pianifica la capacità: Limitazione della frequenza
  4. Gestisci ogni stato: Stati di verifica
  5. Personalizza il tuo workflow: Workflow
  6. Verifica che l’API sia raggiungibile: Healthcheck

Hai bisogno di aiuto?

Ultima modifica il 7 novembre 2026