API de exclusão de usuários em lote: apagamento GDPR

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

Exclui uma ou mais entidades de usuário. 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 ou Excluir sessões em lote. As transações também não são abrangidas; exclua-as com Excluir transações em lote.

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

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

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

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

Autorizações

x-api-key

string

header

obrigatório

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.

Corpo

application/json

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.

vendor_data_list

string[]

Seus próprios identificadores a excluir, comparados exatamente como enviados.

didit_internal_id_list

string<uuid>[]

IDs internos de usuário da Didit a excluir: o didit_internal_id retornado pelos endpoints de criação e consulta.

delete_all

boolean

padrão:false

Se true, exclui todos os usuários da aplicação.

retain_face_embeddings

boolean

padrão:false

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

integer

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.

Intervalo obrigatório: 1 <= x <= 3650

Exemplo:

365

Resposta

Usuários excluídos. Retorna o número de usuários efetivamente excluídos.

deleted

integer

Número de usuários excluídos (não inclui valores de vendor_data que não corresponderam a nada).

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

​Visão geral

​Quando usar

​Observações

​Dados em um relatório regulatório finalizado

​Permissões

​Relacionados