API de eliminação em lote de utilizadores (RGPD)

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"]}'

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);

ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()

result, err := client.Users.BatchDelete(ctx, didit.UsersBatchDeleteParams{
	VendorDataList: didit.Some([]string{"user-123", "user-456"}),
})
if err != nil {
	log.Fatal(err)
}
fmt.Printf("%+v\n", result)

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);

<?php

require 'vendor/autoload.php';

use Didit\DiditClient;

// Reads DIDIT_API_KEY.
$didit = new DiditClient();

$result = $didit->users->batchDelete([
    'vendor_data_list' => ['user-123', 'user-456'],
]);
print_r($result->toArray());

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));

{
  "deleted": 2
}

POST

users

delete

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"]}'

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);

ctx := context.Background()
// Reads DIDIT_API_KEY.
client := didit.NewClient()

result, err := client.Users.BatchDelete(ctx, didit.UsersBatchDeleteParams{
	VendorDataList: didit.Some([]string{"user-123", "user-456"}),
})
if err != nil {
	log.Fatal(err)
}
fmt.Printf("%+v\n", result)

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);

<?php

require 'vendor/autoload.php';

use Didit\DiditClient;

// Reads DIDIT_API_KEY.
$didit = new DiditClient();

$result = $didit->users->batchDelete([
    'vendor_data_list' => ['user-123', 'user-456'],
]);
print_r($result->toArray());

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));

{
  "deleted": 2
}

Visão geral

Elimina uma ou mais entidades de utilizador. 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 ou Eliminar sessões em lote. As transações também não são abrangidas; elimine-as com Eliminar transações em lote.

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 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 finalizado

Se 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:

{
  "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 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 curso

Uma 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:

{
  "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ões

Qualquer 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 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

Autorizações

x-api-key

string

header

obrigatório

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.

Corpo

application/json

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.

vendor_data_list

string[]

Os seus próprios identificadores a eliminar, correspondidos exatamente como foram enviados.

didit_internal_id_list

string<uuid>[]

IDs internos de utilizador da Didit a eliminar - o didit_internal_id devolvido pelos endpoints de criação e obtenção.

delete_all

boolean

padrão:false

Se true, elimina todos os utilizadores na aplicação.

retain_face_embeddings

boolean

padrão:false

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

integer

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.

Intervalo necessário: 1 <= x <= 3650

Exemplo:

365

Resposta

Utilizadores eliminados. Devolve o número de utilizadores efetivamente eliminados.

deleted

integer

Número de utilizadores eliminados (exclui valores de vendor_data que não corresponderam a nada).

Última modificação em 7 de novembro de 2026

​Visão geral

​Quando utilizar

​Notas

​Dados num relatório regulamentar finalizado

​Uma eliminação já em curso

​Permissões

​Relacionados