Inizia
Integrazione / SDK
Verifica degli utenti
Verifica aziendale
Monitoraggio delle transazioni
Changelogvin o bank_account_number, quindi le pagine di servizio che li inviano mostrano solo cURL.
Installazione
Configurazione
Ogni SDK legge le stesse variabili d’ambiente, quindi un client creato senza opzioni è subito pronto all’uso. Gli edge runtime non hanno un ambiente di processo: lì, passa la chiave API al client Node.js come opzione.
Tutto ciò che puoi impostare tramite l’ambiente puoi anche passarlo al client, insieme a URL di base, timeout, nuovi tentativi, intestazioni predefinite e un tuo client HTTP. Crea un client per processo e condividilo: mantiene un pool di connessioni ed è sicuro da usare da più thread o task.
I metodi
account (registrazione programmatica: registrazione, accesso, organizzazioni e applicazioni) chiamano https://apx.didit.me/auth/v2 e non inviano mai la tua chiave API. Accedi con account.login, poi passa il token di accesso restituito al client come token dell’account.
Cosa fa ogni SDK
- Risorse e metodi. Le chiamate seguono le risorse dell’API:
client.<resource>.<method>(...), per esempiosessions.create,sessions.retrieve_decisionotransactions.create, con la convenzione di maiuscole e minuscole propria di ogni linguaggio. Gli id di percorso sono argomenti posizionali; il corpo e la query sono un unico insieme di campi con nome. Python, Node.js, PHP e Ruby usano i nomi dei campi dell’API (workflow_id); Go, Java e .NET usano la convenzione del proprio linguaggio (WorkflowID,workflowId,WorkflowId). - Liste. I metodi di lista scorrono automaticamente tutti i risultati (internamente usano
limiteoffset) e rendono disponibile anche ogni pagina tramitecount,next,previouseresults. In Ruby,auto_paging_eachattraversa tutte le pagine, etotal_count,next_urleprevious_urldi una pagina corrispondono acount,nextepreviousdell’API. - File. I caricamenti (immagini di documenti, selfie, prova di residenza, importazioni) accettano un percorso, byte o uno stream. I download (PDF delle sessioni, report) restituiscono byte o uno stream, mai JSON analizzato.
- Compatibilità in avanti. Un campo di risposta o un valore di enum che la versione dell’SDK non conosce ancora viene mantenuto ed è leggibile, senza generare errori, così un’aggiunta all’API non interrompe un’integrazione già in uso.
- Webhook.
webhooks.verifycontrolla le intestazioniX-Signature-V2eX-Signaturee il timestamp di una consegna con il tuo segreto del webhook, e restituisce un evento tipizzato. Accetta un elenco di segreti mentre ne ruoti uno. Vedi Webhook per lo schema della firma. - Autenticazione. Un helper
Authenticationverifica i token di accesso e token ID firmati dall’emittente di Authentication, e chiama i suoi endpoint per token, sessione e step-up. Non usa mai la tua chiave API.
Errori, nuovi tentativi e timeout
Ogni errore deriva da
DiditError. In Go, ogni errore implementa l’interfaccia didit.Error ed è un tipo puntatore, come *didit.NotFoundError. Java, PHP e .NET li nominano con il consueto suffisso Exception e scrivono API come Api: DiditException, ApiStatusException, NotFoundException.
Gli SDK ritentano una richiesta non riuscita fino a 2 volte, con backoff esponenziale a partire da 0,5 secondi (jitter completo, al massimo 8 secondi) e rispettando Retry-After. GET, HEAD, PUT e DELETE vengono ritentati in caso di errori di connessione, timeout, 408, 429 e 5xx. POST e PATCH vengono ritentati solo su 429 oppure quando la connessione è fallita prima che la richiesta venisse inviata, così un nuovo tentativo non crea mai una seconda sessione o transazione. Il timeout predefinito è di 60 secondi. Ogni risposta espone anche lo stato HTTP grezzo, gli header e l’ID della richiesta. Vedi Rate limiting per i limiti alla base del 429.
Versionamento e supporto
- Gli SDK seguono il versionamento semantico, con una regola per le modifiche alle API. Una modifica che rispecchia l’API di Didit è una release minore, anche quando può compromettere il codice tipizzato (un campo il cui tipo è cambiato, un campo che ora può essere null, oppure un endpoint, un campo o un valore di enum rimosso): l’API già si comporta così per ogni chiamante, quindi una versione precedente dell’SDK non è più sicura. Le note di rilascio elencano tali modifiche sotto «Modifiche API che possono compromettere il codice tipizzato».
- Una release major riguarda solo una modifica al design dell’SDK stesso: un metodo o una risorsa rinominati o rimossi mentre l’API li mantiene, una modifica alla configurazione del client, al comportamento degli errori, dei nuovi tentativi, della paginazione o della verifica dei webhook, oppure una versione del runtime non più supportata. Quando un endpoint esce dall’API o un suo metodo viene rinominato, il vecchio metodo resta per almeno un’altra release minore, contrassegnato come deprecato, così il tuo codice continua a compilare mentre passi a quello nuovo. Ogni linguaggio mantiene il proprio numero di versione: Node.js, PHP e Ruby sono alla 2.x e gli altri alla 1.x, perché questi tre hanno rilasciato una modifica API come release major prima che questa regola esistesse.
- Sono generati dal contratto API pubblicato (
openapi-25.jsoneopenapi-auth.json), e i loro metodi Didit Authentication sono verificati rispetto aopenapi-authentication.json. Controllano tutti e tre ogni giorno, quindi un nuovo endpoint o campo arriva in una release regolare di tutti e sette gli SDK. - Ogni SDK supporta il runtime minimo indicato nella tabella e tutte le release più recenti. I suoi test vengono eseguiti sul runtime minimo e su ogni release più recente, oppure su ogni release con supporto a lungo termine per Node.js e Java.
- Il file
CHANGELOG.mddi ogni repository elenca le modifiche di ogni release. - Segnala un problema di sicurezza in privato tramite gli avvisi di sicurezza del repository dell’SDK oppure a support@didit.me.