Vai al contenuto principale
L’SDK JavaScript di Didit offre un modo programmatico per integrare la verifica nella tua applicazione web, con pieno controllo sull’esperienza utente.

Funzionalità

  • API semplice - Pattern singleton con metodi facili da usare
  • Integrazione flessibile - Usa direttamente l’URL UniLink oppure crea sessioni dal backend
  • Responsive - Funziona su browser desktop e mobile
  • Personalizzabile - Opzioni di configurazione per stile e comportamento
  • Formati multipli - Build ESM, CommonJS e UMD
  • Supporto TypeScript - Definizioni dei tipi complete incluse
  • Modalità modale e inline - Scegli tra overlay modale o integrazione inline
  • Callback degli eventi - Eventi in tempo reale sull’avanzamento della verifica (avviata, passaggio completato, terminata)
  • Gestione dello stato - Osserva lo stato dell’SDK per interfacce personalizzate

Installazione

NPM/Yarn

CDN (UMD)

L’ultima release pubblicata su npm è 0.5.1. 0.5.0 ha aggiunto DiditSdk.shared.submitEvent() (vedi Invio di eventi), e 0.5.1 permette al flusso ospitato di richiedere all’interno dell’SDK l’ID dell’utente da un wallet di identità digitale, e mantiene un avvio non riuscito nello stato error con il relativo errorMessage. 0.4.0 ha aggiunto le opzioni della fotocamera già offerte dagli SDK nativi, incluso defaultLivenessCamera, che apre l’acquisizione del volto con la fotocamera posteriore (vedi Opzioni della fotocamera).

Verifica della versione installata

Il tuo gestore dei pacchetti resta la fonte autorevole per la versione installata:
Puoi anche ispezionare l’export a runtime:
Dalla versione 0.3.1 questo export viene generato dalla versione del pacchetto in tutti i formati JavaScript (ESM, CommonJS, UMD, UMD minificato) e nella dichiarazione TypeScript, quindi corrisponde sempre alla release installata. Le versioni 0.3.0 e precedenti restituiscono 0.2.1 da questo export, indipendentemente dalla versione installata. Su queste release usa npm list oppure il tuo file di lock.

JavaScript puro

ES Modules / TypeScript

Tag script (UMD)


Esempi per framework

Esempi web per SDK

React, Angular, Svelte, Next.js, Nuxt, Vue e altri, con esempi e documentazione per ciascun framework.

Metodi di integrazione

Ci sono due modi per integrare l’SDK: Usa direttamente l’URL UniLink del tuo workflow dalla Didit Console. Non serve un backend.
Ottieni il tuo URL UniLink dalla Didit Console → Il tuo workflow → Copia link. Il session_id generato ti verrà inviato tramite un evento. Consulta qui il riferimento degli eventi

Metodo 2: sessione lato backend (consigliato per la produzione)

Il tuo backend crea una sessione tramite l’API di Didit e restituisce l’URL di verifica ospitato. Questo ti consente di controllare vendor_data, il callback per sessione, i metadata, e di creare sessioni prima che l’utente raggiunga il frontend. Maggiori informazioni nel riferimento dell’API Create Session. Backend (Node.js / Express)
Frontend
Il campo della risposta di creazione sessione si chiama url (vedi lo schema OpenAPI di Create Session). Passalo direttamente a startVerification({ url }).

Configurazione

Consulta le definizioni complete dei tipi TypeScript più sotto per l’interfaccia completa DiditSdkConfiguration.

Opzioni della fotocamera

Le opzioni della fotocamera richiedono @didit-protocol/sdk-web 0.4.0 o successiva.
L’SDK web espone le stesse quattro opzioni della fotocamera degli SDK nativi. Per impostazione predefinita, l’acquisizione del documento apre la fotocamera posteriore e l’acquisizione del volto (vitalità) apre la fotocamera anteriore (selfie), e in entrambi i passaggi è disponibile un selettore di fotocamera durante l’acquisizione sui dispositivi con più di una fotocamera. Imposta defaultLivenessCamera: 'back' per aprire l’acquisizione del volto con la fotocamera posteriore, ad esempio in un chiosco o quando un operatore tiene il dispositivo e lo punta verso la persona da verificare.
  • I valori accettati per l’obiettivo sono 'front' e 'back'. Qualsiasi altro valore viene ignorato, così come un flag del selettore che non è un booleano.
  • Un dispositivo privo della fotocamera richiesta mantiene quella che ha: un laptop a cui viene richiesta 'back' usa comunque la webcam. Il selettore è nascosto sui dispositivi con una sola fotocamera, indipendentemente dai flag.
  • Le opzioni di rilevamento della vitalità si applicano al controllo passivo della vitalità. Il rilevamento attivo della vitalità non è influenzato.
  • L’SDK inoltra le opzioni alla pagina di verifica come parametri di query dell’URL di verifica: document_camera, liveness_camera, document_camera_switch e liveness_camera_switch. Se apri direttamente l’URL di verifica invece di passare dall’SDK, impostali tu: aggiungi ?liveness_camera=back a un URL senza stringa di query, &liveness_camera=back a un URL che ha già dei parametri, oppure impostali con l’API URL, che gestisce entrambi i casi:

Invio di eventi

DiditSdk.shared.submitEvent() mette in coda gli eventi dell’utente finale (registrazione, accesso, accesso non riuscito, disconnessione, reimpostazione della password, MFA, cambio di dispositivo) per il monitoraggio degli eventi di Didit. Il tuo backend genera un token di monitoraggio per la persona, e l’SDK invia gli eventi in batch insieme all’impronta del dispositivo. Non inviare mai una chiave API al browser.
Consulta Invio di eventi tramite SDK per il token, i campi degli eventi e il comportamento di consegna.

