> ## 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. # API eliminazione utenti in batch: cancellazione GDPR > Elimina in blocco gli utenti Didit per vendor_data oppure tutti gli utenti di un'applicazione. Conforme al diritto all'oblio GDPR e CCPA. Batch Delete Users Prompt Copia il prompt negli appunti \

\`Goal: Permanently delete one or many Didit User entities. The matching user records, their tag links, their comment history, and every retained biometric template anchored to them are removed permanently. Verification sessions are NOT removed by this endpoint; delete those separately with POST /v3/sessions/delete/.

Endpoint: POST https://verification.didit.me/v3/users/delete/
Auth header: x-api-key: 
Content-Type: application/json

Request body — provide at least one selector:
\- vendor_data_list: string[] — your own identifiers (case-insensitive after normalisation).
\- didit_internal_id_list: string[] — Didit internal user IDs, the didit_internal_id returned by the create and get endpoints. Can be combined with vendor_data_list; the two are OR'd.
\- delete_all: true — wipe every user in this application. No confirmation, no undo. Takes precedence: when delete_all is true, the two lists are ignored.

\- retain_face_embeddings: boolean, default false — your explicit choice to keep one image-free biometric template of each deleted person for duplicate detection. Everything else about the person is deleted. Requires face_retention_days.
\- face_retention_days: integer 1 to 3650 — how many days that template is kept. Sent without retain_face_embeddings: true it returns 400 on face_retention_days.

This endpoint never narrows delete_all with filters. The Console's filter_* batch params (filter_search, filter_status, filter_country, filter_date_from, filter_date_to, filter_tag, filter_latest_verification_status, filter_risk, filter_has_sessions, filter_has_open_alerts, filter_aml_monitoring, filter_can_sign_in, filter_auth_status, filter_auth_method, filter_auth_mfa_enabled) are NOT supported here. Any of them sent with a value, even false, is rejected with a 400 keyed by that field, and any other unknown filter_* key with "Unknown filter.", so a narrowed intent does not wipe the whole application. Exception: filter_has_approved_sessions and filter_has_declined_sessions are neither rejected nor applied, so with delete_all they still delete every user. Do not send them.

curl:
curl -X POST 'https://verification.didit.me/v3/users/delete/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"vendor_data_list": ["user-123", "user-456"]}'

Response 200:
\{
"deleted": 
}

Biometric templates: unless you set retain_face_embeddings to true, if the application retained image-free biometric templates for these users after session deletion (see /management-api/biometric-templates/overview), Didit purges every one of them before the user is deleted, so the person stops matching in duplicate detection and Face Search. The purge is audited with instruction_source: vendor_user_delete.

Idempotency: re-sending the same list returns deleted: 0 after the first run (unmatched IDs are silently skipped). There is no undo.

Failure modes:
\- 400 — no selector supplied, or a Console-only filter_* param was sent.
No selector: {"vendor_data_list": ["This field is required unless delete_all is true."]}. An unknown filter_* key: {"filter_": ["Unknown filter."]}.
\- 401 — missing/invalid x-api-key.
\- 403 — the API key is revoked or is not valid for this application.
\- 409 — the selection includes a person in a finalized regulatory report. Nothing is deleted. The body has code: in_filed_report and reports[] with uuid, report_number, report_type and case_uuid. Delete the reports, then repeat the request.
\- 409 — code: subject_deletion_in_progress: another request is still deleting one of the selected people. This request deleted nothing; repeat it once that deletion has finished.
\- 429 — rate-limited.
\- 503 — {"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."} A retained biometric template could not be purged. No user in the request is deleted; the affected template is already excluded from matching. Repeat the same request.

WARNING — delete_all: true: there is no confirmation step and no undo. Restrict to API keys you intentionally provision for batch maintenance.

When to prefer status change instead:
\- For day-to-day blocking, use PATCH /v3/users/{vendor_data}/update-status/ with {"status": "BLOCKED"} — it keeps the audit trail intact while rejecting future sessions for the same identifier.

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\
Incolla in ## PanoramicaElimina una o più [entità Utente](https://docs.didit.me/it/entities/users/overview.md). I record degli utenti vengono rimossi in modo permanente. Le loro sessioni di verifica non sono coperte da questo endpoint e restano, con il collegamento all'utente rimosso; eliminale con [Delete Session](https://docs.didit.me/it/sessions-api/delete-session.md) o [Batch Delete Sessions](https://docs.didit.me/it/management-api/sessions/batch-delete.md). Anche le transazioni non sono coperte: eliminale con [Batch Delete Transactions](https://docs.didit.me/it/management-api/transactions/delete.md).## Quando usarlo- Richieste di **diritto all'oblio** (GDPR / CCPA). - **Pulizia** degli utenti di test durante il QA. - **Disattivazione** degli utenti rimossi dalla tua piattaforma.## Note- Accetta un elenco di valori `vendor_data`, un elenco di valori `didit_internal_id`, oppure `delete_all: true`. I due elenchi possono essere combinati e vengono combinati con OR. - Questo endpoint non restringe mai `delete_all` con filtri, e i parametri batch `filter_*` della Console vengono rifiutati con un `400`, quindi una richiesta con filtri non elimina tutti gli utenti dell'applicazione. Le eccezioni sono `filter_has_approved_sessions` e `filter_has_declined_sessions`: non vengono né rifiutate né applicate, quindi non inviarle insieme a `delete_all`. - Tutto o niente: se l'eliminazione non può essere completata per gli utenti selezionati, nessuno di essi viene eliminato e puoi ripetere la stessa richiesta senza rischi. - Idempotente: reinviare lo stesso elenco restituisce `deleted: 0` dopo la prima esecuzione. - Restituisce solo il conteggio di quanto eliminato, non un report per singolo elemento. I valori che non corrispondono a nulla vengono ignorati senza segnalazione. Invia un elenco senza duplicati se vuoi confrontare `deleted` con il numero di identificatori inviati, perché un identificatore ripetuto viene conteggiato una sola volta. - Per un'eliminazione non viene emesso alcun webhook. I webhook si attivano per le modifiche di stato e dei dati dell'utente, non per l'eliminazione, quindi un'integrazione che necessita di un segnale di eliminazione deve registrarlo autonomamente. - Le sessioni di verifica collegate all'utente NON vengono eliminate da questo endpoint. Restano, con il collegamento all'utente rimosso, quindi i loro documenti, volti e contenuti multimediali vengono rimossi solo quando elimini le sessioni stesse. - `retain_face_embeddings` (booleano, predefinito `false`) e `face_retention_days` (da 1 a 3650) sono la tua scelta esplicita di conservare, per il numero di giorni indicato, un unico modello biometrico senza immagini per ogni persona eliminata, per il rilevamento dei duplicati. Non viene conservato nient'altro sulla persona. Ometti entrambi per eliminare i modelli insieme agli utenti. `face_retention_days` senza `retain_face_embeddings: true`, oppure `retain_face_embeddings: true` senza `face_retention_days`, restituisce `400` per `face_retention_days`. - A meno che tu non imposti `retain_face_embeddings` su `true`, i [modelli biometrici](https://docs.didit.me/it/management-api/biometric-templates/overview.md) conservati associati all'utente VENGONO eliminati, prima che l'utente venga cancellato. Se un modello non può essere eliminato perché un archivio biometrico non è disponibile, la chiamata restituisce `503`, nessun utente della richiesta viene eliminato e ripetere la richiesta completa l'operazione.## Dati in un report normativo finalizzatoSe una delle persone selezionate fa parte di un caso con un report normativo finalizzato, l'intera richiesta restituisce `409` e non viene eliminato nulla. La risposta usa `code: in_filed_report` e indica ogni report per nome, così puoi aprirlo nella Console:```json theme={null} { "detail": "A case about this person or company has a filed 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 ogni report con [Delete Report](https://docs.didit.me/it/management-api/regulatory-reports/delete.md), quindi ripeti la stessa richiesta. Rimuovere quella persona dall'elenco non basta se un'altra persona selezionata è ancora in un report.## Un'eliminazione già in corsoUna persona viene eliminata da una sola richiesta alla volta. Se un'altra richiesta sta ancora eliminando una delle persone selezionate, questa richiesta attende al massimo alcuni secondi, poi restituisce `409` con `code: subject_deletion_in_progress` e non elimina nulla:```json theme={null} { "detail": "This person or company is being deleted. Retry after deletion completes.", "code": "subject_deletion_in_progress" } ```Ripeti la stessa richiesta una volta terminata l'altra eliminazione. Una persona già eliminata dall'altra richiesta non corrisponde più, quindi la ripetizione elimina solo ciò che resta.## AutorizzazioniQualsiasi chiave API attiva dell'applicazione può chiamare questo endpoint. Le chiavi API di Didit sono **limitate all'applicazione, non ai ruoli**: i [ruoli e le autorizzazioni](https://docs.didit.me/it/console/roles-permissions.md) della Console (`delete:users` e le altre) determinano cosa una *persona* può fare nella Console, e non vengono valutati per il traffico della Management API. Controlla chi può chiamare questo endpoint controllando chi può leggere la chiave API dell'applicazione.## Correlati- [Conservazione dei dati](https://docs.didit.me/it/console/data-retention.md) - [Registri di audit](https://docs.didit.me/it/console/audit-logs.md) - [Operazioni sugli utenti](https://docs.didit.me/it/entities/users/operations.md) - [Modelli biometrici](https://docs.didit.me/it/management-api/biometric-templates/overview.md) ## OpenAPI ````yaml it/openapi-25.json POST /v3/users/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/users/delete/: post: tags: - Users summary: Elimina utenti in blocco description: >- **Elimina definitivamente** gli utenti: i record utente vengono rimossi in modo permanente. Per il blocco ordinario preferisci [Aggiorna stato utente](#patch-/v3/users/-vendor_data-/update-status/) con `BLOCKED`. Seleziona gli utenti con `vendor_data_list`, con `didit_internal_id_list` o con entrambi contemporaneamente; oppure passa `delete_all: true`. Questo endpoint non restringe mai `delete_all` con i filtri. I filtri Persone della Console vengono rifiutati con un `400` (vedi la risposta `400`), in modo che un intento più restrittivo non si trasformi in una cancellazione totale. Due eccezioni: `filter_has_approved_sessions` e `filter_has_declined_sessions` non vengono rifiutati e non vengono applicati, quindi con `delete_all: true` eliminano comunque ogni utente; non inviarli. **Modelli biometrici:** a meno che tu non imposti `retain_face_embeddings` su `true`, ogni modello biometrico privo di immagini conservato per questi utenti dopo l'eliminazione della sessione (vedi `/v3/biometric-templates/`) viene rimosso prima che l'utente venga eliminato, così la persona non viene più riconosciuta come corrispondenza nel rilevamento dei duplicati e nella Ricerca facciale. Con `retain_face_embeddings: true` e `face_retention_days`, scegli di conservare un modello biometrico privo di immagini per persona per quel numero di giorni, e non viene conservato nient'altro sulla persona. Se non è possibile eliminare un modello perché un archivio biometrico non è disponibile, la chiamata restituisce `503`, nessun utente nella richiesta viene eliminato e la ripetizione della richiesta completa l'operazione. **Report normativi presentati:** se i dati selezionati sono presenti in un report normativo finalizzato, l'intera richiesta viene rifiutata con `409` e non viene eliminato nulla. Il corpo usa `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: batch_delete_users requestBody: required: true content: application/json: schema: type: object description: >- Fornisci `vendor_data_list`, `didit_internal_id_list` o `delete_all: true`. Le due liste possono essere combinate e vengono valutate in OR. Quando `delete_all` è `true`, ha la precedenza ed entrambe le liste vengono ignorate. properties: vendor_data_list: type: array items: type: string description: >- I tuoi identificatori da eliminare, confrontati esattamente come inviati. didit_internal_id_list: type: array items: type: string format: uuid description: >- ID utente interni Didit da eliminare: il `didit_internal_id` restituito dagli endpoint di creazione e recupero. delete_all: type: boolean default: false description: Se `true`, elimina ogni utente nell'applicazione. retain_face_embeddings: type: boolean default: false description: >- La tua scelta esplicita di conservare un modello biometrico privo di immagini di ciascuna persona eliminata per il rilevamento di duplicati, per `face_retention_days`. Tutti gli altri dati della persona vengono eliminati. Omettilo o invia `false` per eliminare i modelli insieme agli utenti. Quando è `true`, `face_retention_days` è obbligatorio. face_retention_days: type: integer minimum: 1 maximum: 3650 description: >- Numero di giorni per cui viene conservato il modello biometrico senza immagini quando `retain_face_embeddings` è `true`. Obbligatorio con esso, e rifiutato senza di esso con un errore `400` su `face_retention_days`. example: 365 examples: Specific users: summary: Elimina utenti tramite vendor_data value: vendor_data_list: - user-123 - user-456 By Didit internal ID: summary: Elimina utenti tramite didit_internal_id value: didit_internal_id_list: - 3f1c0d3e-8f0a-4c2e-9a3d-9b1f5f4a2c11 All users: summary: Elimina tutti gli utenti in questa applicazione value: delete_all: true Keep face templates: summary: >- Elimina gli utenti e conserva i modelli facciali anonimi per 365 giorni value: vendor_data_list: - user-123 retain_face_embeddings: true face_retention_days: 365 responses: '200': description: >- Utenti eliminati. Restituisce il numero di utenti effettivamente eliminati. content: application/json: schema: type: object properties: deleted: type: integer description: >- Numero di utenti eliminati (esclude i valori vendor_data che non corrispondevano a nulla). examples: Deleted some: value: deleted: 2 Nothing matched: value: deleted: 0 '400': description: >- Errore di validazione; non viene eliminato nulla. Gli errori sono indicizzati per nome di campo. In assenza di un selettore (nessuna delle due liste e `delete_all` non `true`), il corpo è `{"vendor_data_list": ["This field is required unless delete_all is true."]}`; una lista vuota viene rifiutata sotto la propria chiave con `"This list may not be empty."`. Un filtro riservato alla Console (`filter_search`, `filter_status`, `filter_country`, `filter_date_from`, `filter_date_to`, `filter_tag`, `filter_latest_verification_status`, `filter_risk`, `filter_has_sessions`, `filter_has_open_alerts`, `filter_aml_monitoring`, `filter_can_sign_in`, `filter_auth_status`, `filter_auth_method` o `filter_auth_mfa_enabled`) viene rifiutato ogni volta che contiene un valore, anche `false`, con un oggetto indicizzato per ciascuno di tali campi. Qualsiasi altra chiave `filter_*` sconosciuta viene rifiutata con `"Unknown filter."`. content: application/json: examples: Missing selector: summary: Né list né delete_all forniti value: vendor_data_list: - This field is required unless delete_all is true. Console-only filter: value: filter_has_sessions: >- This filter is Console-only and is not supported by this endpoint. '401': description: >- Nessuna credenziale fornita. Le richieste ai percorsi `/v3/users/*` senza un'intestazione `x-api-key` (o token `Authorization: Bearer`) vengono rifiutate dal middleware di autenticazione prima di raggiungere l'API. content: application/json: examples: Missing credentials: value: detail: >- You must be authenticated with a valid access token to access this endpoint. '403': description: >- Chiave API non valida o revocata, oppure la chiave non può eliminare utenti per questa applicazione. Una chiave mancante restituisce `403`; una chiave errata, revocata o scaduta restituisce `401`. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- Non viene eliminato nulla. `code` ne indica il motivo: `in_filed_report` quando la selezione include una persona presente in un report normativo finalizzato, `subject_deletion_in_progress` quando un'altra richiesta sta ancora eliminando una delle persone selezionate. Ripeti la richiesta una volta completata tale eliminazione. content: application/json: schema: oneOf: - $ref: '#/components/schemas/InFiledReportError' - $ref: '#/components/schemas/SubjectDeletionInProgressError' '429': description: >- Limite di frequenza superato; rallenta e riprova dopo l'intervallo indicato in `Retry-After`. content: application/json: examples: Rate limited: value: detail: Request was throttled. Expected available in 30 seconds. '503': description: >- Un archivio biometrico non era disponibile durante la conservazione o l'eliminazione definitiva di un modello biometrico. Non è stato eliminato nulla; ripeti la stessa richiesta. I nuovi tentativi sono idempotenti e convergono su un unico modello. content: application/json: schema: type: object properties: detail: type: string examples: Retryable: 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 source: |- curl -X POST 'https://verification.didit.me/v3/users/delete/' \ -H 'x-api-key: YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"vendor_data_list": ["user-123", "user-456"]}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.users.batch_delete( vendor_data_list=["user-123", "user-456"], ) 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.users.batchDelete({ vendor_data_list: ["user-123", "user-456"], }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Users.BatchDelete(ctx, didit.UsersBatchDeleteParams{\n\tVendorDataList: didit.Some([]string{\"user-123\", \"user-456\"}),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import java.util.List; import me.didit.Didit; import me.didit.types.UsersBatchDeleteParams; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.users().batchDelete(UsersBatchDeleteParams.builder() .vendorDataList(List.of("user-123", "user-456")) .build()); System.out.println(result); - lang: php label: PHP source: |- users->batchDelete([ 'vendor_data_list' => ['user-123', 'user-456'], ]); print_r($result->toArray()); - lang: ruby label: Ruby source: >- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.users.batch_delete(vendor_data_list: ["user-123", "user-456"]) 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.Users.BatchDeleteAsync(new UsersBatchDeleteParams { VendorDataList = new string[] { "user-123", "user-456" }, }); 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. SubjectDeletionInProgressError: type: object description: >- Un'altra richiesta sta ancora eliminando questa persona o azienda. Questa richiesta non ha eliminato nulla e può essere ripetuta una volta terminata tale eliminazione; un nuovo tentativo eliminerà quindi ciò che è ancora selezionato. required: - detail - code properties: detail: type: string code: type: string enum: - subject_deletion_in_progress description: >- Codice di errore stabile per una persona o un'azienda che un'altra richiesta sta ancora eliminando. 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.