API de suppression en lot des utilisateurs (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
}

Vue d’ensemble

Supprime une ou plusieurs entités utilisateur. Les enregistrements des utilisateurs sont supprimés de façon définitive. Leurs sessions de vérification ne sont pas couvertes par cet endpoint : elles subsistent, leur lien vers l’utilisateur étant effacé. Supprimez-les avec Supprimer une session ou Supprimer des sessions par lot. Les transactions ne sont pas non plus couvertes ; supprimez-les avec Supprimer des transactions par lot.

Quand l’utiliser

Demandes de droit à l’effacement (RGPD / CCPA).
Nettoyage des utilisateurs de test pendant les tests qualité.
Déprovisionnement des utilisateurs retirés de votre propre plateforme.

Remarques

Accepte une liste de valeurs vendor_data, une liste de valeurs didit_internal_id, ou delete_all: true. Les deux listes peuvent être combinées et sont reliées par un OU logique.
Cet endpoint ne restreint jamais delete_all avec des filtres, et les paramètres de lot filter_* de la Console sont rejetés avec un 400, de sorte qu’une intention restreinte ne supprime pas tous les utilisateurs de l’application. Les exceptions sont filter_has_approved_sessions et filter_has_declined_sessions : ils ne sont ni rejetés ni appliqués, donc ne les envoyez pas avec delete_all.
Tout ou rien : si la suppression ne peut pas être menée à bout pour les utilisateurs sélectionnés, aucun d’entre eux n’est supprimé, et vous pouvez renvoyer la même requête sans risque.
Idempotent : renvoyer la même liste retourne deleted: 0 après la première exécution.
Ne renvoie que le nombre d’éléments supprimés, et non un rapport par élément. Les valeurs sans correspondance sont ignorées silencieusement. Envoyez une liste dédupliquée si vous voulez comparer deleted au nombre d’identifiants envoyés, car un identifiant répété n’est compté qu’une fois.
Aucun webhook n’est émis pour une suppression. Les webhooks se déclenchent lors des changements de statut et de données des utilisateurs, et non lors d’une suppression ; une intégration qui a besoin d’un signal de suppression doit donc l’enregistrer de son côté.
Les sessions de vérification liées à l’utilisateur ne sont PAS supprimées par cet endpoint. Elles subsistent, leur lien vers l’utilisateur étant effacé ; leurs documents, visages et médias ne sont donc supprimés que lorsque vous supprimez les sessions elles-mêmes.
retain_face_embeddings (booléen, false par défaut) et face_retention_days (1 à 3650) traduisent votre choix explicite de conserver, pour chaque personne supprimée, un gabarit biométrique sans image, pour la détection de doublons, pendant ce nombre de jours. Aucune autre donnée sur la personne n’est conservée. Omettez les deux pour supprimer les gabarits avec les utilisateurs. face_retention_days sans retain_face_embeddings: true, ou retain_face_embeddings: true sans face_retention_days, renvoie 400 sur face_retention_days.
Sauf si vous définissez retain_face_embeddings à true, les gabarits biométriques conservés liés à l’utilisateur SONT purgés, avant la suppression de l’utilisateur. Si un gabarit ne peut pas être purgé parce qu’un espace de stockage biométrique est indisponible, l’appel renvoie 503, aucun utilisateur de la requête n’est supprimé, et renvoyer la requête termine le travail.

Données figurant dans un rapport réglementaire finalisé

Si une personne sélectionnée fait partie d’un dossier comportant un rapport réglementaire finalisé, toute la requête renvoie 409 et rien n’est supprimé. La réponse utilise code: in_filed_report et nomme chaque rapport, afin que vous puissiez l’ouvrir dans la 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"
    }
  ]
}

Supprimez chaque rapport avec Supprimer un rapport, puis renvoyez la même requête. Retirer cette personne de la liste ne suffit pas si une autre personne sélectionnée figure encore dans un rapport.

Une suppression déjà en cours

Une personne est supprimée par une seule requête à la fois. Si une autre requête supprime encore l’une des personnes sélectionnées, cette requête attend quelques secondes au maximum, puis renvoie 409 avec code: subject_deletion_in_progress et ne supprime rien :

{
  "detail": "This person or company is being deleted. Retry after deletion completes.",
  "code": "subject_deletion_in_progress"
}

Renvoyez la même requête une fois l’autre suppression terminée. Une personne déjà supprimée par cette autre requête ne correspond plus, donc la requête ne supprime que ce qui reste.

Autorisations

Toute clé API active de l’application peut appeler cet endpoint. Les clés API Didit sont limitées à l’application, et non au rôle : les rôles et autorisations de la Console (delete:users et les autres) déterminent ce qu’une personne peut faire dans la Console, et ne sont pas évalués pour le trafic de l’API de gestion. Pour contrôler qui peut appeler cet endpoint, contrôlez qui peut lire la clé API de l’application.

Liens connexes

Autorisations

x-api-key

string

header

requis

La clé API de votre application, issue de Développeurs -> Clés API dans la Business Console. La clé principale dispose d'un accès complet. Une clé nommée peut être restreinte : aucun, lecture ou écriture par ressource, limitée à certains workflows ou aux sessions approuvées, à une liste d'adresses IP et à une date d'expiration. 401 signifie que la clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a été envoyée, que la clé n'a pas accès à cette ressource ou action, ou que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur une route de session signifie que la session est hors des workflows ou des statuts de la clé. Une clé sans accès aux médias reçoit les URL d'images, de vidéos et de PDF à null, et une clé sans accès en écriture aux sessions reçoit les liens et tokens de session à null. Voir https://docs.didit.me/console/api-keys.

Corps

application/json

Fournissez vendor_data_list, didit_internal_id_list ou delete_all: true. Les deux listes peuvent être combinées et sont évaluées avec un OU logique (OR). Lorsque delete_all est true, il a la priorité et les deux listes sont ignorées.

vendor_data_list

string[]

Vos propres identifiants à supprimer, mis en correspondance exacte avec ceux transmis.

didit_internal_id_list

string<uuid>[]

Identifiants internes d'utilisateur Didit à supprimer - le didit_internal_id renvoyé par les endpoints de création et d'obtention.

delete_all

boolean

défaut:false

Si true, supprime tous les utilisateurs de l'application.

retain_face_embeddings

boolean

défaut:false

Votre choix explicite de conserver un gabarit biométrique sans image de chaque personne supprimée pour la détection des doublons, pendant face_retention_days. Tout le reste concernant la personne est supprimé. Omettez-le, ou envoyez false, pour supprimer les gabarits avec les utilisateurs. Lorsque la valeur est true, face_retention_days est obligatoire.

face_retention_days

integer

Nombre de jours pendant lesquels le gabarit biométrique sans image est conservé lorsque retain_face_embeddings est true. Requis avec ce dernier, et rejeté sans lui avec une erreur 400 sur face_retention_days.

Plage requise: 1 <= x <= 3650

Exemple:

365

Réponse

Utilisateurs supprimés. Renvoie le nombre d'utilisateurs réellement supprimés.

deleted

integer

Nombre d'utilisateurs supprimés (exclut les valeurs vendor_data qui ne correspondaient à rien).

Dernière modification le 7 novembre 2026

​Vue d’ensemble

​Quand l’utiliser

​Remarques

​Données figurant dans un rapport réglementaire finalisé

​Une suppression déjà en cours

​Autorisations

​Liens connexes

Autorisations

Corps

Réponse

Vue d’ensemble

Quand l’utiliser

Remarques

Données figurant dans un rapport réglementaire finalisé

Une suppression déjà en cours

Autorisations

Liens connexes