Dimensionamento e scorrimento della modale

Il comportamento di dimensionamento descritto qui richiede la versione 0.3.1 o successiva. Le versioni 0.3.0 e precedenti possono tagliare il flusso di verifica su viewport desktop e in orientamento orizzontale di altezza ridotta.
La modalità modale usa una larghezza massima di 500px e un’altezza massima di 700px. Su entrambi i viewport, desktop e in orientamento orizzontale, quando hanno altezza ridotta, l’iframe occupa il 90% della viewport visibile. Il flusso di verifica scorre all’interno dell’iframe, così ogni passaggio resta raggiungibile mentre la pagina sotto la modale rimane bloccata. L’SDK usa dvh sui browser che supportano le unità di viewport dinamiche e ricorre a vh sui browser meno recenti supportati. Con larghezze di 540px o inferiori, la modale occupa l’intera viewport visibile. Il pulsante di chiusura e la conferma di uscita restano all’interno della modale.

Flusso di verifica ridisegnato

Tutto il contenuto di questa sezione si applica dalla versione 0.5.0, che non è ancora stata pubblicata. Finché non esegui l’aggiornamento, la modale mantiene le dimensioni descritte sopra.
Dalla versione 0.5.0, la modale si dimensiona in base al flusso di verifica ridisegnato, una volta che la pagina comunica il proprio layout con un messaggio didit:layout:
  • Dimensione iniziale, dalla versione 0.5.0: finché la pagina non comunica il proprio layout, e per le pagine che non lo fanno mai, la modale mantiene la dimensione massima esistente di 500px per 700px. Continua ad adattarsi alle finestre di altezza ridotta e resta a schermo intero a 540px o meno.
  • Pulsante di chiusura, dalla versione 0.5.0: un cerchio di 44px sovrapposto alla barra superiore della pagina. Segue il tema chiaro o scuro della pagina e si sposta a sinistra nelle lingue da destra a sinistra.
  • Modalità incorporata, dalla versione 0.5.0: continua a riempire il proprio elemento host, come prima (vedi Modalità incorporata).
  • URL di verifica, dalla versione 0.5.0: l’SDK aggiunge sdk_presentation (modal o embedded) e, in una modale, sdk_close_button (true o false, in base a showCloseButton), così la pagina sa come viene mostrata.
  • Eventi, dalla versione 0.5.0: l’SDK gestisce didit:layout da solo e non lo passa a onEvent.
Non c’è nulla da configurare, e tutte le opzioni esistenti continuano a funzionare.

Modalità incorporata

La modalità incorporata non usa il limite di 500px per 700px della modale. L’SDK riempie il riquadro del contenuto dell’elemento host, quindi assegna a quell’elemento un’altezza esplicita o comunque risolta:
Se l’host non ha un’altezza risolta, anche l’iframe incorporato non ha un’altezza utilizzabile. Ridimensiona l’host quando cambia il layout; l’SDK continua a riempirlo automaticamente.

Risultati della verifica

L’SDK restituisce tre tipi di risultato:

Completato

Il flusso di verifica è terminato (approvato, in attesa o rifiutato).
Il tipo TypeScript dichiara 'Approved' | 'Pending' | 'Declined', ma il valore viene passato dallo stato della sessione del flusso ospitato: potresti ricevere anche altri stati, come In Review. Pending è il valore di ripiego dell’SDK quando il flusso non ha riportato alcuno stato. Tratta status come un’indicazione e affidati al webhook per la decisione definitiva.

Annullato

L’utente ha chiuso la modale di verifica. session è incluso quando un sessionId era già noto (può essere undefined se l’utente ha annullato prima che l’iframe ne riportasse uno).

Non riuscito

Si è verificato un errore durante la verifica.

Gestione dello stato

Puoi osservare lo stato dell’SDK per creare un’interfaccia personalizzata:

Riferimento API

DiditSdk.shared

L’istanza singleton dell’SDK.

Metodi

Proprietà

Callback


Eventi granulari

Monitora l’avanzamento della verifica con il callback onEvent:

Riferimento agli eventi

Connessione persa

Se la connessione dell’utente cade, la pagina di verifica sovrappone al flusso una schermata «Nessuna connessione internet» invece di lasciare un passaggio in caricamento. La pagina continua a controllare in background e chiude da sola la schermata appena Didit torna raggiungibile, e l’utente prosegue dal passaggio in cui si trovava. All’interno della modale o di un iframe dell’SDK, la schermata offre anche Exit Verification: in quel caso la pagina invia didit:error con error: "network_error", seguito da didit:cancelled, e l’SDK chiude la modale e chiama onComplete con type: "cancelled". A partire dalla versione 0.5.0, il messaggio didit:layout della pagina dimensiona la modale e non raggiunge onEvent. Se invece incorpori la pagina con un tuo iframe, consulta Dimensionare l’iframe da didit:layout.

Valori di passaggio

Il campo step può assumere uno dei seguenti valori:
  • document_selection - Selezione del tipo di documento
  • document_front - Lato anteriore del documento
  • document_back - Lato posteriore del documento
  • face - Verifica del volto e della vitalità
  • email - Verifica email
  • phone - Verifica telefonica
  • poa - Prova di residenza
  • questionnaire - Passaggio del questionario

Valori di canale

Il campo channel in code_sent può essere:
  • email - Codice inviato via email
  • sms - Codice inviato via SMS
  • whatsapp - Codice inviato via WhatsApp

Dimensione del codice

Il campo codeSize in code_sent indica la lunghezza del codice OTP (ad esempio 4 o 6 cifre).

Tipi TypeScript

Ultima modifica il 7 novembre 2026