Benutzer löschen API: Batch-Löschung und DSGVO-Löschung

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
}

Überblick

Löscht eine oder mehrere Benutzer-Entitäten. Die Benutzerdatensätze werden dauerhaft entfernt. Ihre Verifizierungssitzungen werden von diesem Endpoint nicht erfasst. Sie bleiben bestehen, wobei ihre Verknüpfung mit dem Benutzer entfernt wird. Löschen Sie sie mit Sitzung löschen oder Mehrere Sitzungen löschen. Auch Transaktionen werden nicht erfasst. Löschen Sie sie mit Mehrere Transaktionen löschen.

Wann Sie ihn verwenden

Anfragen zum Recht auf Vergessenwerden (DSGVO / CCPA).
Bereinigung von Testbenutzern während der QA.
Deprovisionierung von Benutzern, die von Ihrer eigenen Plattform entfernt wurden.

Hinweise

Akzeptiert eine Liste von vendor_data-Werten, eine Liste von didit_internal_id-Werten oder delete_all: true. Die beiden Listen können kombiniert werden und sind mit ODER verknüpft.
Dieser Endpoint schränkt delete_all nie durch Filter ein. Die filter_*-Batch-Parameter der Console werden mit einem 400 abgelehnt, damit eine eingeschränkte Absicht nicht alle Benutzer der Anwendung löscht. Ausnahmen sind filter_has_approved_sessions und filter_has_declined_sessions: Sie werden weder abgelehnt noch angewendet. Senden Sie sie daher nicht zusammen mit delete_all.
Alles oder nichts: Kann die Löschung für die ausgewählten Benutzer nicht abgeschlossen werden, wird keiner von ihnen gelöscht, und Sie können dieselbe Anfrage gefahrlos wiederholen.
Idempotent: Wird dieselbe Liste erneut gesendet, gibt die Anfrage nach dem ersten Durchlauf deleted: 0 zurück.
Es wird nur die Anzahl der gelöschten Datensätze zurückgegeben, kein Bericht pro Element. Werte ohne Treffer werden stillschweigend übersprungen. Wenn Sie deleted mit der Anzahl der gesendeten Kennungen vergleichen möchten, senden Sie eine bereinigte Liste ohne Duplikate, da eine wiederholte Kennung nur einmal gezählt wird.
Für eine Löschung wird kein Webhook ausgelöst. Webhooks werden bei Änderungen am Benutzerstatus und an Benutzerdaten ausgelöst, nicht beim Löschen. Eine Integration, die ein Signal zur Löschung benötigt, muss die Löschung daher auf ihrer eigenen Seite erfassen.
Mit dem Benutzer verknüpfte Verifizierungssitzungen werden durch diesen Endpoint NICHT gelöscht. Sie bleiben bestehen, wobei ihre Verknüpfung mit dem Benutzer entfernt wird. Ihre Dokumente, Gesichter und Medien werden daher erst entfernt, wenn Sie die Sitzungen selbst löschen.
retain_face_embeddings (boolean, Standard false) und face_retention_days (1 bis 3650) sind Ihre ausdrückliche Entscheidung, pro gelöschter Person ein bildfreies biometrisches Template für die Duplikatserkennung für diese Anzahl von Tagen zu behalten. Über die Person wird sonst nichts behalten. Lassen Sie beide weg, um die Templates zusammen mit den Benutzern zu löschen. face_retention_days ohne retain_face_embeddings: true oder retain_face_embeddings: true ohne face_retention_days liefert 400 für face_retention_days.
Sofern Sie retain_face_embeddings nicht auf true setzen, werden zurückbehaltene biometrische Templates, die dem Benutzer zugeordnet sind, vollständig entfernt, bevor der Benutzer gelöscht wird. Kann ein Template nicht entfernt werden, weil ein biometrischer Speicher nicht verfügbar ist, liefert der Aufruf 503, es wird kein Benutzer der Anfrage gelöscht, und die Wiederholung der Anfrage schließt den Vorgang ab.

