> ## 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 para eliminar usuarios en lote: borrado RGPD > Elimina en lote usuarios de Didit por vendor_data o todos los usuarios de una aplicación. Cumple con el derecho al olvido del RGPD y la CCPA. Prompt para eliminar usuarios en lote Copiar el prompt al portapapeles \

\`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.
\- 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.`

\
Pegar en ## Descripción generalElimina una o más [entidades de usuario](https://docs.didit.me/es/entities/users/overview.md). Los registros de usuario se eliminan de forma permanente. Este endpoint no abarca sus sesiones de verificación, que se conservan sin su vínculo con el usuario; elimínalas con [Eliminar sesión](https://docs.didit.me/es/sessions-api/delete-session.md) o [Eliminar sesiones en lote](https://docs.didit.me/es/management-api/sessions/batch-delete.md). Tampoco abarca las transacciones; elimínalas con [Eliminar transacciones en lote](https://docs.didit.me/es/management-api/transactions/delete.md).## Cuándo usarlo- Solicitudes de **derecho al olvido** (RGPD / CCPA). - **Limpieza** de usuarios de prueba durante QA. - **Desaprovisionamiento** de usuarios eliminados de tu propia plataforma.## Notas- Acepta una lista de valores `vendor_data`, una lista de valores `didit_internal_id` o `delete_all: true`. Las dos listas se pueden combinar y se combinan mediante OR. - Este endpoint nunca acota `delete_all` con filtros, y los parámetros de lote `filter_*` de la Console se rechazan con un `400`, de modo que una intención acotada no elimina a todos los usuarios de la aplicación. Las excepciones son `filter_has_approved_sessions` y `filter_has_declined_sessions`: no se rechazan ni se aplican, así que no los envíes con `delete_all`. - Todo o nada: si la eliminación no se puede completar para los usuarios que seleccionaste, no se elimina ninguno y puedes repetir la misma solicitud con seguridad. - Idempotente: reenviar la misma lista devuelve `deleted: 0` después de la primera ejecución. - Devuelve solo el recuento de lo eliminado, no un informe por elemento. Los valores que no coinciden con nada se omiten sin aviso. Envía una lista sin duplicados si quieres comparar `deleted` con el número de identificadores que enviaste, ya que un identificador repetido solo se cuenta una vez. - Una eliminación no emite ningún webhook. Los webhooks se disparan con los cambios de estado y de datos del usuario, no con la eliminación, por lo que una integración que necesite una señal de eliminación debe registrarla en su propio sistema. - Este endpoint NO elimina las sesiones de verificación vinculadas al usuario. Se conservan, con el vínculo con el usuario eliminado, por lo que sus documentos, rostros y archivos multimedia solo se eliminan cuando eliminas las propias sesiones. - `retain_face_embeddings` (booleano, valor predeterminado `false`) y `face_retention_days` (de 1 a 3650) son tu decisión explícita de conservar una plantilla biométrica sin imagen por cada persona eliminada para la detección de duplicados, durante ese número de días. No se conserva nada más de la persona. Omite ambos para eliminar las plantillas junto con los usuarios. `face_retention_days` sin `retain_face_embeddings: true`, o `retain_face_embeddings: true` sin `face_retention_days`, devuelve `400` en `face_retention_days`. - Salvo que establezcas `retain_face_embeddings` en `true`, las [plantillas biométricas](https://docs.didit.me/es/management-api/biometric-templates/overview.md) conservadas que están asociadas al usuario SÍ se purgan, antes de eliminar al usuario. Si una plantilla no se puede purgar porque un almacén biométrico no está disponible, la solicitud devuelve `503`, no se elimina ningún usuario de la solicitud y al repetir la solicitud, se completa la eliminación.## Datos en un informe regulatorio finalizadoSi alguna de las personas seleccionadas forma parte de un caso con un informe regulatorio finalizado, toda la solicitud devuelve `409` y no se elimina nada. La respuesta usa `code: in_filed_report` e identifica cada informe, para que puedas abrirlo en la 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 cada informe con [Eliminar informe](https://docs.didit.me/es/management-api/regulatory-reports/delete.md) y luego repite la misma solicitud. Quitar a esa persona de la lista no es suficiente si otra persona seleccionada sigue en un informe.## PermisosCualquier clave de API activa de la aplicación puede llamar a este endpoint. Las claves de API de Didit **tienen alcance de aplicación, no de rol**: los [roles y permisos](https://docs.didit.me/es/console/roles-permissions.md) de la Console (`delete:users` y el resto) determinan lo que una *persona* puede hacer en la Console, y no se evalúan para el tráfico de la Management API. Controla quién puede invocar este endpoint controlando quién puede leer la clave de API de la aplicación.## Relacionado- [Retención de datos](https://docs.didit.me/es/console/data-retention.md) - [Registros de auditoría](https://docs.didit.me/es/console/audit-logs.md) - [Operaciones de usuarios](https://docs.didit.me/es/entities/users/operations.md) - [Plantillas biométricas](https://docs.didit.me/es/management-api/biometric-templates/overview.md) ## OpenAPI ````yaml es/openapi-25.json POST /v3/users/delete/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API de verificación de identidad. Autentícate con el encabezado x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/users/delete/: post: tags: - Users summary: Eliminar usuarios en lote description: >- **Elimina de forma permanente** usuarios: los registros de usuario se eliminan de forma permanente. Para bloqueos habituales, es preferible [Actualizar el estado del usuario](#patch-/v3/users/-vendor_data-/update-status/) con `BLOCKED`. Selecciona usuarios con `vendor_data_list`, con `didit_internal_id_list` o con ambos a la vez; o envía `delete_all: true`. Este endpoint nunca acota `delete_all` con filtros. Los filtros de People de la consola se rechazan con un `400` (consulta la respuesta `400`), de modo que una intención acotada no se convierte en un borrado total. Hay dos excepciones: `filter_has_approved_sessions` y `filter_has_declined_sessions` no se rechazan ni se aplican, así que con `delete_all: true` igualmente eliminan a todos los usuarios; no los envíes. **Plantillas biométricas:** salvo que establezcas `retain_face_embeddings` en `true`, cada plantilla biométrica sin imagen conservada para estos usuarios tras la eliminación de la sesión (consulta `/v3/biometric-templates/`) se purga antes de eliminar al usuario, de modo que la persona deja de coincidir en la detección de duplicados y en la Búsqueda facial. Con `retain_face_embeddings: true` y `face_retention_days`, eliges conservar una plantilla biométrica sin imagen por persona durante ese número de días, y no se conserva nada más sobre la persona. Si una plantilla no se puede purgar porque un almacén biométrico no está disponible, la llamada devuelve `503`, no se elimina ningún usuario de la solicitud y, al repetir la solicitud, se completa el proceso. **Informes regulatorios presentados:** si los datos seleccionados están en un informe regulatorio finalizado, se rechaza toda la solicitud con `409` y no se elimina nada. El cuerpo usa `code: in_filed_report` e identifica cada informe con `uuid`, `report_number`, `report_type` y `case_uuid`. Elimina los informes y repite la solicitud. operationId: batch_delete_users requestBody: required: true content: application/json: schema: type: object description: >- Proporciona `vendor_data_list`, `didit_internal_id_list` o `delete_all: true`. Las dos listas se pueden combinar y se aplican con OR. Cuando `delete_all` es `true`, tiene precedencia y se ignoran ambas listas. properties: vendor_data_list: type: array items: type: string description: >- Tus propios identificadores que se van a eliminar, comparados exactamente como se enviaron. didit_internal_id_list: type: array items: type: string format: uuid description: >- IDs internos de usuario de Didit que se van a eliminar: el `didit_internal_id` que devuelven los endpoints de creación y obtención. delete_all: type: boolean default: false description: Si es `true`, elimina todos los usuarios de la aplicación. retain_face_embeddings: type: boolean default: false description: >- Tu decisión explícita de conservar una plantilla biométrica sin imágenes de cada persona eliminada para la detección de duplicados, durante `face_retention_days`. Todo lo demás sobre la persona se elimina. Omítelo, o envía `false`, para eliminar las plantillas junto con los usuarios. Cuando es `true`, `face_retention_days` es obligatorio. face_retention_days: type: integer minimum: 1 maximum: 3650 description: >- Número de días que se conserva la plantilla biométrica sin imágenes cuando `retain_face_embeddings` es `true`. Es obligatorio junto con él, y sin él se rechaza con un `400` en `face_retention_days`. example: 365 examples: Specific users: summary: Eliminar usuarios por vendor_data value: vendor_data_list: - user-123 - user-456 By Didit internal ID: summary: Eliminar usuarios por didit_internal_id value: didit_internal_id_list: - 3f1c0d3e-8f0a-4c2e-9a3d-9b1f5f4a2c11 All users: summary: Borrar todos los usuarios de esta aplicación value: delete_all: true Keep face templates: summary: >- Eliminar usuarios y conservar plantillas faciales anónimas durante 365 días value: vendor_data_list: - user-123 retain_face_embeddings: true face_retention_days: 365 responses: '200': description: >- Usuarios eliminados. Devuelve el número de usuarios realmente eliminados. content: application/json: schema: type: object properties: deleted: type: integer description: >- Número de usuarios eliminados (excluye los valores de vendor_data que no coincidieron con nada). examples: Deleted some: value: deleted: 2 Nothing matched: value: deleted: 0 '400': description: >- Error de validación; no se elimina nada. Los errores se agrupan por nombre de campo. Sin selector (ninguna de las listas y `delete_all` distinto de `true`), el cuerpo es `{"vendor_data_list": ["This field is required unless delete_all is true."]}`; una lista vacía se rechaza bajo su propia clave con `"This list may not be empty."`. Un filtro exclusivo de la 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`) se rechaza siempre que tenga un valor, incluso `false`, con un objeto cuyas claves son cada uno de esos campos. Cualquier otra clave `filter_*` desconocida se rechaza con `"Unknown filter."`. content: application/json: examples: Missing selector: summary: No se proporcionó ni list ni delete_all 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: >- No se proporcionaron credenciales. El middleware de autenticación rechaza las solicitudes a rutas `/v3/users/*` sin un encabezado `x-api-key` (o un token `Authorization: Bearer`) antes de que lleguen a la API. content: application/json: examples: Missing credentials: value: detail: >- You must be authenticated with a valid access token to access this endpoint. '403': description: >- Clave de API no válida o revocada, o la clave no puede eliminar usuarios de esta aplicación. Si falta la clave, se devuelve `403`; si la clave es incorrecta, está revocada o ha expirado, se devuelve `401`. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- La selección incluye una persona que figura en un informe regulatorio finalizado. No se elimina nada. content: application/json: schema: $ref: '#/components/schemas/InFiledReportError' '429': description: >- Límite de solicitudes superado; espera y reintenta cuando haya pasado el intervalo indicado en `Retry-After`. content: application/json: examples: Rate limited: value: detail: Request was throttled. Expected available in 30 seconds. '503': description: >- Un almacén biométrico no estaba disponible al conservar o purgar una plantilla biométrica. No se elimina nada; repite la misma solicitud. Los reintentos son idempotentes y convergen en una única plantilla. 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: >- La eliminación se rechaza porque los datos seleccionados están en un informe regulatorio finalizado. No se elimina nada. Elimina el informe y luego repite la solicitud. required: - detail - code properties: detail: type: string code: type: string enum: - in_filed_report description: >- Código de error estable para una eliminación bloqueada por un informe regulatorio finalizado. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: Informes que impiden eliminar una persona, empresa, caso o sesión. transactions: type: array items: $ref: '#/components/schemas/FiledReportTransaction' description: >- Transacciones que bloquean la eliminación de una transacción, cada una con los informes que la incluyen. FiledRegulatoryReport: type: object description: Un informe regulatorio finalizado que impide la eliminación solicitada. required: - uuid - report_number - report_type - case_uuid properties: uuid: type: string format: uuid description: UUID del informe. report_number: type: string description: >- Número de informe que se muestra en la consola (por ejemplo, SAR-0001). report_type: type: string enum: - SAR - STR - CTR - TTR - UTR - IFT - CBR - TFR description: Tipo de informe regulatorio. case_uuid: type: string format: uuid description: Caso al que pertenece el informe. FiledReportTransaction: type: object description: >- Una transacción que no se puede eliminar porque figura en un informe regulatorio finalizado. required: - uuid - transaction_id - reports properties: uuid: type: string format: uuid description: UUID de transacción de Didit. transaction_id: type: string description: >- El identificador de la transacción proporcionado al crear la transacción. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: Informes finalizados que incluyen esta transacción. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- La clave de API de tu aplicación, que encontrarás en Developers -> API keys en la Business Console. La clave principal tiene acceso completo. Una clave con nombre puede tener un alcance limitado: ninguno, lectura o escritura por recurso, limitada a algunos flujos o a sesiones aprobadas, a una lista de direcciones IP y a una fecha de caducidad. 401 significa que la clave es incorrecta, se revocó o expiró; 403 significa que no se envió ninguna clave, que la clave no tiene acceso a este recurso o acción, o que la solicitud provino de una dirección fuera de su lista de IP; 404 en una ruta de sesión significa que la sesión está fuera de los flujos o estados de la clave. Una clave sin acceso a contenido multimedia recibe las URL de imágenes, videos y PDF como null, y una clave sin permiso de escritura en sesiones recibe los enlaces y tokens de sesión como null. Consulta https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.