Sessions und personenbezogene Daten löschen

So löschen Sie eine Verifizierungs-Session und alles, was sie erzeugt hat - und was die Löschung genau betrifft und was nicht. Die Löschung erfolgt sofort und ist unwiderruflich.

Verfasst vom Didit-Support · Aktualisiert am 31. August 2026

Sie können eine Verifizierungs-Session und alles, was sie erzeugt hat, jederzeit über die Business Console oder die API löschen. Die Löschung erfolgt sofort und kann nicht rückgängig gemacht werden.

#Eine Session über die Konsole löschen

1. Verifizierungen öffnen

   Gehen Sie in der Business Console zu Dashboard > Verifizierungen.

2. Die Session finden

   Suchen oder filtern Sie nach der Session, die Sie entfernen möchten.

3. Löschen

   Klicken Sie auf Löschen und bestätigen Sie.

12

1. Weitere Optionen enthält die Löschaktion für diese Session.
2. Prüfen Sie zuerst, ob Sie die richtige Session haben - die Löschung ist unwiderruflich.

#Eine Session über die API löschen

Rufen Sie den Lösch-Endpunkt mit der Session-ID auf:

curl -X DELETE https://verification.didit.me/v3/session/SESSION_ID/delete/ \
  -H "x-api-key: YOUR_API_KEY"

Ein erfolgreicher Aufruf gibt 204 No Content zurück. Ein 404 bedeutet, dass die Session bereits gelöscht ist oder die ID unbekannt ist. Das funktioniert sowohl für individuelle (KYC) als auch für geschäftliche (KYB) Verifizierungs-Sessions.

#Was gelöscht wird

Das Löschen einer Session entfernt die Session selbst sowie:

• ihre Entscheidung und alle extrahierten Daten.
• jeden zugehörigen Funktionsdatensatz - ID-Verifizierung, Registerabfragen, Dokumente, AML-Ergebnisse und mehr.
• alle gespeicherten Medien - Dokumentbilder, Videos, Porträts, Selfies und alle anderen mit der Session verknüpften Uploads.

Die Session verschwindet sofort aus Ihren Session-Listen und Entscheidungsabfragen, und alle vor der Löschung ausgestellten Medien-URLs lösen sich danach nicht mehr auf.

#Was die Löschung nicht betrifft

Ein paar Dinge werden getrennt behandelt und werden beim Löschen einer Session nicht entfernt:

• Sperrlisteneinträge, die aus der Session erstellt wurden, bleiben bestehen. Entfernen Sie sie bei Bedarf direkt aus der Sperrliste.
• Bereits ausgestellte Links für gehostete Abläufe für die Session werden nicht widerrufen.
• Bereits eingereihte Webhook-Zustellungen kommen trotzdem an. Für die Löschung selbst wird kein Webhook gesendet.
• Bereits für die Verifizierung ausgegebene Credits werden nicht erstattet.
• Der Nutzer oder das Unternehmen, zu dem die Session gehörte, wird nicht gelöscht - das Löschen einer Session entfernt nur diese eine Verifizierung.
• Audit-Protokolleinträge, die die API-Aktivität aufzeichnen, sind Aktivitätsdatensätze, die nach ihrem eigenen 365-Tage-Zeitplan aufbewahrt werden. Siehe Audit-Protokolle nutzen.

#Die Löschung wirkt sich auf künftige Duplikaterkennung aus

Die Duplikaterkennung funktioniert, indem ein neues Gesicht mit den Daten verglichen wird, die Sie noch vorhalten. Sobald eine Session gelöscht ist, ist das darin enthaltene Gesicht nicht mehr vorhanden, um damit zu vergleichen - verifiziert sich dieselbe Person also später erneut, wird dieser Versuch nicht als Duplikat der gelöschten Session erkannt.

Das ist der eigentliche Zielkonflikt zwischen Datenminimierung und Betrugserkennung, und er wird besser bewusst entschieden als später entdeckt. Siehe doppelte Konten und Gesichtssuche.

#Viele Sessions auf einmal löschen

Um mehrere Sessions in einem Aufruf statt einzeln zu entfernen, nutzen Sie den Massenlöschungs-Endpunkt. Das Anfrageformat finden Sie in der Delete-Session-API.

Wenn Sie einen großen historischen Bestand bereinigen müssen - eine Testphase, eine stillgelegte Anwendung - und der Massenlöschungs-Endpunkt in diesem Umfang nicht praktikabel ist, fragen Sie den Support, statt ein Skript mit hoher Nebenläufigkeit gegen die API laufen zu lassen, was an Rate Limits stoßen wird.

#Aufbewahrungsfenster erledigen das automatisch

Statt Session für Session zu löschen, legen Sie ein Aufbewahrungsfenster fest und lassen Sie es wirken. Konfigurieren Sie es unter Business Console → App Settings → Data retention: von 1 Monat bis 10 Jahre, oder unbegrenzt. Die Richtlinie gilt pro Anwendung, sodass unterschiedliche Produkte unterschiedliche Fenster tragen können, und sie gilt gleichermaßen für zukünftige wie für bestehende Sessions.

#Process-and-Purge

Für maximale Datenminimierung halten Sie die Daten gar nicht erst vor:

1. Die Session erstellen

   Ihr Backend ruft wie gewohnt die Create-Session-API auf.

2. Die Prüfungen laufen lassen

   Identität, Liveness, AML und alles andere, was Ihr Workflow konfiguriert.

3. Den Webhook empfangen

   Sie erhalten den Status, die Session-ID, Ihre vendor_data und die vollständigen Verifizierungsdaten.

4. Nur das behalten, was Sie brauchen

   Speichern Sie das Minimum, das Ihre eigenen Unterlagen erfordern - oft nur den Status und Ihre eigene Referenz, plus das PDF, falls Sie den Nachweis benötigen.

5. Die Session löschen

   Rufen Sie den Lösch-Endpunkt für diese Session-ID auf.

Das ist die stärkste verfügbare Haltung, und es lohnt sich, sie in Betracht zu ziehen, wenn Ihre Verpflichtung darin besteht, den Nachweis selbst vorzuhalten, statt sich darauf zu verlassen, dass ein Anbieter ihn vorhält.

#Wenn Ihre eigene Verpflichtung Sie zur Aufbewahrung von Unterlagen zwingt

Manche regulierten Unternehmen haben eine gesetzliche Aufbewahrungspflicht, die länger läuft, als sie es einem Auftragsverarbeiter überlassen möchten. Um beides zu erfüllen, exportieren Sie den Nachweis zum Zeitpunkt der Entscheidung und bewahren Sie ihn in Ihren eigenen Systemen unter Ihrer eigenen Kontrolle auf, und lassen Sie dann ein kurzes Aufbewahrungsfenster hier die Kopie erledigen.

Zu entscheiden, worin Ihre Verpflichtung tatsächlich besteht und für wie lange, ist eine rechtliche und Compliance-Entscheidung Ihres Teams. Leiten Sie sie nicht aus einer Hilfeseite ab - entscheiden Sie sie, und konfigurieren Sie dann die Aufbewahrung und Ihre eigene Archivierung entsprechend.