> ## 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 eliminação em lote de utilizadores (RGPD) > Elimine em lote utilizadores Didit por vendor_data ou todos os utilizadores de uma aplicação. Conforme com o direito a ser esquecido do RGPD e do CCPA. Prompt para eliminar utilizadores 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.
\- 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.`

\
Colar em ## Visão geralElimina uma ou mais [entidades de utilizador](https://docs.didit.me/pt/entities/users/overview.md). Os registos de utilizador são removidos de forma permanente. As respetivas sessões de verificação não são abrangidas por este endpoint e permanecem, com a ligação ao utilizador removida; elimine-as com [Eliminar sessão](https://docs.didit.me/pt/sessions-api/delete-session.md) ou [Eliminar sessões em lote](https://docs.didit.me/pt/management-api/sessions/batch-delete.md). As transações também não são abrangidas; elimine-as com [Eliminar transações em lote](https://docs.didit.me/pt/management-api/transactions/delete.md).## Quando utilizar- Pedidos de **direito ao esquecimento** (RGPD / CCPA). - **Limpeza** de utilizadores de teste durante o QA. - **Desprovisionamento** de utilizadores removidos da sua própria plataforma.## Notas- Aceita uma lista de valores `vendor_data`, uma lista de valores `didit_internal_id` ou `delete_all: true`. As duas listas podem ser combinadas e são combinadas com OR. - Este endpoint nunca restringe `delete_all` com filtros, e os parâmetros em lote `filter_*` da Consola são rejeitados com `400`, pelo que uma intenção restringida não elimina todos os utilizadores da aplicação. As exceções são `filter_has_approved_sessions` e `filter_has_declined_sessions`: não são rejeitados nem aplicados, por isso não os envie com `delete_all`. - Tudo ou nada: se a eliminação não puder ser concluída para os utilizadores selecionados, nenhum deles é eliminado e pode repetir o mesmo pedido em segurança. - Idempotente: reenviar a mesma lista devolve `deleted: 0` após a primeira execução. - Devolve apenas uma contagem do que foi eliminado, e não um relatório por item. Os valores que não correspondem a nada são ignorados silenciosamente. Envie uma lista sem duplicados se quiser comparar `deleted` com o número de identificadores enviados, uma vez que um identificador repetido só é contado uma vez. - Não é emitido nenhum webhook para uma eliminação. Os webhooks disparam em alterações de estado e de dados do utilizador, não na eliminação; por isso, uma integração que precise de um sinal de eliminação deve registá-lo do seu lado. - As sessões de verificação ligadas ao utilizador NÃO são eliminadas por este endpoint. Permanecem, com a ligação ao utilizador removida, pelo que os seus documentos, rostos e ficheiros multimédia só são removidos quando eliminar as próprias sessões. - `retain_face_embeddings` (booleano, predefinição `false`) e `face_retention_days` (1 a 3650) são a sua escolha explícita de manter, por pessoa eliminada, um template biométrico sem imagem para deteção de duplicados, durante esse número de dias. Nada mais sobre a pessoa é conservado. Omita ambos para eliminar os templates juntamente com os utilizadores. `face_retention_days` sem `retain_face_embeddings: true`, ou `retain_face_embeddings: true` sem `face_retention_days`, devolve `400` em `face_retention_days`. - A menos que defina `retain_face_embeddings` como `true`, os [templates biométricos](https://docs.didit.me/pt/management-api/biometric-templates/overview.md) retidos ligados ao utilizador SÃO purgados, antes de o utilizador ser eliminado. Se um template não puder ser purgado porque um armazenamento biométrico está indisponível, o pedido devolve `503`, nenhum utilizador do pedido é eliminado, e repetir o pedido conclui a operação.## Dados num relatório regulamentar finalizadoSe alguma pessoa selecionada fizer parte de um caso com um relatório regulamentar finalizado, todo o pedido devolve `409` e nada é eliminado. A resposta usa `code: in_filed_report` e indica cada relatório, para que o possa abrir na Consola:```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" } ] } ```Elimine cada relatório com [Eliminar relatório](https://docs.didit.me/pt/management-api/regulatory-reports/delete.md) e, em seguida, repita o mesmo pedido. Remover essa pessoa da lista não basta se outra pessoa selecionada ainda estiver num relatório.## Uma eliminação já em cursoUma pessoa é eliminada por um pedido de cada vez. Se outro pedido ainda estiver a eliminar uma das pessoas selecionadas, este pedido aguarda no máximo alguns segundos e, em seguida, devolve `409` com `code: subject_deletion_in_progress` e não elimina nada:```json theme={null} { "detail": "This person or company is being deleted. Retry after deletion completes.", "code": "subject_deletion_in_progress" } ```Repita o mesmo pedido quando a outra eliminação tiver terminado. Uma pessoa que essa eliminação já tenha removido deixa de corresponder, pelo que a repetição elimina apenas o que resta.## PermissõesQualquer chave de API ativa da aplicação pode chamar este endpoint. As chaves de API da Didit são **limitadas à aplicação, e não a funções**: as [funções e permissões](https://docs.didit.me/pt/console/roles-permissions.md) da Consola (`delete:users` e as restantes) determinam o que uma *pessoa* pode fazer na Consola, e não são avaliadas para o tráfego da API de Gestão. Controle quem pode chamar este endpoint controlando quem pode ler a chave de API da aplicação.## Relacionados- [Conservação de dados](https://docs.didit.me/pt/console/data-retention.md) - [Registos de auditoria](https://docs.didit.me/pt/console/audit-logs.md) - [Operações de utilizadores](https://docs.didit.me/pt/entities/users/operations.md) - [Templates biométricos](https://docs.didit.me/pt/management-api/biometric-templates/overview.md) ## OpenAPI ````yaml pt/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: Eliminar utilizadores em lote description: >- **Elimine permanentemente** utilizadores: os registos de utilizador são removidos permanentemente. Para o bloqueio do dia a dia, prefira [Update User Status](#patch-/v3/users/-vendor_data-/update-status/) com `BLOCKED`. Selecione utilizadores com `vendor_data_list`, com `didit_internal_id_list` ou com ambos em simultâneo; ou passe `delete_all: true`. Este endpoint nunca restringe `delete_all` com filtros. Os filtros de Pessoas da Console são recusados com um `400` (consulte a resposta `400`), para que uma intenção restrita não se transforme numa eliminação total. Duas exceções: `filter_has_approved_sessions` e `filter_has_declined_sessions` não são recusados nem aplicados, pelo que com `delete_all: true` continuam a eliminar todos os utilizadores; não os envie. **Templates biométricos:** a menos que defina `retain_face_embeddings` como `true`, todos os templates biométricos sem imagem retidos para estes utilizadores após a eliminação da sessão (consulte `/v3/biometric-templates/`) são purgados antes de o utilizador ser eliminado, pelo que a pessoa deixa de gerar correspondências na deteção de duplicados e na Pesquisa facial. Com `retain_face_embeddings: true` e `face_retention_days`, opta por manter um template biométrico sem imagem por pessoa durante esse número de dias, não sendo mantido mais nada sobre a pessoa. Se um template não puder ser purgado devido à indisponibilidade de um armazenamento biométrico, a chamada devolve `503`, nenhum utilizador no pedido é eliminado e a repetição do pedido conclui a operação. **Relatórios regulamentares submetidos:** se os dados selecionados estiverem num relatório regulamentar finalizado, todo o pedido é recusado com `409` e nada é eliminado. O corpo utiliza `code: in_filed_report` e identifica cada relatório com `uuid`, `report_number`, `report_type` e `case_uuid`. Elimine os relatórios e repita o pedido. operationId: batch_delete_users requestBody: required: true content: application/json: schema: type: object description: >- Forneça `vendor_data_list`, `didit_internal_id_list` ou `delete_all: true`. As duas listas podem ser combinadas com um operador OR. Quando `delete_all` é `true`, tem precedência e ambas as listas são ignoradas. properties: vendor_data_list: type: array items: type: string description: >- Os seus próprios identificadores a eliminar, correspondidos exatamente como foram enviados. didit_internal_id_list: type: array items: type: string format: uuid description: >- IDs internos de utilizador da Didit a eliminar - o `didit_internal_id` devolvido pelos endpoints de criação e obtenção. delete_all: type: boolean default: false description: Se `true`, elimina todos os utilizadores na aplicação. retain_face_embeddings: type: boolean default: false description: >- A sua escolha explícita de manter um modelo biométrico sem imagem de cada pessoa eliminada para deteção de duplicados, durante `face_retention_days`. Tudo o resto sobre a pessoa é eliminado. Omita este campo, ou envie `false`, para eliminar os modelos juntamente com os utilizadores. Quando for `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 é conservado quando `retain_face_embeddings` for `true`. Obrigatório com este parâmetro e rejeitado sem ele com um `400` em `face_retention_days`. example: 365 examples: Specific users: summary: Eliminar utilizadores por vendor_data value: vendor_data_list: - user-123 - user-456 By Didit internal ID: summary: Eliminar utilizadores por didit_internal_id value: didit_internal_id_list: - 3f1c0d3e-8f0a-4c2e-9a3d-9b1f5f4a2c11 All users: summary: Apagar todos os utilizadores nesta aplicação value: delete_all: true Keep face templates: summary: >- Eliminar utilizadores e manter modelos faciais anónimos durante 365 dias value: vendor_data_list: - user-123 retain_face_embeddings: true face_retention_days: 365 responses: '200': description: >- Utilizadores eliminados. Devolve o número de utilizadores efetivamente eliminados. content: application/json: schema: type: object properties: deleted: type: integer description: >- Número de utilizadores eliminados (exclui 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 é eliminado. Os erros são indexados pelo nome do campo. Sem nenhum seletor (nenhuma lista e `delete_all` não sendo `true`), o corpo é `{"vendor_data_list": ["This field is required unless delete_all is true."]}`; uma lista vazia é recusada sob a sua própria chave com `"This list may not be empty."`. Um filtro exclusivo da 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 fornecidos 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. Os pedidos para caminhos `/v3/users/*` sem um cabeçalho `x-api-key` (ou token `Authorization: Bearer`) são rejeitados 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 eliminar utilizadores para esta aplicação. Uma chave em falta devolve `403`; uma chave incorreta, revogada ou expirada devolve `401`. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- Nada é eliminado. O `code` indica o motivo: `in_filed_report` quando a seleção inclui uma pessoa num relatório regulamentar finalizado, `subject_deletion_in_progress` quando outro pedido ainda está a eliminar uma das pessoas selecionadas. Repita o pedido assim que essa eliminação estiver concluída. content: application/json: schema: oneOf: - $ref: '#/components/schemas/InFiledReportError' - $ref: '#/components/schemas/SubjectDeletionInProgressError' '429': description: >- Limite de pedidos excedido; reduza a frequência 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 estava indisponível durante a retenção ou eliminação de um template biométrico. Nada é eliminado; repita o mesmo pedido. As novas tentativas são idempotentes e convergem para um único modelo. 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 eliminação foi recusada porque os dados selecionados constam de um relatório regulamentar finalizado. Nada é eliminado. Elimine o relatório e, em seguida, repita o pedido. required: - detail - code properties: detail: type: string code: type: string enum: - in_filed_report description: >- Código de erro estável para uma eliminação bloqueada por um relatório regulamentar finalizado. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: >- Relatórios que bloqueiam a eliminação de uma pessoa, empresa, caso ou sessão. transactions: type: array items: $ref: '#/components/schemas/FiledReportTransaction' description: >- Transações que bloqueiam a eliminação de uma transação, cada uma com os relatórios que a listam. SubjectDeletionInProgressError: type: object description: >- Outro pedido ainda está a eliminar esta pessoa ou empresa. Este pedido não eliminou nada e pode ser repetido assim que essa eliminação terminar; uma repetição eliminará o que ainda estiver selecionado. required: - detail - code properties: detail: type: string code: type: string enum: - subject_deletion_in_progress description: >- Código de erro estável para uma pessoa ou empresa que outro pedido ainda está a eliminar. FiledRegulatoryReport: type: object description: Um relatório regulamentar finalizado que impede a eliminação pedida. 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 apresentado na Consola (por exemplo, SAR-0001). report_type: type: string enum: - SAR - STR - CTR - TTR - UTR - IFT - CBR - TFR description: Tipo de relatório regulamentar. 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 eliminada porque um relatório regulamentar finalizado a inclui. required: - uuid - transaction_id - reports properties: uuid: type: string format: uuid description: UUID da transação Didit. transaction_id: type: string description: >- O identificador de transação fornecido aquando da criação da transação. reports: type: array items: $ref: '#/components/schemas/FiledRegulatoryReport' description: Relatórios finalizados que listam esta transação. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- A chave de API da sua aplicação, a partir de Programadores -> Chaves de API na Business Console. A chave principal tem acesso total. Uma chave nomeada pode ter o âmbito definido: nenhum, 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á incorreta, 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 o pedido veio de um endereço fora da sua lista de IP; 404 numa rota de sessão significa que a sessão está fora dos fluxos ou estados da chave. Uma chave sem acesso a multimédia recebe URLs de imagens, vídeos e PDFs como nulos, e uma chave sem permissão de escrita em sessões recebe ligações de sessão e tokens como nulos. Consulte https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.