> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Messaggi ai clienti

> Con Didit, anteprima dei messaggi predefiniti, richiesta di informazioni a un contatto verificato e risposte dei clienti.

Apri un caso e scegli **Invia messaggio**.
Scegli un destinatario verificato, una lingua e la finalità, poi seleziona **Anteprima**.
L'anteprima mostra il mittente, il destinatario, l'oggetto e il corpo dell'email esatti.
Scegli **Modifica** per cambiare la selezione, oppure **Invia** per confermarla.
Un'anteprima modificata o scaduta deve essere generata di nuovo prima dell'invio.

## Finalità dei messaggi

| Finalità | Azione del cliente | Stato del caso |
| - | - | - |
| Documento d'identità | Caricare una foto nitida di un documento d'identità | In attesa dell'utente |
| Prova di residenza | Caricare un documento recente che mostri nome e indirizzo di residenza | In attesa dell'utente |
| Documento aziendale | Caricare un documento di registrazione dell'azienda | In attesa dell'utente |
| Conferma dei dati | Inviare nome completo e data di nascita affinché il revisore li valuti | In attesa dell'utente |
| Revisione in corso | Nessuna azione richiesta; l'email non contiene un pulsante di risposta | Invariato |

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:

```text theme={null}
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/options/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/preview/
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/cancel/
POST /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/remind/
GET  /v3/organization/{organization_id}/application/{application_id}/cases/{case_uuid}/requests/{request_uuid}/attachment/
```

La lettura della cronologia e degli allegati richiede `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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.