> ## 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 de exclusão de usuários em lote: apagamento GDPR > Exclua usuários da Didit em lote por vendor_data ou todos os usuários de uma aplicação. Conforme o direito ao esquecimento do GDPR e da CCPA. Prompt para excluir usuários em lote Copiar o prompt para a área de transferência \

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

\
Colar em ## Visão geralExclui uma ou mais [entidades de usuário](https://docs.didit.me/pt-br/entities/users/overview.md). Os registros dos usuários são removidos permanentemente. As sessões de verificação deles não são abrangidas por este endpoint e continuam existindo, com o vínculo com o usuário removido; exclua-as com [Excluir sessão](https://docs.didit.me/pt-br/sessions-api/delete-session.md) ou [Excluir sessões em lote](https://docs.didit.me/pt-br/management-api/sessions/batch-delete.md). As transações também não são abrangidas; exclua-as com [Excluir transações em lote](https://docs.didit.me/pt-br/management-api/transactions/delete.md).## Quando usar- Solicitações de **direito de ser esquecido** (GDPR / CCPA). - **Limpeza** de usuários de teste durante o QA. - **Desprovisionamento** de usuários removidos da sua própria plataforma.## Observações- Aceita uma lista de valores `vendor_data`, uma lista de valores `didit_internal_id` ou `delete_all: true`. As duas listas podem ser combinadas com OR. - Este endpoint nunca restringe `delete_all` com filtros, e os parâmetros de lote `filter_*` do Console são rejeitados com `400`, para que uma intenção restrita não exclua todos os usuários da aplicação. As exceções são `filter_has_approved_sessions` e `filter_has_declined_sessions`: eles não são rejeitados nem aplicados, então não os envie com `delete_all`. - Tudo ou nada: se a exclusão não puder ser concluída para os usuários selecionados, nenhum deles é excluído e você pode repetir a mesma requisição com segurança. - Idempotente: reenviar a mesma lista retorna `deleted: 0` após a primeira execução. - Retorna apenas a contagem do que foi excluído, não um relatório por item. Valores sem correspondência são ignorados silenciosamente. Envie uma lista sem duplicatas se quiser comparar `deleted` com o número de identificadores enviados, já que um identificador repetido é contado apenas uma vez. - Nenhum webhook é emitido para uma exclusão. Os webhooks são disparados em mudanças de status e de dados do usuário, não na exclusão; por isso, uma integração que precise de um sinal de exclusão deve registrá-lo por conta própria. - As sessões de verificação vinculadas ao usuário NÃO são excluídas por este endpoint. Elas permanecem, com o vínculo com o usuário removido, de modo que seus documentos, rostos e mídias só são removidos quando você exclui as próprias sessões. - `retain_face_embeddings` (booleano, padrão `false`) e `face_retention_days` (de 1 a 3650) são sua escolha explícita de manter um template biométrico sem imagem por pessoa excluída para detecção de duplicatas, por esse número de dias. Nada mais sobre a pessoa é mantido. Omita ambos para excluir os templates junto com os usuários. `face_retention_days` sem `retain_face_embeddings: true`, ou `retain_face_embeddings: true` sem `face_retention_days`, retorna `400` em `face_retention_days`. - A menos que você defina `retain_face_embeddings` como `true`, os [templates biométricos](https://docs.didit.me/pt-br/management-api/biometric-templates/overview.md) retidos vinculados ao usuário SÃO eliminados antes de o usuário ser excluído. Se um template não puder ser eliminado porque um armazenamento biométrico está indisponível, a chamada retorna `503`, nenhum usuário da requisição é excluído, e repetir a requisição conclui a operação.## Dados em um relatório regulatório finalizadoSe alguma pessoa selecionada fizer parte de um caso com um relatório regulatório finalizado, a requisição inteira retorna `409` e nada é excluído. A resposta usa `code: in_filed_report` e nomeia cada relatório, para que você possa abri-lo no 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" } ] } ```Exclua cada relatório com [Excluir relatório](https://docs.didit.me/pt-br/management-api/regulatory-reports/delete.md) e depois repita a mesma requisição. Remover essa pessoa da lista não basta se outra pessoa selecionada ainda estiver em um relatório.## PermissõesQualquer chave de API ativa da aplicação pode chamar este endpoint. As chaves de API da Didit são **associadas à aplicação, não à função**: as [funções e permissões](https://docs.didit.me/pt-br/console/roles-permissions.md) do Console (`delete:users` e as demais) definem o que uma *pessoa* pode fazer no Console e não são avaliadas para o tráfego da Management API. Controle quem pode chamar este endpoint controlando quem pode ler a chave de API da aplicação.## Relacionados- [Retenção de dados](https://docs.didit.me/pt-br/console/data-retention.md) - [Registros de auditoria](https://docs.didit.me/pt-br/console/audit-logs.md) - [Operações de usuário](https://docs.didit.me/pt-br/entities/users/operations.md) - [Templates biométricos](https://docs.didit.me/pt-br/management-api/biometric-templates/overview.md) ## OpenAPI ````yaml pt-br/openapi-25.json POST /v3/users/delete/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API de verificação de identidade. Autentique-se com o cabeçalho x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/users/delete/: post: tags: - Users summary: Excluir usuários em lote description: >- **Exclui permanentemente** usuários: os registros dos usuários são removidos de forma permanente. Para bloqueios do dia a dia, prefira [Update User Status](#patch-/v3/users/-vendor_data-/update-status/) com `BLOCKED`. Selecione usuários com `vendor_data_list`, com `didit_internal_id_list` ou com ambos ao mesmo tempo; ou envie `delete_all: true`. Este endpoint nunca restringe `delete_all` com filtros. Os filtros de People do Console são recusados com `400` (veja a resposta `400`), para que uma intenção restrita não se transforme em uma exclusão total. Há duas exceções: `filter_has_approved_sessions` e `filter_has_declined_sessions` não são recusados nem aplicados, então, com `delete_all: true`, eles ainda excluem todos os usuários; não os envie. **Templates biométricos:** a menos que você defina `retain_face_embeddings` como `true`, todo template biométrico sem imagem retido para esses usuários após a exclusão da sessão (veja `/v3/biometric-templates/`) é eliminado antes de o usuário ser excluído, de modo que a pessoa deixa de gerar correspondências na detecção de duplicatas e na Busca facial. Com `retain_face_embeddings: true` e `face_retention_days`, você opta por manter um template biométrico sem imagem por pessoa durante esse número de dias, e nada mais sobre a pessoa é mantido. Se um template não puder ser eliminado porque um armazenamento biométrico está indisponível, a chamada retorna `503`, nenhum usuário da requisição é excluído, e repetir a requisição conclui o trabalho. **Relatórios regulatórios enviados:** se os dados selecionados estiverem em um relatório regulatório finalizado, a requisição inteira é recusada com `409` e nada é excluído. O corpo usa `code: in_filed_report` e identifica cada relatório com `uuid`, `report_number`, `report_type` e `case_uuid`. Exclua os relatórios e repita a requisição. operationId: batch_delete_users requestBody: required: true content: application/json: schema: type: object description: >- Informe `vendor_data_list`, `didit_internal_id_list` ou `delete_all: true`. As duas listas podem ser combinadas e são unidas por OR. Quando `delete_all` é `true`, ele tem precedência e ambas as listas são ignoradas. properties: vendor_data_list: type: array items: type: string description: >- Seus próprios identificadores a excluir, comparados exatamente como enviados. didit_internal_id_list: type: array items: type: string format: uuid description: >- IDs internos de usuário da Didit a excluir: o `didit_internal_id` retornado pelos endpoints de criação e consulta. delete_all: type: boolean default: false description: Se `true`, exclui todos os usuários da aplicação. retain_face_embeddings: type: boolean default: false description: >- Sua escolha explícita de manter um template biométrico sem imagem de cada pessoa excluída para detecção de duplicatas, por `face_retention_days`. Todo o resto sobre a pessoa é excluído. Omita-o, ou envie `false`, para excluir os templates junto com os usuários. Quando `true`, `face_retention_days` é obrigatório. face_retention_days: type: integer minimum: 1 maximum: 3650 description: >- Número de dias durante os quais o template biométrico sem imagem é mantido quando `retain_face_embeddings` é `true`. Obrigatório junto com ele e, sem ele, rejeitado com um `400` em `face_retention_days`. example: 365 examples: Specific users: summary: Excluir usuários por vendor_data value: vendor_data_list: - user-123 - user-456 By Didit internal ID: summary: Excluir usuários por didit_internal_id value: didit_internal_id_list: - 3f1c0d3e-8f0a-4c2e-9a3d-9b1f5f4a2c11 All users: summary: Excluir todos os usuários desta aplicação value: delete_all: true Keep face templates: summary: >- Excluir usuários e manter templates faciais anônimos por 365 dias value: vendor_data_list: - user-123 retain_face_embeddings: true face_retention_days: 365 responses: '200': description: >- Usuários excluídos. Retorna o número de usuários efetivamente excluídos. content: application/json: schema: type: object properties: deleted: type: integer description: >- Número de usuários excluídos (não inclui valores de vendor_data que não corresponderam a nada). examples: Deleted some: value: deleted: 2 Nothing matched: value: deleted: 0 '400': description: >- Erro de validação; nada é excluído. Os erros são indexados pelo nome do campo. Sem seletor (nenhuma das listas e `delete_all` diferente de `true`), o corpo é `{"vendor_data_list": ["This field is required unless delete_all is true."]}`; uma lista vazia é recusada sob sua própria chave com `"This list may not be empty."`. Um filtro exclusivo do 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` ou `filter_auth_mfa_enabled`) é recusado sempre que tiver um valor, mesmo `false`, com um objeto indexado por cada um desses campos. Qualquer outra chave `filter_*` desconhecida é recusada com `"Unknown filter."`. content: application/json: examples: Missing selector: summary: Nem list nem delete_all foram informados 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: >- Nenhuma credencial fornecida. Requisições para caminhos `/v3/users/*` sem um cabeçalho `x-api-key` (ou token `Authorization: Bearer`) são rejeitadas pelo middleware de autenticação antes de chegarem à API. content: application/json: examples: Missing credentials: value: detail: >- You must be authenticated with a valid access token to access this endpoint. '403': description: >- Chave de API inválida ou revogada, ou a chave não pode excluir usuários desta aplicação. Uma chave ausente retorna `403`; uma chave incorreta, revogada ou expirada retorna `401`. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- A seleção inclui uma pessoa em um relatório regulatório finalizado. Nada é excluído. content: application/json: schema: $ref: '#/components/schemas/InFiledReportError' '429': description: >- Limite de requisições excedido; aguarde e tente novamente após o intervalo indicado em `Retry-After`. content: application/json: examples: Rate limited: value: detail: Request was throttled. Expected available in 30 seconds. '503': description: >- Um armazenamento biométrico ficou indisponível durante a retenção ou a exclusão de um template biométrico. Nada é excluído; repita a mesma requisição. As novas tentativas são idempotentes e convergem para um único template. 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: >- A exclusão é recusada porque os dados selecionados estão em um relatório regulatório finalizado. Nada é excluído. Exclua o relatório e repita a requisição. required: - detail - code properties: detail: type: string code: type: string enum: - in_filed_report description: >- Código de erro estável para uma exclusão bloqueada por um relatório regulatório finalizado. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: >- Relatórios que bloqueiam a exclusão de uma pessoa, empresa, caso ou sessão. transactions: type: array items: $ref: '#/components/schemas/FiledReportTransaction' description: >- Transações que impedem a exclusão de uma transação, cada uma com os relatórios que a listam. FiledRegulatoryReport: type: object description: Um relatório regulatório finalizado que impede a exclusão solicitada. required: - uuid - report_number - report_type - case_uuid properties: uuid: type: string format: uuid description: UUID do relatório. report_number: type: string description: Número do relatório exibido no Console (por exemplo, SAR-0001). report_type: type: string enum: - SAR - STR - CTR - TTR - UTR - IFT - CBR - TFR description: Tipo de relatório regulatório. case_uuid: type: string format: uuid description: Caso ao qual o relatório pertence. FiledReportTransaction: type: object description: >- Uma transação que não pode ser excluída porque um relatório regulatório finalizado a inclui. required: - uuid - transaction_id - reports properties: uuid: type: string format: uuid description: UUID da transação na Didit. transaction_id: type: string description: >- O identificador da transação informado quando a transação foi criada. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: Relatórios finalizados que incluem esta transação. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- Chave de API da sua aplicação, em Developers -> API keys no Business Console. A chave principal tem acesso total. Uma chave nomeada pode ter escopo restrito: nenhum acesso, leitura ou escrita por recurso, limitada a alguns fluxos ou a sessões aprovadas, a uma lista de endereços IP e a uma data de validade. 401 significa que a chave está errada, revogada ou expirada; 403 significa que nenhuma chave foi enviada, que a chave não tem acesso a este recurso ou ação, ou que a requisição veio de um endereço fora da sua lista de IPs; 404 em uma rota de sessão significa que a sessão está fora dos fluxos ou status da chave. Uma chave sem acesso a mídia recebe URLs de imagem, vídeo e PDF como null, e uma chave sem permissão de escrita em sessões recebe links e tokens de sessão como null. Consulte https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.