Inizia
Integrazione / SDK
Verifica degli utenti
Verifica aziendale
Monitoraggio delle transazioni
ChangelogFinalità dei messaggi
Al momento i caricamenti di documenti accettano immagini JPEG, PNG e WebP fino a 5 MB.
Compaiono solo le finalità applicabili al soggetto del caso.
I modelli di email per il cliente sono attualmente disponibili in inglese, spagnolo e portoghese.
La console usa lo stesso campo email e lo stesso selettore della lingua del reinvio della sessione.
Destinatari verificati e modelli fissi
Un destinatario deve aver completato la verifica email in una sessione appartenente al soggetto del caso e all’applicazione. Un indirizzo importato o modificato in un profilo utente non stabilisce la verifica. Se non esiste alcun contatto verificato, l’editor lo spiega e l’invio resta disabilitato. I revisori non possono fornire testo email, link, indirizzi del mittente o destinatari arbitrari. L’email usa il marchio Didit o White label esistente. Un mittente personalizzato richiede che il dominio email configurato sia verificato. Ogni modello informa il destinatario che l’email non chiederà password, codici di verifica o pagamenti. Il reinvio della sessione resta un’azione separata per ripetere i controlli di verifica. La sua anteprima mostra l’email di reinvio effettiva e i controlli selezionati.Consegna e risposte
La cronologia dei messaggi distingue gli esiti di consegna in coda, in invio, inviati, simulati e sconosciuti. Un’email simulata non viene inviata. Un esito sconosciuto significa che il provider potrebbe aver accettato l’email; il sistema non la invia di nuovo automaticamente. Il nuovo tentativo di una richiesta confermata usa lo stesso ID richiesta per evitare consegne duplicate. Una richiesta che richiede un’azione ha un link di risposta sicuro valido per sette giorni. Annullare la richiesta o risolvere il caso invalida tale link, anche dopo la riapertura del caso. La pagina del cliente non rivela risultanze private del caso né altri record di origine. Una risposta inviata compare in Messaggi al cliente come prova in attesa di revisione. Il caso torna Aperto e una risoluzione già in attesa deve essere rivista di nuovo. Le risposte non possono sostituire una precedente presentazione, approvare la verifica originale, sovrascrivere l’identità del cliente né contribuire a un esito di frode. L’eliminazione della verifica di origine o del caso elimina anche le richieste al cliente e le relative prove caricate.Flusso di lavoro API
Tutti gli endpoint della console sono limitati a un’organizzazione, un’applicazione e un caso:read:cases.
Comporre, visualizzare in anteprima, confermare, annullare e sollecitare richiede write:cases.
La conferma deve includere gli stessi contact_id, purpose e language, insieme a request_id, expires_at e preview_token restituiti dall’anteprima.
La ricevuta di conferma scade dopo 15 minuti, indipendentemente dalla scadenza della risposta del cliente.
Un sollecito invia di nuovo la stessa email allo stesso destinatario verificato, al massimo una volta ogni 24 ore per richiesta.
Non modifica altro: la richiesta mantiene la sua scadenza e il caso mantiene il proprio stato.
La risposta restituisce la richiesta, reminded_at, il delivery_status del sollecito (SENT, SIMULATED o UNKNOWN) e next_reminder_at.
Una richiesta a cui il cliente non deve più rispondere restituisce 409 con code case_request_not_waiting e un reason: answered, cancelled, expired, closed, not_actionable, not_delivered o contact_unavailable.
Un secondo sollecito entro 24 ore restituisce 429 con code case_request_reminder_too_soon, un timestamp retry_at e un’intestazione Retry-After.
Mentre una risoluzione è in attesa di approvazione, un sollecito restituisce 400.
L’endpoint per il cliente è GET o POST /v3/case-requests/{request_uuid}/ con il relativo header X-Case-Request-Token, specifico per la richiesta.
Il link di risposta contiene tale credenziale nel frammento; la pagina rimuove il frammento all’apertura.
Il token concede l’accesso solo a quella richiesta.