> ## 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.
# Eliminare una sessione via API: diritto all'oblio GDPR
> Con Didit elimina una sessione KYC/KYB e i suoi dati. Di default va via anche l'embedding facciale; un modello senza immagini solo se attivato.
Prompt per eliminare la sessione
Copia il prompt negli appunti
\
\`Delete a single Didit verification session and all of its data, and control what happens to the face biometric data.
Endpoint:
DELETE https://verification.didit.me/v3/session/{session_id}/delete/
Authentication:
Use the x-api-key header with your Didit API key. Privilege: delete:sessions.
Path parameter:
\- session_id (UUID) — works for both User Verification (KYC) and Business Verification (KYB) sessions. Didit resolves the id against both session types.
Optional JSON body (send Content-Type: application/json; omit the body entirely for the default behavior):
\- retain_face_embeddings (boolean | null) — override the application's face_retention_policy for this deletion. true keeps an image-free biometric template anchored to the session's User; false deletes the face embedding with the session; omit or null to follow the application policy.
\- face_retention_days (integer 1-3650) — finite retention duration for the template. Required when retaining unless the application already sets face_retention_days.
\- face_retention_deadline (ISO 8601 datetime, future) — optional hard expiry. The template expires at the earliest of face_retention_days, the application's data-retention window, and this deadline.
\- deletion_instruction ("operational_session_delete" default | "privacy_erasure") — privacy_erasure purges every retained biometric template for the session's User and never retains a new one, regardless of the application policy. Combining privacy_erasure with retain_face_embeddings: true is rejected with 400.
\- instruction_id (string, max 255) — your own durable reference for this deletion instruction (for example your erasure-ticket id). Stored on the audit trail and on any retained template.
curl examples:
Default (follow the application policy; delete_with_session unless you opted in):
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: "
Delete the session but keep an image-free biometric template for 365 days:
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{"retain_face_embeddings": true, "face_retention_days": 365}'
Right-to-erasure request (delete the session AND purge every retained template for that person):
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}'
Response: 200 OK with a JSON body once the deletion has completed (this endpoint no longer returns 204):
\{
"session_id": "",
"session_number": 1024,
"face_retention_outcome": "deleted" | "retained_with_user" | "none" | "ineligible_no_vendor_user",
"biometric_template_uuid": "" | null,
"biometric_template_expires_at": "" | null,
"deleted_child_verifications": 0
}
\- deleted: the session and its face embedding are deleted (default behavior).
\- retained_with_user: the session is deleted; an image-free biometric template with the returned biometric_template_uuid stays anchored to the User until biometric_template_expires_at, User deletion, privacy erasure, or explicit purge. Manage it with GET/DELETE /v3/biometric-templates/{uuid}/.
\- none: the session had no face embedding (for example a KYB session or a document-only KYC session).
\- ineligible_no_vendor_user: retention was requested but the session has no linked User (no vendor_data), so nothing can anchor the template. The session and its embedding are deleted.
\- biometric_template_expires_at: when the retained template is deleted; null when no template is retained.
\- deleted_child_verifications: for a KYB session, how many verifications it created (its key people's KYC sessions and its corporate owners' KYB sessions, recursively) were deleted with it. Always 0 for a KYC session.
Behavior:
\- The session and every verification attempt it holds are deleted, including results a resubmission replaced: the decision, the extracted data, the associated feature records (ID verification, registry checks, documents, AML, IP, etc.), its reviews and activity log, and all stored files (document images, videos, portraits, selfies, POA documents, extra uploads, and E-signature documents, signed PDFs, evidence PDFs and signature images).
\- A KYB session is deleted together with the verifications it created for its key people and corporate owners. A verification it only links to (for example a reused, already approved KYC) is not deleted.
\- The session disappears immediately from /v3/sessions/ and /v3/session/{id}/decision/, and media URLs issued before the call stop resolving.
\- Webhook deliveries still queued for the session, and their retries, are dropped. Webhooks already delivered are not affected.
\- Ongoing AML monitoring and KYB registry monitoring started by the deleted verifications stop.
\- A retained biometric template never contains the face image, liveness video, document data, extracted identity fields, the decision, or the deleted session's id. It is biometric data, tenant-scoped, used only for your duplicate-face, multi-account, biometric-authentication, and list matching, and it is never used for model training or cross-customer fraud processing.
\- Share tokens issued for the session are NOT revoked, but there is nothing left for them to import: an import with one returns 400 {"share_token": ["Original session does not exist."]}.
\- Blocklist entries created from the session are NOT removed; manage those with the Lists endpoints.
\- Credits already consumed by the verification are NOT refunded.
\- The parent User or Business entity is NOT deleted; use POST /v3/users/delete/ or POST /v3/businesses/delete/ for those. Deleting the User also purges its retained biometric templates. If the User's profile portrait came from this session, the portrait is removed.
\- No webhook fires for the deletion itself.
Idempotency:
Idempotent in effect: the second call to the same session returns 404 because the session no longer exists. Deletion is permanent and cannot be undone.
Failure modes:
\- 400: {"retain_face_embeddings": ["Privacy erasure cannot retain biometric templates."]} or {"detail": "A finite biometric-template retention duration is required."} (retention requested without face_retention_days on the request or the application). Nothing is deleted.
\- 403: {"detail": "You do not have permission to perform this action."} when the key lacks delete:sessions.
\- 404: {"detail": "Not found."} when the session does not exist (or was already deleted).
\- 409: {"detail": "...", "code": "in_filed_report", "reports": [{"uuid": "...", "report_number": "SAR-0001", "report_type": "SAR", "case_uuid": "..."}]} when the session is part of a finalized regulatory report. Nothing is deleted. Delete the reports, then repeat the request.
\- 503: {"detail": "The session could not be deleted because a storage service or a monitoring provider is unavailable. The session is still in place; repeat the request to finish deleting it."} or {"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."} The session is still in place; repeat the same request until it returns 200. Some of its stored files or its face embedding may already be deleted. Retries converge on a single template.
Bulk delete:
For many KYC sessions at once, use POST /v3/sessions/delete/ with body {"session_numbers": ["1001", "1002"]} or {"delete_all": true}; it accepts the same retention and instruction fields. Up to 20 matching sessions return 200 with a per-session outcome; more return 202 with a job to poll at GET /v3/sessions/delete/{job_id}/.
Migration note:
Until this release the endpoint returned 204 No Content. It now returns 200 OK with the JSON body above. Update clients that assert on 204. The default deletion behavior is unchanged: existing applications stay on delete_with_session until you explicitly change the policy.
When to call:
\- Customer requests data erasure (GDPR Article 17): use deletion_instruction: "privacy_erasure".
\- Operational clean-up after approval while keeping duplicate detection: retain_face_embeddings: true with a finite face_retention_days.
\- Cleaning up test sessions from a staging application.
\- After exporting a decision PDF for long-term archival outside Didit.
For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`
\
Incolla in
## Supporto KYC e KYBFunziona sia per le sessioni di **Verifica degli utenti (KYC)** sia per quelle di **Verifica aziendale (KYB)**. Il `session_id` viene risolto confrontandolo con entrambi i tipi di sessione; il comportamento di eliminazione è lo stesso per entrambi. La conservazione del modello biometrico si applica solo alle sessioni KYC, perché solo le sessioni KYC contengono un embedding facciale.## Comportamento- La sessione viene eliminata insieme a tutti i tentativi di verifica che contiene, compresi i risultati sostituiti da una nuova presentazione: la sua decisione, i dati estratti, i relativi record delle funzionalità (verifiche dell'identità, controlli nei registri, documenti, AML, analisi IP e così via), le sue revisioni e il registro delle attività, e tutti i file archiviati.
- Eliminare una sessione di **Verifica aziendale (KYB)** elimina anche le verifiche create per le sue persone chiave (KYC) e per i suoi titolari effettivi (KYB), in modo ricorsivo. La risposta riporta quante sono in `deleted_child_verifications`. Una verifica alla quale la sessione è solo collegata, come un KYC già approvato e riutilizzato, non viene eliminata.
- I dati della firma elettronica vengono eliminati con essa: i documenti da firmare e i relativi file Word originali, i PDF firmati, i PDF delle prove, le immagini delle firme e tutti i valori dei campi. I loro percorsi di download restituiscono `404`.
- La sessione scompare immediatamente dalle risposte di elenco e di decisione, e gli URL dei contenuti multimediali emessi prima della chiamata smettono di funzionare.
- Le consegne di webhook ancora in coda per la sessione, e i relativi nuovi tentativi, vengono scartate.
- Il monitoraggio AML continuo e il monitoraggio del registro KYB avviati dalle verifiche eliminate si interrompono.
- L'eliminazione è definitiva e irreversibile. Non esiste un endpoint di ripristino, quindi esporta tutto ciò che ti serve, ad esempio un PDF della decisione, prima di effettuare la chiamata.
- La risposta è `200 OK`, inviata solo al completamento dell'eliminazione, con un corpo JSON che riporta cosa è successo ai dati biometrici del volto della sessione. Vedi [Migrazione](#migrazione-dalle-risposte-204) se il tuo client si aspetta ancora `204`.## Dati in un report normativo finalizzatoSe la sessione fa parte di un caso con un report normativo finalizzato, la richiesta restituisce `409` e non viene eliminato nulla. La risposta usa `code: in_filed_report` e indica ciascun report:```json theme={null}
{
"detail": "This session is part of a finalized regulatory report, so it cannot be deleted.",
"code": "in_filed_report",
"reports": [
{
"uuid": "5ec00000-0000-4000-8000-000000000007",
"report_number": "SAR-0001",
"report_type": "SAR",
"case_uuid": "c1a5e000-0000-4000-8000-000000000001"
}
]
}
```Elimina ciascun report con [Elimina report](https://docs.didit.me/it/management-api/regulatory-reports/delete.md), poi ripeti l'eliminazione. Eliminare il report non elimina la sessione; la sessione resta finché non richiami questo endpoint.## Dati biometrici del volto da eliminare o conservareOgni sessione KYC con un selfie di prova di vita contiene un embedding facciale, che alimenta la [Ricerca facciale 1:N](https://docs.didit.me/it/core-technology/face-search/overview.md) e il rilevamento dei duplicati. Per impostazione predefinita, l'embedding viene eliminato insieme alla sessione (`face_retention_policy: delete_with_session`), quindi una persona la cui sessione hai eliminata può effettuare nuovamente la verifica senza essere segnalata come duplicata.Le applicazioni che hanno bisogno che il rilevamento dei duplicati sopravviva all'eliminazione della sessione possono attivare la **conservazione del modello biometrico**. In questo caso Didit elimina la sessione e tutti i suoi dati come di consueto, e conserva un unico modello biometrico del volto, gestito separatamente e privo di immagini, associato all'[utente](https://docs.didit.me/it/entities/users/overview.md) della sessione.> [!WARNING]
>
> Un modello biometrico conservato è un dato biometrico. Non è anonimo, non è transitorio e non viene eliminato insieme alla sessione. Resta disponibile fino alla sua scadenza programmata, a una scadenza anteriore prevista dalla legge applicabile, all'eliminazione dell'utente, a una richiesta di cancellazione per motivi di privacy o a una purga esplicita. Attiva la conservazione solo se le istruzioni del titolare del trattamento e la tua informativa sulla privacy la prevedono.Che cosa contiene e che cosa non contiene un modello conservato:| Conservati | Mai conservati |
| - | - |
| Il modello numerico del volto usato per il confronto | L'immagine del volto, il video di prova di vita, le immagini dei documenti, i ritagli del ritratto e qualsiasi altro contenuto multimediale |
| Un nuovo id casuale del modello e un `provenance_reference` opaco | L'id della sessione eliminata, il suo numero, la decisione, i campi di identità estratti o i payload delle funzionalità |
| L'utente proprietario (`vendor_user_uuid`, `vendor_data` attuale) | Stato della blocklist, corrispondenze precedenti, etichette di frode o dichiarazioni di identità tra organizzazioni diverse |
| Metadati di conservazione: `retained_at`, `expires_at`, policy, override, classe di istruzione, `instruction_id` e l'id del soggetto che agisce | Indirizzi email dei soggetti che agiscono |La conservazione si configura in tre punti, dal più generale al più specifico:1) **Politica dell'applicazione** in **Business Console → App Settings → Data retention** oppure tramite `PATCH /v3/webhook/` (`face_retention_policy`, `face_retention_days`). Vedi [Conservazione dei dati](https://docs.didit.me/it/console/data-retention.md#conservazione-del-modello-biometrico).
2) **Override per singola chiamata** con `retain_face_embeddings` su questo endpoint e su [Eliminazione in batch delle sessioni](https://docs.didit.me/it/management-api/sessions/batch-delete.md).
3) **Classe di istruzione** con `deletion_instruction`. Un'istruzione `privacy_erasure` ha sempre la precedenza: elimina ogni modello conservato per quell'utente e non ne conserva mai uno nuovo.### Corpo della richiestaTutti i campi sono facoltativi. Ometti il corpo per seguire la politica dell'applicazione.| Campo | Tipo | Descrizione |
| - | - | - |
| `retain_face_embeddings` | booleano o null | Sostituisce la politica dell'applicazione per questa eliminazione. `true` conserva un modello, `false` elimina l'embedding insieme alla sessione, `null` o omesso segue la politica. |
| `face_retention_days` | intero (1-3650) | Durata di conservazione limitata del modello. Obbligatorio quando un modello viene conservato, a meno che l'applicazione non imposti già `face_retention_days`. |
| `face_retention_deadline` | datetime (ISO 8601) | Scadenza definitiva facoltativa. Deve essere nel futuro. |
| `deletion_instruction` | `operational_session_delete` (predefinito) o `privacy_erasure` | La classe dell'istruzione che stai impartendo. `privacy_erasure` elimina ogni modello conservato per l'utente della sessione prima di eliminare la sessione e non può essere combinato con `retain_face_embeddings: true`. |
| `instruction_id` | stringa (max 255) | Il tuo riferimento durevole per questa istruzione, ad esempio l'id del ticket di cancellazione. Viene registrato nel registro di audit e su ogni modello conservato. Se lo ometti, Didit ne genera uno, leggibile nel dettaglio del modello. |### Risposta```json theme={null}
{
"session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
"session_number": 1024,
"face_retention_outcome": "retained_with_user",
"biometric_template_uuid": "9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b",
"biometric_template_expires_at": "2027-10-09T10:15:00Z",
"deleted_child_verifications": 0
}
```| Campo | Descrizione |
| - | - |
| `session_id` | La sessione eliminata. |
| `session_number` | Il numero della sessione eliminata. |
| `face_retention_outcome` | Che cosa è successo ai dati biometrici del volto della sessione. Vedi la tabella seguente. |
| `biometric_template_uuid` | Id del modello biometrico conservato quando `face_retention_outcome` è `retained_with_user`; altrimenti `null`. |
| `biometric_template_expires_at` | Quando viene eliminato il modello biometrico conservato; `null` quando nessun modello viene conservato. |
| `deleted_child_verifications` | Per una sessione KYB, quante verifiche da essa create (le sessioni KYC delle sue persone chiave e le sessioni KYB dei suoi titolari effettivi, in modo ricorsivo) sono state eliminate insieme a essa. Per una sessione KYC è sempre `0`. || `face_retention_outcome` | Significato |
| - | - |
| `deleted` | La sessione e il suo embedding facciale sono eliminati. Comportamento predefinito. |
| `retained_with_user` | La sessione è eliminata. Un unico modello biometrico privo di immagini resta associato all'utente; il suo id è `biometric_template_uuid`. Gestiscilo con l'[API dei modelli biometrici](https://docs.didit.me/it/management-api/biometric-templates/overview.md). |
| `none` | La sessione non aveva alcun embedding facciale da eliminare o conservare (ad esempio una sessione KYB, o una sessione KYC senza selfie di prova di vita). |
| `ineligible_no_vendor_user` | È stata richiesta la conservazione, ma la sessione non è collegata a un utente (è stata creata senza `vendor_data`), quindi non c'è nulla a cui associare un modello. La sessione e il suo embedding facciale vengono eliminati. L'esito non idoneo viene registrato nel registro di audit. |La risposta conferma che Didit ha accettato e applicato la tua istruzione di eliminazione. Non è un certificato di cancellazione: conserva il `instruction_id` nel tuo registro di cancellazione, così potrai correlarlo in seguito con il registro di audit.### Durata della conservazione e scadenzaOgni modello conservato ha un `expires_at` definito. Didit lo imposta in base alla scadenza più anticipata determinata dai seguenti valori:1) `face_retention_days` della richiesta, oppure `face_retention_days` dell'applicazione quando la richiesta lo omette;
2) la finestra generale di conservazione dei dati dell'applicazione, quando è configurata;
3) `face_retention_deadline` della richiesta, quando è fornito.Una richiesta che conserverebbe un modello senza una durata finita viene rifiutata con `400` e non viene eliminato nulla. I modelli conservati non possono sopravvivere alla più breve tra le istruzioni applicabili del cliente, la fine della finalità, la scadenza configurata, un'istruzione di cancellazione dell'interessato o una scadenza biometrica prevista dalla legge. Sei tu a scegliere una durata che rispetti le leggi applicabili ai tuoi utenti; scegli una durata più breve ogni volta che una norma applicabile lo richiede.### Cancellazione per privacyInvia `deletion_instruction: "privacy_erasure"` quando agisci su una richiesta dell'interessato. Didit elimina ogni modello biometrico conservato collegato all'**Utente** della sessione, poi elimina la sessione e il relativo embedding. La politica di conservazione dell'applicazione non può prevalere su un'istruzione di cancellazione per motivi di privacy, e `retain_face_embeddings: true` viene rifiutato con `400`.Eliminare l'Utente con [Batch Delete Users](https://docs.didit.me/it/management-api/users/delete.md) elimina anche i modelli conservati collegati.## Cosa non viene influenzatoEliminare una sessione non esegue automaticamente queste operazioni. Se stai gestendo una richiesta di cancellazione dei dati, occupatene separatamente.- **Voci della blocklist** create a partire dalla sessione (volto o documento) restano al loro posto. Rimuovile dalla [blocklist](https://docs.didit.me/it/entities/users/blocklist.md). Una voce della blocklist facciale mantiene la propria voce biometrica, indipendente da qualsiasi modello conservato.
- **Token di condivisione** già emessi per la sessione non vengono revocati, ma non c'è più nulla da importare: un [import](https://docs.didit.me/it/sessions-api/share-session/import.md) con uno di questi token restituisce `400` con `{"share_token": ["Original session does not exist."]}`.
- **Webhook già consegnati** per la sessione non sono interessati. Le consegne ancora in coda e i relativi nuovi tentativi vengono eliminati. Per la cancellazione in sé non viene emesso alcun webhook.
- **Crediti già consumati** dalla verifica non vengono rimborsati.
- **Copie firmate già inviate via email** a un firmatario da un passaggio di firma elettronica si trovano nella casella di posta del firmatario e non sono interessate.
- L'entità padre **Utente** o **azienda** non viene eliminata. Per queste usa [Delete Users](https://docs.didit.me/it/management-api/users/delete.md) o [Delete Businesses](https://docs.didit.me/it/management-api/businesses/delete.md). Se il ritratto del profilo dell'Utente proviene dalla sessione eliminata, il ritratto viene rimosso.
- Un **modello biometrico conservato** (solo se hai scelto di conservarlo) resta finché non scade o non lo elimini. Eliminalo con la [Biometric Templates API](https://docs.didit.me/it/management-api/biometric-templates/purge.md), eliminando l'Utente, oppure ripetendo l'eliminazione di un'altra sessione dello stesso Utente con `deletion_instruction: "privacy_erasure"`.## Esempi> [tab] Predefinito (politica dell'applicazione)
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY"
> ```
>
> Risposta per un'applicazione che non ha scelto la conservazione:
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "deleted",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Conserva un modello biometrico
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"retain_face_embeddings": true, "face_retention_days": 365, "instruction_id": "cleanup-2026-08-0142"}'
> ```
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "retained_with_user",
> "biometric_template_uuid": "9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b",
> "biometric_template_expires_at": "2027-10-09T10:15:00Z",
> "deleted_child_verifications": 0
> }
> ```> [tab] Forza l'eliminazione su un'applicazione con conservazione attiva
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"retain_face_embeddings": false}'
> ```
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "deleted",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Cancellazione per privacy
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}'
> ```
>
> Prima vengono eliminati tutti i modelli conservati per l'Utente della sessione, poi la sessione viene eliminata:
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "deleted",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Sessione senza Utente
>
> Una sessione creata senza `vendor_data` non ha un Utente a cui collegare un modello:
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/7a1e9c2d-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"retain_face_embeddings": true, "face_retention_days": 365}'
> ```
>
> ```json theme={null}
> {
> "session_id": "7a1e9c2d-5f4b-4c3a-8e2d-1b0a9f8e7d6c",
> "session_number": 1031,
> "face_retention_outcome": "ineligible_no_vendor_user",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Sessione di Verifica aziendale (KYB)
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/bs-01HJX1.../delete/ \
> -H "x-api-key: YOUR_API_KEY"
> ```
>
> La verifica aziendale viene eliminata insieme alle tre verifiche che ha creato per le sue persone chiave:
>
> ```json theme={null}
> {
> "session_id": "0f3c9b7e-2d1a-4e5f-8c6b-7a9d8e1f2c3b",
> "session_number": 88,
> "face_retention_outcome": "none",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 3
> }
> ```## Errori| Stato | Quando | Corpo |
| - | - | - |
| `400` | `privacy_erasure` combinato con `retain_face_embeddings: true` | `{"retain_face_embeddings": ["Privacy erasure cannot retain biometric templates."]}` |
| `400` | Conservazione richiesta senza una durata finita, nella richiesta o nell'applicazione | `{"detail": "A finite biometric-template retention duration is required."}` |
| `403` | La credenziale non ha `delete:sessions` oppure non è proprietaria della sessione | `{"detail": "You do not have permission to perform this action."}` |
| `404` | Sessione sconosciuta o già eliminata | `{"detail": "Not found."}` |
| `503` | Un servizio di archiviazione o un provider di monitoraggio non era disponibile durante l'eliminazione della sessione. | `{"detail": "The session could not be deleted because a storage service or a monitoring provider is unavailable. The session is still in place; repeat the request to finish deleting it."}` |
| `503` | Un archivio biometrico non era disponibile durante la conservazione o l'eliminazione di un modello. I nuovi tentativi convergono su un unico modello. | `{"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."}` |Con `400` non viene eliminato nulla. Con `503` la sessione resta al suo posto: ripeti la stessa richiesta finché non restituisce `200`. Alcuni dei suoi file archiviati o il suo embedding facciale potrebbero essere già stati eliminati, quindi non fare affidamento su di essi dopo un `503`.## AutorizzazioneRichiede `delete:sessions`. La stessa autorizzazione copre sia le sessioni di Verifica degli utenti (KYC) sia quelle di Verifica aziendale (KYB), e l'override della conservazione.## Eliminazione in batchPer le operazioni di massa sulle sessioni KYC usa `POST /v3/sessions/delete/`. Accetta gli stessi campi di conservazione e istruzione. Fino a 20 sessioni corrispondenti vengono eliminate nella richiesta, con un esito per ciascuna sessione; le altre vengono eliminate tramite un [job di eliminazione](https://docs.didit.me/it/management-api/sessions/get-deletion-job.md). Vedi [Batch Delete Sessions](https://docs.didit.me/it/management-api/sessions/batch-delete.md).## Migrazione dalle risposte 204Fino a questa release l'endpoint restituiva `204 No Content`. Ora restituisce `200 OK` con il corpo JSON descritto sopra, così che ogni eliminazione riporti il proprio `face_retention_outcome`. Aggiorna i client che verificano la presenza di `204`.Il comportamento predefinito non cambia: le applicazioni esistenti restano su `delete_with_session`, e nessuna migrazione attiva la conservazione per tuo conto. Attivala esplicitamente nella Console oppure tramite `PATCH /v3/webhook/`.## Documentazione correlata- [Modelli biometrici](https://docs.didit.me/it/management-api/biometric-templates/overview.md)
- [Conservazione dei dati](https://docs.didit.me/it/console/data-retention.md)
- [Panoramica delle sessioni](https://docs.didit.me/it/sessions-api/overview.md)
## OpenAPI
````yaml it/openapi-25.json DELETE /v3/session/{sessionId}/delete/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API di verifica dell'identità. Autenticati con l'intestazione x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/session/{sessionId}/delete/:
delete:
tags:
- Sessions
summary: Elimina una sessione di verifica (KYC o KYB)
description: >-
Elimina una singola sessione di verifica, Verifica degli utenti (KYC) o
Verifica aziendale (KYB), tramite il suo `session_id`. L'id viene
risolto prima rispetto alle sessioni KYC, poi a quelle KYB, quindi
entrambi i tipi vengono eliminati tramite questo unico URL.
**Cosa viene eliminato:**
- La sessione e ogni tentativo di verifica che contiene, inclusi i
risultati sostituiti da un nuovo invio: la decisione, i dati estratti,
tutti i record delle funzionalità correlate (verifica dell'identità,
volto, rilevamento della vitalità, confronto facciale, AML, controlli
sui registri, analisi IP e così via), le relative revisioni e il suo
registro delle attività.
- Tutti i file archiviati appartenenti alla sessione: foto fronte/retro
dei documenti (varianti intere, ritagliate e con oscuramento per la
privacy), video di acquisizione dei documenti, ritagli del ritratto,
immagini del ritratto e della firma dal chip NFC, immagini di
riferimento del volto, video di rilevamento della vitalità, immagini
sorgente/destinazione per il confronto facciale, documenti di Prova di
residenza e qualsiasi file aggiuntivo caricato (KYC); documenti
aziendali e file aggiuntivi caricati (KYB). Documenti di Firma
elettronica, PDF firmati, PDF probatori e immagini delle firme (KYC e
KYB): i relativi percorsi di download smettono di funzionare. Gli URL
dei contenuti multimediali emessi in precedenza
(`https:///...`) smettono di risolversi.
- I dati del volto della sessione. Anche il relativo embedding facciale
viene eliminato, a meno che tu non scelga di conservare un modello privo
di immagini (vedi **Dati biometrici del volto**).
- Le consegne dei webhook ancora in coda per la sessione e i relativi
tentativi. I webhook già consegnati non sono interessati.
- Per una sessione di Verifica aziendale (KYB): le verifiche create per
le sue persone chiave (KYC) e i suoi proprietari aziendali (KYB), in
modo ricorsivo, indicate come `deleted_child_verifications`. Una
verifica a cui è solo collegata, come un KYC approvato esistente che ha
riutilizzato, non viene eliminata.
La sessione scompare immediatamente da ogni endpoint di lettura: `GET
/v3/session/{sessionId}/decision/` restituisce `404` e `GET
/v3/sessions/` smette di includerla nell'elenco. Il monitoraggio AML
continuo e il monitoraggio del registro KYB avviati dalle verifiche
eliminate si interrompono.
**Cosa non viene modificato:** le voci della blocklist create a partire
da questa sessione (volto o documento) **non** vengono rimosse;
gestiscile tramite gli endpoint della blocklist. I token di condivisione
emessi per la sessione non vengono revocati, ma non c'è più nulla che
possano importare: un'importazione con uno di essi restituisce `400` con
`{"share_token": ["Original session does not exist."]}`. I crediti già
consumati **non** vengono rimborsati. L'entità genitore User o Business
**non** viene eliminata; usa `POST /v3/users/delete/` o `POST
/v3/businesses/delete/` per queste entità. Se il ritratto del profilo
dell'User proveniva da questa sessione, il ritratto viene rimosso
insieme ad essa.
**Dati biometrici del volto:** per impostazione predefinita, l'embedding
facciale della sessione viene eliminato con la sessione
(`face_retention_outcome: deleted`). Un'applicazione che ha scelto la
conservazione del modello biometrico (`face_retention_policy:
retain_until_user_deleted` su `PATCH /v3/webhook/`), o una richiesta con
`retain_face_embeddings: true`, conserva un unico modello biometrico
facciale gestito separatamente e privo di immagini ancorato all'User
della sessione (`retained_with_user`), in modo che il rilevamento dei
duplicati, Ricerca facciale e l'autenticazione biometrica continuino a
funzionare. Il modello non contiene mai l'immagine del volto, contenuti
multimediali, campi di identità, la decisione o l'id della sessione
eliminata; si tratta di dati biometrici eliminati a
`biometric_template_expires_at`, oppure prima in caso di eliminazione
dell'User, cancellazione per motivi di privacy o eliminazione esplicita
tramite `/v3/biometric-templates/`. Una sessione senza un User collegato
non può conservare un modello (`ineligible_no_vendor_user`). Invia
`deletion_instruction: privacy_erasure` per le richieste degli
interessati: elimina definitivamente ogni modello conservato per
quell'User e non ne conserva mai uno nuovo.
**Irreversibile:** l'eliminazione è permanente e non esiste alcun
endpoint di ripristino. Esporta tutto ciò di cui hai bisogno (ad esempio
un PDF della decisione) prima di chiamarlo.
**Effetti collaterali:** non viene emesso alcun webhook per le
eliminazioni.
**Risposta:** `200 OK` una volta completata l'eliminazione, con un corpo
JSON che riporta `face_retention_outcome`, la scadenza del modello
conservato e, per una sessione KYB, `deleted_child_verifications`. Le
versioni precedenti di questo endpoint restituivano `204 No Content`;
aggiorna i client che verificano `204`. Conserva il tuo `instruction_id`
nel tuo registro di cancellazione.
**Idempotenza:** non idempotente a livello HTTP: la prima chiamata
restituisce `200`; se ripetuta restituisce `404` perché la sessione non
viene più risolta. Dopo un `503` la sessione è ancora presente; ripeti
la stessa richiesta per completarne l'eliminazione.
**Autenticazione:** invia la chiave API della tua applicazione
nell'intestazione `x-api-key`; la sessione deve appartenere a tale
applicazione. Anche i token di accesso utente della console
(`Authorization: Bearer ...`) possono chiamare questo endpoint quando
dispongono dell'autorizzazione `delete:sessions`. Gli errori di
autenticazione e di autorizzazione restituiscono entrambi `403`; questa
API non restituisce mai `401`.
**Limite di frequenza:** budget di scrittura condiviso di 300
richieste/min per chiave API su tutti gli endpoint POST/PATCH/DELETE; il
superamento restituisce `429`.
Per eliminare in blocco le sessioni KYC in base al loro `session_number`
numerico, usa invece `POST /v3/sessions/delete/`.
**Report normativi depositati:** se i dati selezionati si trovano in un
report normativo finalizzato, l'intera richiesta viene rifiutata con
`409` e nulla viene eliminato. Il corpo utilizza `code: in_filed_report`
e indica ciascun report con `uuid`, `report_number`, `report_type` e
`case_uuid`. Elimina i report, quindi ripeti la richiesta.
operationId: delete_v3_session_by_id
parameters:
- in: path
name: sessionId
required: true
description: >-
UUID (`session_id`) della sessione di Verifica degli utenti (KYC) o
Verifica aziendale (KYB) da eliminare, come restituito al momento
della creazione della sessione. Deve essere un UUID canonico
separato da trattini: un valore che non è un UUID non corrisponde al
percorso e restituisce `404`.
schema:
type: string
format: uuid
example: 11111111-2222-3333-4444-555555555555
requestBody:
required: false
description: >-
Opzionale. Ometti interamente il corpo per seguire la politica di
conservazione dell'applicazione con un'eliminazione operativa.
content:
application/json:
schema:
type: object
properties:
retain_face_embeddings:
type: boolean
nullable: true
description: >-
Esegui l'override della `face_retention_policy`
dell'applicazione per questa eliminazione. `true` mantiene
un modello biometrico facciale privo di immagini associato
all'Utente della sessione dopo l'eliminazione della
sessione; `false` elimina l'embedding facciale insieme alla
sessione; ometti o imposta su `null` per seguire la politica
dell'applicazione. Ignorato per le sessioni KYB e per le
sessioni senza un embedding facciale.
example: true
face_retention_days:
type: integer
minimum: 1
maximum: 3650
description: >-
Periodo di conservazione limitato, in giorni, per un modello
conservato. Obbligatorio quando un modello viene conservato,
a meno che l'applicazione non imposti già
`face_retention_days`. Il campo `expires_at` del modello
corrisponde al valore più anticipato tra questa durata, la
finestra generale di conservazione dei dati
dell'applicazione e `face_retention_deadline`.
example: 365
face_retention_deadline:
type: string
format: date-time
description: >-
Scadenza definitiva opzionale per un modello conservato.
Deve essere nel futuro.
example: '2027-08-28T00:00:00Z'
deletion_instruction:
type: string
enum:
- operational_session_delete
- privacy_erasure
default: operational_session_delete
description: >-
La classe di istruzione che stai fornendo.
`operational_session_delete` elimina la sessione e conserva
un modello solo quando la policy o `retain_face_embeddings`
lo prevede. `privacy_erasure` elimina definitivamente ogni
modello biometrico conservato e associato all'Utente della
sessione prima di eliminarla, non può essere sovrascritta
dalla policy dell'applicazione e non può essere combinata
con `retain_face_embeddings: true` (`400`).
example: operational_session_delete
instruction_id:
type: string
maxLength: 255
description: >-
Il tuo riferimento permanente per questa istruzione di
eliminazione (ad esempio l'ID di un ticket di
cancellazione). Registrato nel registro di audit e su
qualsiasi modello conservato. Generato da Didit se omesso.
example: dsar-2026-0142
examples:
Retain a biometric template:
summary: >-
Elimina la sessione, conserva un modello privo di immagini per
365 giorni
value:
retain_face_embeddings: true
face_retention_days: 365
instruction_id: post-approval-cleanup-2026-08
Force deletion on an opted-in application:
summary: >-
Elimina l'embedding facciale indipendentemente dalla policy
dell'applicazione
value:
retain_face_embeddings: false
Privacy erasure:
summary: >-
Richiesta dell'interessato: elimina la sessione ed elimina
definitivamente ogni modello conservato per quella persona
value:
deletion_instruction: privacy_erasure
instruction_id: dsar-2026-0142
responses:
'200':
description: >-
Sessione eliminata. Il corpo riporta cosa è successo ai dati
biometrici facciali della sessione e, per una sessione KYB, quante
verifiche create da essa sono state eliminate insieme ad essa.
content:
application/json:
schema:
type: object
properties:
session_id:
type: string
format: uuid
description: La sessione eliminata.
session_number:
type: integer
nullable: true
description: Il numero della sessione eliminata.
face_retention_outcome:
type: string
enum:
- retained_with_user
- deleted
- none
- ineligible_no_vendor_user
description: >-
Cosa è successo ai dati biometrici facciali della
sessione. `deleted`: l'embedding facciale è stato
eliminato insieme alla sessione (impostazione
predefinita). `retained_with_user`: la sessione viene
eliminata e un modello biometrico senza immagini rimane
associato all'Utente; vedi `biometric_template_uuid`.
`none`: la sessione non aveva alcun embedding facciale (ad
esempio una sessione KYB o una sessione KYC senza selfie
per la prova di vita). `ineligible_no_vendor_user`: la
conservazione era stata richiesta ma la sessione non ha
alcun Utente collegato, quindi l'embedding è stato
eliminato con la sessione. Un errore dello store
biometrico non viene mai segnalato tramite questo campo su
questo endpoint: restituisce `503` e la sessione non viene
eliminata.
biometric_template_uuid:
type: string
format: uuid
nullable: true
description: >-
ID del modello biometrico conservato quando
`face_retention_outcome` è `retained_with_user`; `null`
altrimenti. Gestiscilo tramite
`/v3/biometric-templates/{template_uuid}/`.
biometric_template_expires_at:
type: string
format: date-time
nullable: true
description: >-
Quando il modello biometrico conservato viene eliminato,
se `face_retention_outcome` è `retained_with_user`; `null`
quando nessun modello viene conservato.
deleted_child_verifications:
type: integer
description: >-
Per una sessione di Verifica aziendale (KYB): quante
verifiche ha creato (le sessioni KYC delle sue persone
chiave e le sessioni KYB dei suoi proprietari aziendali,
ricorsivamente) che sono state eliminate insieme ad essa.
Sempre `0` per una sessione KYC.
examples:
Deleted (default):
value:
session_id: 4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02
session_number: 1024
face_retention_outcome: deleted
biometric_template_uuid: null
biometric_template_expires_at: null
deleted_child_verifications: 0
Retained with User:
value:
session_id: 4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02
session_number: 1024
face_retention_outcome: retained_with_user
biometric_template_uuid: 9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b
biometric_template_expires_at: '2027-10-09T10:15:00Z'
deleted_child_verifications: 0
'Ineligible: no User':
summary: >-
Conservazione richiesta per una sessione creata senza
vendor_data
value:
session_id: 7a1e9c2d-5f4b-4c3a-8e2d-1b0a9f8e7d6c
session_number: 1031
face_retention_outcome: ineligible_no_vendor_user
biometric_template_uuid: null
biometric_template_expires_at: null
deleted_child_verifications: 0
KYB session:
value:
session_id: 0f3c9b7e-2d1a-4e5f-8c6b-7a9d8e1f2c3b
session_number: 88
face_retention_outcome: none
biometric_template_uuid: null
biometric_template_expires_at: null
deleted_child_verifications: 3
summary: >-
Una verifica aziendale eliminata insieme alle tre verifiche
create per le relative persone chiave
'400':
description: Errore di validazione — nulla viene eliminato.
content:
application/json:
examples:
Privacy erasure cannot retain:
value:
retain_face_embeddings:
- Privacy erasure cannot retain biometric templates.
No finite retention duration:
summary: >-
Conservazione richiesta senza face_retention_days nella
richiesta o nell'applicazione
value:
detail: >-
A finite biometric-template retention duration is
required.
'403':
description: >-
Errore di autenticazione o di autorizzazione. Anche una chiave
mancante restituisce `403`; una chiave errata, revocata o scaduta
restituisce `401`. Eccezione: quando il `sessionId` non corrisponde
a una sessione attiva, la ricerca del proprietario prima
dell'autenticazione restituisce prima `404`, anche con credenziali
mancanti o non valide.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Missing or invalid API key:
summary: >-
Nessuna intestazione x-api-key, oppure la chiave non è
valida
value:
detail: >-
Authentication credentials were not provided or are
invalid.
Insufficient permission:
summary: >-
Token utente senza delete:sessions, o credenziali per
un'applicazione che non possiede la sessione
value:
detail: You do not have permission to perform this action.
'404':
description: >-
Non esiste alcuna sessione KYC o KYB attiva con questo `session_id`
— l'id è sconosciuto o la sessione è già stata eliminata (la
ripetizione di un'eliminazione riuscita porta a questo risultato).
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Not Found:
summary: Sessione sconosciuta o già eliminata
value:
detail: Not found.
'409':
description: >-
La sessione fa parte di un report normativo finalizzato. Non viene
eliminato nulla.
content:
application/json:
schema:
$ref: '#/components/schemas/InFiledReportError'
'429':
description: >-
Limite di frequenza di scrittura condiviso superato (300 richieste
POST/PATCH/DELETE al minuto per chiave API). Esamina `Retry-After` e
le intestazioni di risposta `X-RateLimit-*` prima di effettuare un
nuovo tentativo.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Rate limited:
summary: Budget di scrittura esaurito
value:
detail: >-
Write request rate limit exceeded. You can make up to 300
requests per minute.
'503':
description: >-
Impossibile completare l'eliminazione perché un servizio di
archiviazione, uno store biometrico o un provider di monitoraggio
non era disponibile. La sessione è ancora presente; ripeti la stessa
richiesta finché non restituisce `200`. Alcuni dei suoi file
archiviati o il suo embedding facciale potrebbero essere già stati
eliminati, quindi non farvi affidamento dopo un `503`. I nuovi
tentativi convergono su un singolo modello.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Session deletion unavailable:
summary: >-
Un servizio di archiviazione o un provider di monitoraggio
non era disponibile
value:
detail: >-
The session could not be deleted because a storage service
or a monitoring provider is unavailable. The session is
still in place; repeat the request to finish deleting it.
Biometric store unavailable:
summary: >-
Un archivio biometrico non era disponibile durante la
conservazione o l'eliminazione definitiva di un modello
value:
detail: >-
The biometric-template operation could not finish because
an external store is unavailable. The operation is
retryable.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: curl (default policy)
source: |-
curl -X DELETE \
https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \
-H 'x-api-key: YOUR_API_KEY'
- lang: curl
label: curl (retain template)
source: |-
curl -X DELETE \
https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"retain_face_embeddings": true, "face_retention_days": 365}'
- lang: curl
label: curl (privacy erasure)
source: |-
curl -X DELETE \
https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}'
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.sessions.delete(
"11111111-2222-3333-4444-555555555555",
retain_face_embeddings=True,
face_retention_days=365,
instruction_id="post-approval-cleanup-2026-08",
)
print(result)
- lang: javascript
label: Node.js
source: >-
import Didit from "@didit-protocol/sdk-node";
// Reads DIDIT_API_KEY.
const didit = new Didit();
const result = await
didit.sessions.delete("11111111-2222-3333-4444-555555555555", {
retain_face_embeddings: true,
face_retention_days: 365,
instruction_id: "post-approval-cleanup-2026-08",
});
console.log(result);
- lang: go
label: Go
source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.Delete(ctx, \"11111111-2222-3333-4444-555555555555\", didit.SessionsDeleteParams{\n\tRetainFaceEmbeddings: didit.Bool(true),\n\tFaceRetentionDays: didit.Int(365),\n\tInstructionID: didit.String(\"post-approval-cleanup-2026-08\"),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)"
- lang: java
label: Java
source: >-
import me.didit.Didit;
import me.didit.types.SessionsDeleteParams;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result =
client.sessions().delete("11111111-2222-3333-4444-555555555555",
SessionsDeleteParams.builder()
.retainFaceEmbeddings(true)
.faceRetentionDays(365L)
.instructionId("post-approval-cleanup-2026-08")
.build());
System.out.println(result);
- lang: php
label: PHP
source: >-
sessions->delete('11111111-2222-3333-4444-555555555555', [
'retain_face_embeddings' => true,
'face_retention_days' => 365,
'instruction_id' => 'post-approval-cleanup-2026-08',
]);
print_r($result->toArray());
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.sessions.delete(
"11111111-2222-3333-4444-555555555555",
retain_face_embeddings: true,
face_retention_days: 365,
instruction_id: "post-approval-cleanup-2026-08"
)
puts result.to_h
- lang: csharp
label: .NET
source: >-
using System;
using System.Text.Json;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var result = await
client.Sessions.DeleteAsync("11111111-2222-3333-4444-555555555555",
new SessionsDeleteParams
{
RetainFaceEmbeddings = true,
FaceRetentionDays = 365,
InstructionId = "post-approval-cleanup-2026-08",
});
Console.WriteLine(JsonSerializer.Serialize(result));
components:
schemas:
InFiledReportError:
type: object
description: >-
L'eliminazione è stata rifiutata perché i dati selezionati si trovano in
un report normativo finalizzato. Non viene eliminato nulla. Elimina il
report, quindi ripeti la richiesta.
required:
- detail
- code
properties:
detail:
type: string
code:
type: string
enum:
- in_filed_report
description: >-
Codice di errore stabile per un'eliminazione bloccata da un report
normativo finalizzato.
reports:
type: array
items:
$ref: '#/components/schemas/FiledRegulatoryReport'
description: >-
Report che bloccano l'eliminazione di una persona, azienda, caso o
sessione.
transactions:
type: array
items:
$ref: '#/components/schemas/FiledReportTransaction'
description: >-
Transazioni che bloccano l'eliminazione di una transazione, ciascuna
con i report che la elencano.
FiledRegulatoryReport:
type: object
description: Un report normativo finalizzato che impedisce l'eliminazione richiesta.
required:
- uuid
- report_number
- report_type
- case_uuid
properties:
uuid:
type: string
format: uuid
description: UUID del report.
report_number:
type: string
description: Numero del report mostrato nella Console (ad esempio, SAR-0001).
report_type:
type: string
enum:
- SAR
- STR
- CTR
- TTR
- UTR
- IFT
- CBR
- TFR
description: Tipo di report normativo.
case_uuid:
type: string
format: uuid
description: Caso a cui appartiene il report.
FiledReportTransaction:
type: object
description: >-
Una transazione che non può essere eliminata perché inclusa in un report
normativo finalizzato.
required:
- uuid
- transaction_id
- reports
properties:
uuid:
type: string
format: uuid
description: UUID della transazione Didit.
transaction_id:
type: string
description: >-
L'identificatore della transazione fornito al momento della
creazione della transazione.
reports:
type: array
items:
$ref: '#/components/schemas/FiledRegulatoryReport'
description: Report finalizzati che includono questa transazione.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
La chiave API della tua applicazione, da Developers -> API keys nella
Business Console. La chiave primaria ha accesso completo. Una chiave con
nome può avere un ambito definito: nessuno, lettura o scrittura per
risorsa, limitata ad alcuni workflow o a sessioni approvate, a un elenco
di indirizzi IP e a una data di scadenza. 401 indica che la chiave è
errata, revocata o scaduta; 403 indica che non è stata inviata alcuna
chiave, che la chiave non ha accesso a questa risorsa o azione, oppure
che la richiesta proviene da un indirizzo non incluso nel suo elenco IP;
404 su una route di sessione indica che la sessione non rientra nei
workflow o negli stati previsti dalla chiave. Una chiave senza accesso
ai media riceve gli URL di immagini, video e PDF come null, e una chiave
senza permessi di scrittura sulle sessioni riceve link e token di
sessione come null. Consulta https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.