Daten in einem finalisierten regulatorischen Bericht

Ist eine ausgewählte Person Teil eines Falls mit einem finalisierten regulatorischen Bericht, gibt die gesamte Anfrage 409 zurück, und nichts wird gelöscht. Die Antwort verwendet code: in_filed_report und nennt jeden Bericht, sodass Sie ihn in der Console öffnen können:

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

Löschen Sie jeden Bericht mit Bericht löschen und wiederholen Sie dann dieselbe Anfrage. Die Person aus der Liste zu entfernen reicht nicht, solange eine andere ausgewählte Person noch in einem Bericht enthalten ist.

Eine bereits laufende Löschung

Eine Person wird jeweils nur durch eine Anfrage gelöscht. Löscht eine andere Anfrage noch eine der ausgewählten Personen, wartet diese Anfrage höchstens einige Sekunden und gibt dann 409 mit code: subject_deletion_in_progress zurück. Sie löscht nichts:

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

Wiederholen Sie dieselbe Anfrage, sobald die andere Löschung abgeschlossen ist. Eine Person, die sie bereits gelöscht hat, passt nicht mehr, sodass die Wiederholung nur noch löscht, was übrig ist.

Berechtigungen

Jeder aktive API-Schlüssel der Anwendung kann diesen Endpoint aufrufen. API-Schlüssel von Didit sind an die Anwendung gebunden, nicht an Rollen. Die Rollen und Berechtigungen der Console (delete:users und die übrigen) bestimmen, was eine Person in der Console tun darf, und werden für Anfragen an die Management API nicht ausgewertet. Steuern Sie, wer diesen Endpoint aufrufen darf, indem Sie steuern, wer den API-Schlüssel der Anwendung lesen darf.

Verwandte Seiten

Autorisierungen

x-api-key

string

header

erforderlich

Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese- oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde, der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als null. Siehe https://docs.didit.me/console/api-keys.

Body

application/json

Geben Sie vendor_data_list, didit_internal_id_list oder delete_all: true an. Die beiden Listen können kombiniert werden und sind ODER-verknüpft. Wenn delete_all auf true gesetzt ist, hat dies Vorrang und beide Listen werden ignoriert.

vendor_data_list

string[]

Ihre eigenen zu löschenden Kennungen, exakt so abgeglichen wie übermittelt.

didit_internal_id_list

string<uuid>[]

Interne Didit-Benutzer-IDs, die gelöscht werden sollen – die von den Create- und Get-Endpoints zurückgegebene didit_internal_id.

delete_all

boolean

Standard:false

Wenn true, werden alle Benutzer in der Anwendung gelöscht.

retain_face_embeddings

boolean

Standard:false

Ihre ausdrückliche Auswahl, ein bildfreies biometrisches Template jeder gelöschten Person zur Duplikaterkennung für face_retention_days aufzubewahren. Alles andere über die Person wird gelöscht. Lassen Sie es weg oder senden Sie false, um die Templates zusammen mit den Benutzern zu löschen. Wenn true, ist face_retention_days erforderlich.

face_retention_days

integer

Anzahl der Tage, die das biometrische Template ohne Bild aufbewahrt wird, wenn retain_face_embeddings true ist. Zusammen damit erforderlich und ohne dieses mit einem 400 für face_retention_days abgelehnt.

Erforderlicher Bereich: 1 <= x <= 3650

Beispiel:

365

Antwort

Benutzer gelöscht. Gibt die Anzahl der tatsächlich gelöschten Benutzer zurück.

deleted

integer

Anzahl der gelöschten Benutzer (schließt vendor_data-Werte aus, die mit nichts übereinstimmten).

Zuletzt geändert am 7. November 2026

​Überblick

​Wann Sie ihn verwenden

​Hinweise

​Daten in einem finalisierten regulatorischen Bericht

​Eine bereits laufende Löschung

​Berechtigungen

​Verwandte Seiten