Vai al contenuto principale
The Didit API signala un errore con un codice di stato HTTP e, quasi sempre, con un corpo JSON. Questa pagina elenca il significato di ogni stato, la struttura del corpo, i valori code su cui puoi basare la logica del tuo codice e gli errori che si possono ripetere in sicurezza. Basati prima sullo stato e, quando è presente, su code, perché il testo di un messaggio può cambiare.

Codici di stato

Corpi degli errori

I corpi di errore non hanno un formato unico, quindi leggili in modo difensivo. Il formato dipende dalla famiglia di endpoint: Un 500 potrebbe non avere affatto un corpo JSON, quindi gestisci anche un corpo che non può essere interpretato.

Errori delle chiavi API

Per alcuni minuti dopo l’eliminazione di un’applicazione, l’API risponde con application_deleted; dopo di che rifiuta la chiave come qualsiasi chiave errata. Non riprovare: l’applicazione e le sue chiavi sono state eliminate. Consulta Autenticazione API e Chiavi API per capire come funzionano le chiavi e i relativi limiti.

Crediti insufficienti

Ogni famiglia di API segnala un saldo basso in modo diverso: Con un contratto, la creazione di una sessione risponde con 403 e "code": "contract_billing_suspended" mentre i servizi a pagamento sono sospesi per la tua organizzazione. Le applicazioni sandbox non vengono mai addebitate, quindi non sono soggette a questi controlli.

Codici di errore

Questi valori code sono stabili, quindi puoi basarti su di essi per gestire i casi. La maggior parte si trova accanto a detail; nella verifica con wallet di identità digitale il codice è il valore di error.

Accesso e fatturazione

Richieste e idempotenza

Controlli bancari, telefonici e di rischio

Verifica aziendale (KYB)

Wallet di identità digitale

Report e casi

Firme elettroniche

Alla creazione della sessione, i problemi relativi al documento descritti di seguito vengono restituiti come valore del campo interessato con stato 400, ad esempio {"sign": "signature_document_changed"}:

Webhook

Nuovi tentativi e idempotenza

Alcuni errori possono essere ripetuti in sicurezza, altri no:
  • 429: attendi il valore dell’intestazione Retry-After, poi riprova.
  • 502 e 503: riprova con backoff quando il riferimento dell’endpoint indica che non è stato addebitato nulla, come avviene per i controlli telefonici, email, bancari e di rischio.
  • 502 su POST /v3/database-validation/: leggi prima ogni voce di validation_errors, perché questo stato da solo non indica un errore temporaneo.
  • 503 su una cancellazione: ripeti la stessa richiesta finché non restituisce 200.
  • Altri 4xx: correggi prima la richiesta, perché la stessa richiesta fallisce allo stesso modo.
POST /v3/aml/ e la verifica del wallet Digital ID accettano un’intestazione Idempotency-Key di massimo 255 caratteri. Ripetere una richiesta con la stessa chiave e lo stesso corpo restituisce la risposta memorizzata, quindi l’operazione viene eseguita e l’addebito viene effettuato una sola volta. La stessa chiave con un corpo diverso restituisce 409, e mentre la prima richiesta è ancora in esecuzione gli endpoint del wallet rispondono 409 con Retry-After. POST /v3/session/ non ha una chiave di idempotenza, quindi se la creazione va in timeout, elenca le tue sessioni per vendor_data prima di crearne un’altra.

Correlati

Ultima modifica il 7 novembre 2026