> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.
# Sitzung löschen API: DSGVO-Recht auf Vergessenwerden
> Löschen Sie mit Didit KYC- oder KYB-Sitzungen samt Daten inklusive Gesichts-Embedding. Biometrische Templates können optional behalten werden.
Prompt zum Löschen von Sitzungen
Prompt in die Zwischenablage kopieren
\
\`Delete a single Didit verification session and all of its data, and control what happens to the face biometric data.
Endpoint:
DELETE https://verification.didit.me/v3/session/{session_id}/delete/
Authentication:
Use the x-api-key header with your Didit API key. Privilege: delete:sessions.
Path parameter:
\- session_id (UUID) — works for both User Verification (KYC) and Business Verification (KYB) sessions. Didit resolves the id against both session types.
Optional JSON body (send Content-Type: application/json; omit the body entirely for the default behavior):
\- retain_face_embeddings (boolean | null) — override the application's face_retention_policy for this deletion. true keeps an image-free biometric template anchored to the session's User; false deletes the face embedding with the session; omit or null to follow the application policy.
\- face_retention_days (integer 1-3650) — finite retention duration for the template. Required when retaining unless the application already sets face_retention_days.
\- face_retention_deadline (ISO 8601 datetime, future) — optional hard expiry. The template expires at the earliest of face_retention_days, the application's data-retention window, and this deadline.
\- deletion_instruction ("operational_session_delete" default | "privacy_erasure") — privacy_erasure purges every retained biometric template for the session's User and never retains a new one, regardless of the application policy. Combining privacy_erasure with retain_face_embeddings: true is rejected with 400.
\- instruction_id (string, max 255) — your own durable reference for this deletion instruction (for example your erasure-ticket id). Stored on the audit trail and on any retained template.
curl examples:
Default (follow the application policy; delete_with_session unless you opted in):
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: "
Delete the session but keep an image-free biometric template for 365 days:
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{"retain_face_embeddings": true, "face_retention_days": 365}'
Right-to-erasure request (delete the session AND purge every retained template for that person):
curl -X DELETE https://verification.didit.me/v3/session//delete/ \
-H "x-api-key: " \
-H "Content-Type: application/json" \
-d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}'
Response: 200 OK with a JSON body once the deletion has completed (this endpoint no longer returns 204):
\{
"session_id": "",
"session_number": 1024,
"face_retention_outcome": "deleted" | "retained_with_user" | "none" | "ineligible_no_vendor_user",
"biometric_template_uuid": "" | null,
"biometric_template_expires_at": "" | null,
"deleted_child_verifications": 0
}
\- deleted: the session and its face embedding are deleted (default behavior).
\- retained_with_user: the session is deleted; an image-free biometric template with the returned biometric_template_uuid stays anchored to the User until biometric_template_expires_at, User deletion, privacy erasure, or explicit purge. Manage it with GET/DELETE /v3/biometric-templates/{uuid}/.
\- none: the session had no face embedding (for example a KYB session or a document-only KYC session).
\- ineligible_no_vendor_user: retention was requested but the session has no linked User (no vendor_data), so nothing can anchor the template. The session and its embedding are deleted.
\- biometric_template_expires_at: when the retained template is deleted; null when no template is retained.
\- deleted_child_verifications: for a KYB session, how many verifications it created (its key people's KYC sessions and its corporate owners' KYB sessions, recursively) were deleted with it. Always 0 for a KYC session.
Behavior:
\- The session and every verification attempt it holds are deleted, including results a resubmission replaced: the decision, the extracted data, the associated feature records (ID verification, registry checks, documents, AML, IP, etc.), its reviews and activity log, and all stored files (document images, videos, portraits, selfies, POA documents, extra uploads, and E-signature documents, signed PDFs, evidence PDFs and signature images).
\- A KYB session is deleted together with the verifications it created for its key people and corporate owners. A verification it only links to (for example a reused, already approved KYC) is not deleted.
\- The session disappears immediately from /v3/sessions/ and /v3/session/{id}/decision/, and media URLs issued before the call stop resolving.
\- Webhook deliveries still queued for the session, and their retries, are dropped. Webhooks already delivered are not affected.
\- Ongoing AML monitoring and KYB registry monitoring started by the deleted verifications stop.
\- A retained biometric template never contains the face image, liveness video, document data, extracted identity fields, the decision, or the deleted session's id. It is biometric data, tenant-scoped, used only for your duplicate-face, multi-account, biometric-authentication, and list matching, and it is never used for model training or cross-customer fraud processing.
\- Share tokens issued for the session are NOT revoked, but there is nothing left for them to import: an import with one returns 400 {"share_token": ["Original session does not exist."]}.
\- Blocklist entries created from the session are NOT removed; manage those with the Lists endpoints.
\- Credits already consumed by the verification are NOT refunded.
\- The parent User or Business entity is NOT deleted; use POST /v3/users/delete/ or POST /v3/businesses/delete/ for those. Deleting the User also purges its retained biometric templates. If the User's profile portrait came from this session, the portrait is removed.
\- No webhook fires for the deletion itself.
Idempotency:
Idempotent in effect: the second call to the same session returns 404 because the session no longer exists. Deletion is permanent and cannot be undone.
Failure modes:
\- 400: {"retain_face_embeddings": ["Privacy erasure cannot retain biometric templates."]} or {"detail": "A finite biometric-template retention duration is required."} (retention requested without face_retention_days on the request or the application). Nothing is deleted.
\- 403: {"detail": "You do not have permission to perform this action."} when the key lacks delete:sessions.
\- 404: {"detail": "Not found."} when the session does not exist (or was already deleted).
\- 409: {"detail": "...", "code": "in_filed_report", "reports": [{"uuid": "...", "report_number": "SAR-0001", "report_type": "SAR", "case_uuid": "..."}]} when the session is part of a finalized regulatory report. Nothing is deleted. Delete the reports, then repeat the request.
\- 503: {"detail": "The session could not be deleted because a storage service or a monitoring provider is unavailable. The session is still in place; repeat the request to finish deleting it."} or {"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."} The session is still in place; repeat the same request until it returns 200. Some of its stored files or its face embedding may already be deleted. Retries converge on a single template.
Bulk delete:
For many KYC sessions at once, use POST /v3/sessions/delete/ with body {"session_numbers": ["1001", "1002"]} or {"delete_all": true}; it accepts the same retention and instruction fields. Up to 20 matching sessions return 200 with a per-session outcome; more return 202 with a job to poll at GET /v3/sessions/delete/{job_id}/.
Migration note:
Until this release the endpoint returned 204 No Content. It now returns 200 OK with the JSON body above. Update clients that assert on 204. The default deletion behavior is unchanged: existing applications stay on delete_with_session until you explicitly change the policy.
When to call:
\- Customer requests data erasure (GDPR Article 17): use deletion_instruction: "privacy_erasure".
\- Operational clean-up after approval while keeping duplicate detection: retain_face_embeddings: true with a finite face_retention_days.
\- Cleaning up test sessions from a staging application.
\- After exporting a decision PDF for long-term archival outside Didit.
For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`
\
Einfügen in
## KYC- und KYB-UnterstützungFunktioniert sowohl für Sitzungen der **Benutzerverifizierung (KYC)** als auch der **Unternehmensverifizierung (KYB)**. Die `session_id` wird für beide Sitzungstypen aufgelöst; für beide gilt dasselbe Löschverhalten. Die Aufbewahrung biometrischer Templates gilt nur für KYC-Sitzungen, da nur KYC-Sitzungen ein Gesichts-Embedding enthalten.## Verhalten- Die Sitzung wird zusammen mit jedem darin enthaltenen Verifizierungsversuch gelöscht, einschließlich der Ergebnisse, die durch eine erneute Einreichung ersetzt wurden: ihre Entscheidung, ihre extrahierten Daten, ihre zugehörigen Funktionsdatensätze (Ausweisverifizierungen, Registerprüfungen, Dokumente, AML, IP-Analyse usw.), ihre Prüfungen und das Aktivitätsprotokoll sowie alle ihre gespeicherten Dateien.
- Das Löschen einer Sitzung der **Unternehmensverifizierung (KYB)** löscht auch die Verifizierungen, die sie für ihre Schlüsselpersonen (KYC) und ihre Unternehmenseigentümer (KYB) erstellt hat, und zwar rekursiv. Die Antwort gibt in `deleted_child_verifications` an, wie viele dies sind. Eine Verifizierung, auf die sie lediglich verlinkt, wie etwa ein bestehendes, genehmigtes KYC, das wiederverwendet wurde, wird nicht gelöscht.
- E-Signatur-Daten werden mitgelöscht: die zu unterzeichnenden Dokumente und ihre ursprünglichen Word-Dateien, die signierten PDFs, die Nachweis-PDFs, die Signaturbilder und jeder Feldwert. Ihre Download-Pfade geben `404` zurück.
- Die Sitzung verschwindet sofort aus Listen- und Entscheidungsantworten, und Medien-URLs, die vor dem Aufruf ausgestellt wurden, lassen sich nicht mehr auflösen.
- Webhook-Zustellungen, die sich noch in der Warteschlange für die Sitzung befinden, sowie deren Wiederholungsversuche werden verworfen.
- Die laufende AML-Überwachung und die KYB-Registerüberwachung, die durch die gelöschten Verifizierungen gestartet wurden, werden beendet.
- Die Löschung ist dauerhaft und unwiderruflich. Es gibt keinen Wiederherstellungs-Endpoint; exportieren Sie daher alles, was Sie benötigen, wie etwa ein Entscheidungs-PDF, bevor Sie ihn aufrufen.
- Die Antwort ist `200 OK` und wird gesendet, sobald die Löschung abgeschlossen ist, mit einem JSON-Body, der angibt, was mit den biometrischen Gesichtsdaten der Sitzung geschehen ist. Siehe [Migration](#migration-von-204-antworten), falls Ihr Client noch `204` erwartet.## Daten in einem finalisierten aufsichtsrechtlichen BerichtIst die Sitzung Teil eines Falls mit einem finalisierten aufsichtsrechtlichen Bericht, gibt die Anfrage `409` zurück und es wird nichts gelöscht. Die Antwort verwendet `code: in_filed_report` und nennt jeden Bericht:```json theme={null}
{
"detail": "This session is part of a finalized 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](https://docs.didit.me/de/management-api/regulatory-reports/delete.md) und wiederholen Sie anschließend den Löschvorgang. Das Löschen des Berichts löscht nicht die Sitzung; die Sitzung bleibt bestehen, bis Sie diesen Endpoint erneut aufrufen.## Biometrische Gesichtsdaten: löschen oder aufbewahrenJede KYC-Sitzung mit einem Liveness-Selfie enthält ein Gesichts-Embedding, das die [Gesichtssuche 1:N](https://docs.didit.me/de/core-technology/face-search/overview.md) und die Duplikaterkennung unterstützt. Standardmäßig wird dieses Embedding zusammen mit der Sitzung gelöscht (`face_retention_policy: delete_with_session`), sodass sich eine Person, deren Sitzung Sie gelöscht haben, erneut verifizieren kann, ohne als Duplikat markiert zu werden.Anwendungen, bei denen die Duplikaterkennung auch nach dem Löschen der Sitzung erhalten bleiben muss, können die **Aufbewahrung biometrischer Templates** aktivieren. Didit löscht dann wie gewohnt die Sitzung und alle zugehörigen Daten und behält ein separat verwaltetes, bildfreies biometrisches Template bei, das an den [Benutzer](https://docs.didit.me/de/entities/users/overview.md) der Sitzung gebunden ist.> [!WARNING]
>
> Ein aufbewahrtes biometrisches Template stellt biometrische Daten dar. Es ist weder anonym noch flüchtig und wird nicht zusammen mit der Sitzung gelöscht. Es bleibt bis zu seinem geplanten Ablauf, einer früheren Frist nach geltendem Recht, der Löschung des Benutzers, einer datenschutzrechtlichen Löschanfrage oder einer expliziten Bereinigung bestehen. Aktivieren Sie die Aufbewahrung nur, wenn die Weisung des Verantwortlichen und Ihre Datenschutzerklärung dies abdecken.Was ein aufbewahrtes Template enthält und was nicht:| Aufbewahrt | Niemals aufbewahrt |
| - | - |
| Das für den Abgleich verwendete numerische biometrische Template | Das Gesichtsbild, das Liveness-Video, Dokumentbilder, Portraitausschnitte und alle anderen Medien |
| Eine neue zufällige Template-ID und eine opake `provenance_reference` | ID, Nummer, Entscheidung, extrahierte Identitätsfelder oder Feature-Payloads der gelöschten Sitzung |
| Der zugehörige Benutzer (`vendor_user_uuid`, aktuelle `vendor_data`) | Sperrlisten-Status, frühere Übereinstimmungen, Betrugs-Labels oder organisationsübergreifende Identitätsansprüche |
| Aufbewahrungs-Metadaten: `retained_at`, `expires_at`, Richtlinie, Überschreibung, Anweisungsklasse, `instruction_id` und die ID des handelnden Prinzipals | E-Mail-Adressen der Akteure |Die Aufbewahrung wird an drei Stellen konfiguriert, von der allgemeinsten bis zur spezifischsten:1) **Anwendungsrichtlinie** in **Business Console → App Settings → Data retention** oder über `PATCH /v3/webhook/` (`face_retention_policy`, `face_retention_days`). Siehe [Datenaufbewahrung](https://docs.didit.me/de/console/data-retention.md#aufbewahrung-biometrischer-templates).
2) **Überschreibung pro Aufruf** mit `retain_face_embeddings` an diesem Endpoint und bei [Sitzungen stapelweise löschen](https://docs.didit.me/de/management-api/sessions/batch-delete.md).
3) **Anweisungsklasse** mit `deletion_instruction`. Eine `privacy_erasure`-Anweisung hat immer Vorrang: Sie bereinigt jedes aufbewahrte Template für diesen Benutzer und behält niemals ein neues auf.### Request-BodyAlle Felder sind optional. Lassen Sie den Body weg, um der Anwendungsrichtlinie zu folgen.| Feld | Typ | Beschreibung |
| - | - | - |
| `retain_face_embeddings` | boolean oder null | Überschreibt die Anwendungsrichtlinie für diesen Löschvorgang. `true` bewahrt ein Template auf, `false` löscht das Embedding mit der Sitzung, `null` oder weggelassen folgt der Richtlinie. |
| `face_retention_days` | integer (1-3650) | Befristete Aufbewahrungsdauer für das Template. Erforderlich, wenn ein Template aufbewahrt wird, es sei denn, die Anwendung legt `face_retention_days` bereits fest. |
| `face_retention_deadline` | datetime (ISO 8601) | Optionaler fester Ablaufzeitpunkt. Muss in der Zukunft liegen. |
| `deletion_instruction` | `operational_session_delete` (Standard) oder `privacy_erasure` | Die Klasse der Anweisung, die Sie erteilen. `privacy_erasure` bereinigt jedes aufbewahrte Template für den Benutzer der Sitzung vor dem Löschen der Sitzung und kann nicht mit `retain_face_embeddings: true` kombiniert werden. |
| `instruction_id` | string (max 255) | Ihre dauerhafte Referenz für diese Anweisung, beispielsweise Ihre Lösch-Ticket-ID. Wird im Audit-Trail und auf jedem aufbewahrten Template erfasst. Wenn Sie sie weglassen, generiert Didit eine ID, die in den Template-Details einsehbar ist. |### Antwort```json theme={null}
{
"session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
"session_number": 1024,
"face_retention_outcome": "retained_with_user",
"biometric_template_uuid": "9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b",
"biometric_template_expires_at": "2027-10-09T10:15:00Z",
"deleted_child_verifications": 0
}
```| Feld | Beschreibung |
| - | - |
| `session_id` | Die gelöschte Sitzung. |
| `session_number` | Die Nummer der gelöschten Sitzung. |
| `face_retention_outcome` | Was mit den biometrischen Gesichtsdaten der Sitzung geschehen ist. Siehe Tabelle unten. |
| `biometric_template_uuid` | ID des aufbewahrten biometrischen Templates, wenn `face_retention_outcome` gleich `retained_with_user` ist; andernfalls `null`. |
| `biometric_template_expires_at` | Wann das aufbewahrte biometrische Template gelöscht wird; `null`, wenn kein Template aufbewahrt wird. |
| `deleted_child_verifications` | Bei einer KYB-Sitzung die Anzahl der von ihr erstellten Verifizierungen (die KYC-Sitzungen ihrer Schlüsselpersonen und die KYB-Sitzungen ihrer Unternehmenseigentümer, rekursiv), die mit ihr gelöscht wurden. Bei einer KYC-Sitzung immer `0`. || `face_retention_outcome` | Bedeutung |
| - | - |
| `deleted` | Die Sitzung und ihr Gesichts-Embedding werden gelöscht. Standardverhalten. |
| `retained_with_user` | Die Sitzung wird gelöscht. Ein bildfreies biometrisches Template bleibt an den Benutzer gebunden; seine ID lautet `biometric_template_uuid`. Verwalten Sie es mit der [Biometric Templates API](https://docs.didit.me/de/management-api/biometric-templates/overview.md). |
| `none` | Die Sitzung enthielt kein Gesichts-Embedding, das gelöscht oder aufbewahrt werden konnte (z. B. eine KYB-Sitzung oder eine KYC-Sitzung ohne Liveness-Selfie). |
| `ineligible_no_vendor_user` | Die Aufbewahrung wurde angefordert, die Sitzung ist jedoch nicht mit einem Benutzer verknüpft (sie wurde ohne `vendor_data` erstellt), sodass kein Template verankert werden kann. Die Sitzung und ihr Embedding werden gelöscht. Das Ergebnis der Nichtberechtigung wird im Audit-Trail erfasst. |Die Antwort bestätigt, dass Didit Ihre Löschanweisung akzeptiert und angewendet hat. Sie stellt kein Löschzertifikat dar: Bewahren Sie die `instruction_id` in Ihrem eigenen Löschprotokoll auf, um den Audit-Trail später abgleichen zu können.### Aufbewahrungsdauer und AblaufJedes aufbewahrte Template hat einen zeitlich begrenzten Ablaufzeitpunkt in `expires_at`. Didit setzt diesen auf den frühesten der folgenden Zeitpunkte:1) `face_retention_days` aus der Anfrage oder `face_retention_days` der Anwendung, wenn die Anfrage diesen Wert weglässt;
2) das allgemeine Datenaufbewahrungsfenster der Anwendung, sofern eines konfiguriert ist;
3) `face_retention_deadline` aus der Anfrage, sofern angegeben.Eine Anfrage, die ein Template ohne endliche Dauer aufbewahren würde, wird mit `400` abgewiesen und es wird nichts gelöscht. Aufbewahrte Templates dürfen die früheste geltende Kundenanweisung, das Zweckende, den konfigurierten Ablauf, die auf die betroffene Person bezogene Löschanweisung oder die gesetzliche Frist für biometrische Daten nicht überdauern. Sie sind dafür verantwortlich, eine Dauer zu wählen, die den für Ihre Benutzer geltenden Gesetzen entspricht; wählen Sie eine kürzere Dauer, wann immer eine anwendbare Vorschrift dies erfordert.### Datenschutzrechtliche LöschungSenden Sie `deletion_instruction: "privacy_erasure"`, wenn Sie einer Anfrage einer betroffenen Person nachkommen. Didit löscht jedes gespeicherte biometrische Template, das an den Benutzer der Sitzung gebunden ist, und löscht anschließend die Sitzung sowie deren Embedding. Die Aufbewahrungsrichtlinie der Anwendung kann eine Anweisung zur Datenschutzlöschung nicht überschreiben, und `retain_face_embeddings: true` wird mit `400` abgelehnt.Das Löschen des Benutzers mit [Batch Delete Users](https://docs.didit.me/de/management-api/users/delete.md) löscht ebenfalls seine gespeicherten Templates.## Was nicht betroffen istDas Löschen einer Sitzung bereinigt diese Daten nicht automatisch. Wenn Sie eine Anfrage auf Löschung bearbeiten, müssen Sie diese separat berücksichtigen.- **Sperrlisteneinträge**, die aus der Sitzung erstellt wurden (Gesicht oder Dokument), bleiben bestehen. Entfernen Sie diese aus der [Sperrliste](https://docs.didit.me/de/entities/users/blocklist.md). Ein Gesichts-Sperrlisteneintrag behält seinen eigenen biometrischen Eintrag, unabhängig von jedem gespeicherten Template.
- Bereits für die Sitzung ausgestellte **Share-Token** werden nicht widerrufen, aber es gibt für sie nichts mehr zu importieren: Ein [Import](https://docs.didit.me/de/sessions-api/share-session/import.md) mit einem solchen Token gibt `400` mit `{"share_token": ["Original session does not exist."]}` zurück.
- Bereits für die Sitzung **zugestellte Webhooks** sind nicht betroffen. Zustellungen, die sich noch in der Warteschlange befinden, sowie deren Wiederholungsversuche werden verworfen. Für die Löschung selbst wird kein Webhook ausgelöst.
- Bereits durch die Verifizierung **verbrauchte Credits** werden nicht zurückerstattet.
- **Unterzeichnete Kopien, die bereits per E-Mail** durch einen E-Signatur-Schritt an einen Unterzeichner gesendet wurden, verbleiben im Postfach des Unterzeichners und sind nicht betroffen.
- Die übergeordnete Entität **Benutzer** oder **Unternehmen** wird nicht gelöscht. Verwenden Sie dafür [Delete Users](https://docs.didit.me/de/management-api/users/delete.md) oder [Delete Businesses](https://docs.didit.me/de/management-api/businesses/delete.md). Wenn das Profilporträt des Benutzers aus der gelöschten Sitzung stammte, wird das Porträt entfernt.
- Ein **gespeichertes biometrisches Template** (nur, wenn Sie sich dafür entschieden haben) bleibt bestehen, bis es abläuft oder Sie es löschen. Löschen Sie es mit der [Biometric Templates API](https://docs.didit.me/de/management-api/biometric-templates/purge.md), indem Sie den Benutzer löschen oder indem Sie die Löschung einer anderen Sitzung desselben Benutzers mit `deletion_instruction: "privacy_erasure"` wiederholen.## Beispiele> [tab] Standard (Anwendungsrichtlinie)
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY"
> ```
>
> Antwort bei einer Anwendung, die sich nicht dafür entschieden hat:
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "deleted",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Ein biometrisches Template beibehalten
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"retain_face_embeddings": true, "face_retention_days": 365, "instruction_id": "cleanup-2026-08-0142"}'
> ```
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "retained_with_user",
> "biometric_template_uuid": "9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b",
> "biometric_template_expires_at": "2027-10-09T10:15:00Z",
> "deleted_child_verifications": 0
> }
> ```> [tab] Löschung bei einer Opt-in-Anwendung erzwingen
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"retain_face_embeddings": false}'
> ```
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "deleted",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Datenschutzlöschung
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/4c5c7f3a-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}'
> ```
>
> Jedes gespeicherte Template für den Benutzer der Sitzung wird zuerst bereinigt, danach wird die Sitzung gelöscht:
>
> ```json theme={null}
> {
> "session_id": "4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02",
> "session_number": 1024,
> "face_retention_outcome": "deleted",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Sitzung ohne einen Benutzer
>
> Eine ohne `vendor_data` erstellte Sitzung hat keinen Benutzer, an den ein Template gebunden werden kann:
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/7a1e9c2d-.../delete/ \
> -H "x-api-key: YOUR_API_KEY" \
> -H "Content-Type: application/json" \
> -d '{"retain_face_embeddings": true, "face_retention_days": 365}'
> ```
>
> ```json theme={null}
> {
> "session_id": "7a1e9c2d-5f4b-4c3a-8e2d-1b0a9f8e7d6c",
> "session_number": 1031,
> "face_retention_outcome": "ineligible_no_vendor_user",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 0
> }
> ```> [tab] Sitzung zur Unternehmensverifizierung (KYB)
>
> ```bash theme={null}
> curl -X DELETE https://verification.didit.me/v3/session/bs-01HJX1.../delete/ \
> -H "x-api-key: YOUR_API_KEY"
> ```
>
> Die Unternehmensverifizierung wird zusammen mit den drei Verifizierungen gelöscht, die für ihre Schlüsselpersonen erstellt wurden:
>
> ```json theme={null}
> {
> "session_id": "0f3c9b7e-2d1a-4e5f-8c6b-7a9d8e1f2c3b",
> "session_number": 88,
> "face_retention_outcome": "none",
> "biometric_template_uuid": null,
> "biometric_template_expires_at": null,
> "deleted_child_verifications": 3
> }
> ```## Fehler| Status | Wann | Inhalt |
| - | - | - |
| `400` | `privacy_erasure` kombiniert mit `retain_face_embeddings: true` | `{"retain_face_embeddings": ["Privacy erasure cannot retain biometric templates."]}` |
| `400` | Aufbewahrung ohne begrenzte Dauer in der Anfrage oder der Anwendung angefordert | `{"detail": "A finite biometric-template retention duration is required."}` |
| `403` | Die Zugangsdaten verfügen nicht über `delete:sessions` oder die Sitzung gehört nicht zu ihnen | `{"detail": "You do not have permission to perform this action."}` |
| `404` | Unbekannte oder bereits gelöschte Sitzung | `{"detail": "Not found."}` |
| `503` | Ein Speicherdienst oder ein Überwachungsanbieter war während des Löschens der Sitzung nicht verfügbar. | `{"detail": "The session could not be deleted because a storage service or a monitoring provider is unavailable. The session is still in place; repeat the request to finish deleting it."}` |
| `503` | Ein biometrischer Speicher war beim Speichern oder Löschen eines Templates nicht verfügbar. Wiederholungsversuche konvergieren auf ein einzelnes Template. | `{"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."}` |Bei `400` wird nichts gelöscht. Bei `503` bleibt die Sitzung bestehen: Wiederholen Sie dieselbe Anfrage, bis sie `200` zurückgibt. Einige ihrer gespeicherten Dateien oder ihr Gesichts-Embedding sind möglicherweise bereits gelöscht, verlassen Sie sich daher nach einem `503` nicht mehr darauf.## BerechtigungErfordert `delete:sessions`. Dieselbe Berechtigung gilt sowohl für Sitzungen der Benutzerverifizierung (KYC) als auch der Unternehmensverifizierung (KYB) sowie für das Überschreiben der Aufbewahrung.## Batch-LöschungFür Massenoperationen auf KYC-Sitzungen verwenden Sie `POST /v3/sessions/delete/`. Dieser Endpoint akzeptiert dieselben Aufbewahrungs- und Anweisungsfelder. Bis zu 20 übereinstimmende Sitzungen werden in der Anfrage mit einem Ergebnis pro Sitzung gelöscht; darüber hinausgehende werden als [Löschauftrag](https://docs.didit.me/de/management-api/sessions/get-deletion-job.md) ausgeführt. Siehe [Batch Delete Sessions](https://docs.didit.me/de/management-api/sessions/batch-delete.md).## Migration von 204-AntwortenBis zu dieser Version gab der Endpoint `204 No Content` zurück. Er gibt jetzt `200 OK` mit dem oben dokumentierten JSON-Body zurück, sodass jede Löschung ihr `face_retention_outcome` meldet. Aktualisieren Sie Clients, die auf `204` prüfen.Das Standardverhalten bleibt unverändert: Bestehende Anwendungen verbleiben auf `delete_with_session`, und keine Migration aktiviert die Aufbewahrung automatisch für Sie. Aktivieren Sie sie explizit in der Konsole oder über `PATCH /v3/webhook/`.## Ähnliche Themen- [Biometrische Templates](https://docs.didit.me/de/management-api/biometric-templates/overview.md)
- [Datenaufbewahrung](https://docs.didit.me/de/console/data-retention.md)
- [Sitzungsübersicht](https://docs.didit.me/de/sessions-api/overview.md)
## OpenAPI
````yaml de/openapi-25.json DELETE /v3/session/{sessionId}/delete/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API für Ausweisverifizierung. Authentifizierung über den x-api-key-Header.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/session/{sessionId}/delete/:
delete:
tags:
- Sessions
summary: Eine Verifizierungssitzung (KYC oder KYB) löschen
description: >-
Löschen Sie eine einzelne Verifizierungssitzung, Benutzerverifizierung
(KYC) oder Unternehmensverifizierung (KYB), anhand ihrer `session_id`.
Die ID wird zuerst mit KYC-Sitzungen abgeglichen, danach mit
KYB-Sitzungen, sodass beide Arten über diese eine URL gelöscht werden.
**Was gelöscht wird:**
- Die Sitzung und jeder darin enthaltene Verifizierungsversuch,
einschließlich der Ergebnisse, die durch ein erneutes Einreichen ersetzt
wurden: die Entscheidung, extrahierte Daten, alle zugehörigen
Funktionsdatensätze (Ausweisverifizierung, Gesicht, Liveness,
Gesichtsabgleich, AML, Registerprüfungen, IP-Analyse usw.), ihre
Prüfungen und ihr Aktivitätslog.
- Alle gespeicherten Dateien, die zur Sitzung gehören: Fotos der
Dokumentenvorder-/-rückseite (vollständige, zugeschnittene und aus
Datenschutzgründen unkenntlich gemachte Varianten), Videos der
Dokumentenerfassung, Porträtausschnitte, NFC-Chip-Porträt- und
Signaturbilder, Gesichtsreferenzbilder, Liveness-Videos,
Gesichtsabgleich-Quell-/Zielbilder, Adressnachweis-Dokumente und alle
zusätzlich hochgeladenen Dateien (KYC); hochgeladene
Unternehmensdokumente und zusätzliche Dateien (KYB).
E-Signatur-Dokumente, signierte PDFs, Nachweis-PDFs und Signaturbilder
(KYC und KYB): deren Download-Pfade funktionieren nicht mehr. Zuvor
ausgestellte Medien-URLs (`https:///...`) lassen sich nicht
mehr auflösen.
- Die Gesichtsdaten der Sitzung. Das Gesichts-Embedding der Sitzung wird
ebenfalls gelöscht, es sei denn, Sie entscheiden sich dafür, ein
bildfreies Template beizubehalten (siehe **Biometrische
Gesichtsdaten**).
- Webhook-Zustellungen, die sich für die Sitzung noch in der
Warteschlange befinden, und deren Wiederholungsversuche. Bereits
zugestellte Webhooks sind nicht betroffen.
- Bei einer Sitzung zur Unternehmensverifizierung (KYB): die
Verifizierungen, die sie für ihre Schlüsselpersonen (KYC) und ihre
Unternehmenseigentümer (KYB) rekursiv erstellt hat, gemeldet als
`deleted_child_verifications`. Eine Verifizierung, auf die sie lediglich
verlinkt, wie etwa ein bestehendes genehmigtes KYC, das sie
wiederverwendet hat, wird nicht gelöscht.
Die Sitzung verschwindet sofort aus jedem Lese-Endpoint: `GET
/v3/session/{sessionId}/decision/` gibt `404` zurück und `GET
/v3/sessions/` führt sie nicht mehr auf. Die durch die gelöschten
Verifizierungen gestartete laufende AML-Überwachung und
KYB-Registerüberwachung werden beendet.
**Was nicht betroffen ist:** Aus dieser Sitzung erstellte
Sperrlisten-Einträge (Gesicht oder Dokument) werden **nicht** entfernt;
verwalten Sie diese über die Sperrlisten-Endpoints. Für die Sitzung
ausgestellte Share-Token werden nicht widerrufen, aber es gibt nichts
mehr, was sie importieren könnten: Ein Import mit einem solchen Token
gibt `400` mit `{"share_token": ["Original session does not exist."]}`
zurück. Bereits verbrauchte Credits werden **nicht** zurückerstattet.
Die übergeordnete Benutzer- oder Unternehmens-Entität wird **nicht**
gelöscht; verwenden Sie dafür `POST /v3/users/delete/` oder `POST
/v3/businesses/delete/`. Wenn das Profilporträt des Benutzers aus dieser
Sitzung stammt, wird das Porträt mit ihr entfernt.
**Biometrische Gesichtsdaten:** Standardmäßig wird das
Gesichts-Embedding der Sitzung zusammen mit der Sitzung gelöscht
(`face_retention_outcome: deleted`). Eine Anwendung, die sich für die
Aufbewahrung biometrischer Templates entschieden hat
(`face_retention_policy: retain_until_user_deleted` bei `PATCH
/v3/webhook/`), oder eine Anfrage mit `retain_face_embeddings: true`
behält ein separat verwaltetes, bildfreies biometrisches Template bei,
das an den Benutzer der Sitzung gebunden ist (`retained_with_user`),
sodass Duplikaterkennung, Gesichtssuche und biometrische
Authentifizierung weiterhin funktionieren. Das Template enthält niemals
das Gesichtsbild, Medien, Identitätsfelder, die Entscheidung oder die ID
der gelöschten Sitzung; es handelt sich um biometrische Daten, die bei
`biometric_template_expires_at` gelöscht werden, oder früher bei
Benutzerlöschung, datenschutzrechtlicher Löschung oder einer expliziten
Bereinigung über `/v3/biometric-templates/`. Eine Sitzung ohne
verknüpften Benutzer kann kein Template beibehalten
(`ineligible_no_vendor_user`). Senden Sie `deletion_instruction:
privacy_erasure` für Betroffenenanfragen: Dies bereinigt jedes
beibehaltene Template für diesen Benutzer und behält niemals ein neues
bei.
**Unwiderruflich:** Die Löschung ist dauerhaft und es gibt keinen
Wiederherstellungs-Endpoint. Exportieren Sie alles, was Sie benötigen
(beispielsweise ein Entscheidungs-PDF), bevor Sie ihn aufrufen.
**Nebeneffekte:** Für Löschungen wird kein Webhook ausgelöst.
**Antwort:** `200 OK`, sobald die Löschung abgeschlossen ist, mit einem
JSON-Body, der das `face_retention_outcome`, den Ablauf des
beibehaltenen Templates und bei einer KYB-Sitzung
`deleted_child_verifications` meldet. Frühere Versionen dieses Endpoints
gaben `204 No Content` zurück; aktualisieren Sie Clients, die `204`
voraussetzen. Bewahren Sie Ihre `instruction_id` in Ihrem eigenen
Löschprotokoll auf.
**Idempotenz:** Auf HTTP-Ebene nicht idempotent: Der erste Aufruf gibt
`200` zurück; eine Wiederholung gibt `404` zurück, da die Sitzung nicht
mehr aufgelöst werden kann. Nach einem `503` ist die Sitzung weiterhin
vorhanden; wiederholen Sie dieselbe Anfrage, um das Löschen
abzuschließen.
**Authentifizierung:** Senden Sie den API-Schlüssel Ihrer Anwendung im
`x-api-key`-Header; die Sitzung muss zu dieser Anwendung gehören.
Console-Benutzer-Zugriffstoken (`Authorization: Bearer ...`) können
diesen Endpoint ebenfalls aufrufen, wenn sie die Berechtigung
`delete:sessions` besitzen. Authentifizierungs- und Berechtigungsfehler
geben beide `403` zurück; diese API gibt niemals `401` zurück.
**Rate-Limit:** Gemeinsames Schreibkontingent von 300 Anfragen/Min. pro
API-Schlüssel über alle POST/PATCH/DELETE-Endpoints hinweg; ein
Überschreiten gibt `429` zurück.
Um KYC-Sitzungen anhand ihrer numerischen `session_number` als
Massenvorgang zu löschen, verwenden Sie stattdessen `POST
/v3/sessions/delete/`.
**Eingereichte behördliche Berichte:** Wenn sich die ausgewählten Daten
in einem finalisierten behördlichen Bericht befinden, wird die gesamte
Anfrage mit `409` abgelehnt und nichts gelöscht. Der Body verwendet
`code: in_filed_report` und benennt jeden Bericht mit `uuid`,
`report_number`, `report_type` und `case_uuid`. Löschen Sie die Berichte
und wiederholen Sie dann die Anfrage.
operationId: delete_v3_session_by_id
parameters:
- in: path
name: sessionId
required: true
description: >-
UUID (`session_id`) der zu löschenden Sitzung der
Benutzerverifizierung (KYC) oder Unternehmensverifizierung (KYB),
wie sie bei der Sitzungserstellung zurückgegeben wurde. Muss eine
kanonische UUID mit Bindestrichen sein — ein Wert, der keine UUID
ist, stimmt nicht mit der Route überein und gibt `404` zurück.
schema:
type: string
format: uuid
example: 11111111-2222-3333-4444-555555555555
requestBody:
required: false
description: >-
Optional. Lassen Sie den Payload vollständig weg, um die
Datenaufbewahrungsrichtlinie der Anwendung durch eine operative
Löschung zu befolgen.
content:
application/json:
schema:
type: object
properties:
retain_face_embeddings:
type: boolean
nullable: true
description: >-
Überschreibt die `face_retention_policy` der Anwendung für
diese Löschung. `true` behält ein bildfreies biometrisches
Gesichts-Template, das dem Benutzer der Sitzung zugeordnet
ist, bei, nachdem die Sitzung gelöscht wurde; `false` löscht
das Gesichts-Embedding mit der Sitzung; weglassen oder
`null`, um der Richtlinie der Anwendung zu folgen. Wird für
KYB-Sitzungen und für Sitzungen ohne Gesichts-Embedding
ignoriert.
example: true
face_retention_days:
type: integer
minimum: 1
maximum: 3650
description: >-
Endliche Aufbewahrungsdauer in Tagen für ein aufbewahrtes
Template. Erforderlich, wenn ein Template aufbewahrt wird,
es sei denn, die Anwendung legt bereits
`face_retention_days` fest. Das `expires_at` des Templates
wird durch den frühesten der folgenden Zeitpunkte bestimmt:
diese Dauer, der allgemeine Datenaufbewahrungszeitraum der
Anwendung und `face_retention_deadline`.
example: 365
face_retention_deadline:
type: string
format: date-time
description: >-
Optionaler fester Ablaufzeitpunkt für ein aufbewahrtes
Template. Muss in der Zukunft liegen.
example: '2027-08-28T00:00:00Z'
deletion_instruction:
type: string
enum:
- operational_session_delete
- privacy_erasure
default: operational_session_delete
description: >-
Die Art der Anweisung, die Sie erteilen.
`operational_session_delete` löscht die Sitzung und behält
ein Template nur dann bei, wenn die Richtlinie oder
`retain_face_embeddings` dies vorschreibt. `privacy_erasure`
löscht jedes beibehaltene biometrische Template, das mit dem
Benutzer der Sitzung verknüpft ist, bevor die Sitzung
gelöscht wird, kann nicht durch die Anwendungsrichtlinie
überschrieben werden und kann nicht mit
`retain_face_embeddings: true` kombiniert werden (`400`).
example: operational_session_delete
instruction_id:
type: string
maxLength: 255
description: >-
Ihre dauerhafte Referenz für diese Löschanweisung
(beispielsweise die ID eines Löschtickets). Wird im
Audit-Log und auf jedem aufbewahrten Template erfasst. Wird
von Didit generiert, wenn sie weggelassen wird.
example: dsar-2026-0142
examples:
Retain a biometric template:
summary: >-
Die Sitzung löschen, eine bildfreie Vorlage für 365 Tage
behalten
value:
retain_face_embeddings: true
face_retention_days: 365
instruction_id: post-approval-cleanup-2026-08
Force deletion on an opted-in application:
summary: >-
Das Gesichts-Embedding unabhängig von der Anwendungsrichtlinie
löschen
value:
retain_face_embeddings: false
Privacy erasure:
summary: >-
Anfrage einer betroffenen Person: Sitzung löschen und jedes
gespeicherte Template für diese Person endgültig entfernen
value:
deletion_instruction: privacy_erasure
instruction_id: dsar-2026-0142
responses:
'200':
description: >-
Sitzung gelöscht. Der Body gibt an, was mit den
Gesichtsbiometriedaten der Sitzung geschehen ist und bei einer
KYB-Sitzung, wie viele von ihr erstellte Verifizierungen zusammen
mit ihr gelöscht wurden.
content:
application/json:
schema:
type: object
properties:
session_id:
type: string
format: uuid
description: Die gelöschte Sitzung.
session_number:
type: integer
nullable: true
description: Die Nummer der gelöschten Sitzung.
face_retention_outcome:
type: string
enum:
- retained_with_user
- deleted
- none
- ineligible_no_vendor_user
description: >-
Was mit den biometrischen Gesichtsdaten der Sitzung
passiert ist. `deleted`: Das Gesichts-Embedding wurde mit
der Sitzung gelöscht (Standard). `retained_with_user`: Die
Sitzung wird gelöscht und ein bildfreies biometrisches
Template bleibt beim Benutzer verankert; siehe
`biometric_template_uuid`. `none`: Die Sitzung hatte kein
Gesichts-Embedding (beispielsweise eine KYB-Sitzung oder
eine KYC-Sitzung ohne Liveness-Selfie).
`ineligible_no_vendor_user`: Die Aufbewahrung wurde
angefordert, aber die Sitzung hat keinen verknüpften
Benutzer, daher wurde das Embedding mit der Sitzung
gelöscht. Ein Fehler des biometrischen Speichers wird über
dieses Feld an diesem Endpoint niemals gemeldet: Er gibt
`503` zurück und die Sitzung wird nicht gelöscht.
biometric_template_uuid:
type: string
format: uuid
nullable: true
description: >-
ID des aufbewahrten biometrischen Templates, wenn
`face_retention_outcome` gleich `retained_with_user` ist;
andernfalls `null`. Verwalten Sie es über
`/v3/biometric-templates/{template_uuid}/`.
biometric_template_expires_at:
type: string
format: date-time
nullable: true
description: >-
Wann das aufbewahrte biometrische Template gelöscht wird,
wenn `face_retention_outcome` auf `retained_with_user`
steht; `null`, wenn kein Template aufbewahrt wird.
deleted_child_verifications:
type: integer
description: >-
Für eine Unternehmensverifizierungs-Sitzung (KYB): wie
viele der von ihr erstellten Verifizierungen (die
KYC-Sitzungen ihrer Schlüsselpersonen und die
KYB-Sitzungen ihrer Unternehmenseigentümer, rekursiv)
zusammen mit ihr gelöscht wurden. Bei einer KYC-Sitzung
immer `0`.
examples:
Deleted (default):
value:
session_id: 4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02
session_number: 1024
face_retention_outcome: deleted
biometric_template_uuid: null
biometric_template_expires_at: null
deleted_child_verifications: 0
Retained with User:
value:
session_id: 4c5c7f3a-3b1d-4b7e-9c39-2b4f7e6a1d02
session_number: 1024
face_retention_outcome: retained_with_user
biometric_template_uuid: 9d2f4b6e-1c3a-4e8f-b7d5-0a1c2e3f4a5b
biometric_template_expires_at: '2027-10-09T10:15:00Z'
deleted_child_verifications: 0
'Ineligible: no User':
summary: >-
Aufbewahrung für eine Sitzung angefordert, die ohne
vendor_data erstellt wurde
value:
session_id: 7a1e9c2d-5f4b-4c3a-8e2d-1b0a9f8e7d6c
session_number: 1031
face_retention_outcome: ineligible_no_vendor_user
biometric_template_uuid: null
biometric_template_expires_at: null
deleted_child_verifications: 0
KYB session:
value:
session_id: 0f3c9b7e-2d1a-4e5f-8c6b-7a9d8e1f2c3b
session_number: 88
face_retention_outcome: none
biometric_template_uuid: null
biometric_template_expires_at: null
deleted_child_verifications: 3
summary: >-
Eine Unternehmensverifizierung, die zusammen mit den drei
für ihre Schlüsselpersonen erstellten Verifizierungen
gelöscht wurde
'400':
description: Validierungsfehler – es wird nichts gelöscht.
content:
application/json:
examples:
Privacy erasure cannot retain:
value:
retain_face_embeddings:
- Privacy erasure cannot retain biometric templates.
No finite retention duration:
summary: >-
Aufbewahrung ohne face_retention_days in der Anfrage oder
der Anwendung angefordert
value:
detail: >-
A finite biometric-template retention duration is
required.
'403':
description: >-
Authentifizierungs- oder Berechtigungsfehler. Ein fehlender
Schlüssel gibt ebenfalls `403` zurück; ein falscher, widerrufener
oder abgelaufener Schlüssel gibt `401` zurück. Ausnahme: Wenn die
`sessionId` nicht zu einer aktiven Sitzung aufgelöst werden kann,
gibt die Eigentümerprüfung vor der Authentifizierung zuerst `404`
zurück, selbst bei fehlenden oder ungültigen Anmeldedaten.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Missing or invalid API key:
summary: >-
Kein x-api-key-Header vorhanden oder der Schlüssel ist
ungültig
value:
detail: >-
Authentication credentials were not provided or are
invalid.
Insufficient permission:
summary: >-
Benutzer-Token ohne delete:sessions oder Anmeldedaten für
eine Anwendung, die nicht Eigentümer der Sitzung ist
value:
detail: You do not have permission to perform this action.
'404':
description: >-
Es existiert keine aktive KYC- oder KYB-Sitzung mit dieser
`session_id` – die ID ist unbekannt oder die Sitzung wurde bereits
gelöscht (das Wiederholen einer erfolgreichen Löschung führt
hierher).
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Not Found:
summary: Unbekannte oder bereits gelöschte Sitzung
value:
detail: Not found.
'409':
description: >-
Die Sitzung ist Teil eines finalisierten behördlichen Berichts. Es
wird nichts gelöscht.
content:
application/json:
schema:
$ref: '#/components/schemas/InFiledReportError'
'429':
description: >-
Gemeinsames Schreib-Rate-Limit überschritten (300
POST/PATCH/DELETE-Anfragen pro Minute pro API-Schlüssel). Prüfen Sie
`Retry-After` und die `X-RateLimit-*`-Antwort-Header vor einem
Wiederholungsversuch.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Rate limited:
summary: Schreibbudget aufgebraucht
value:
detail: >-
Write request rate limit exceeded. You can make up to 300
requests per minute.
'503':
description: >-
Die Löschung konnte nicht abgeschlossen werden, da ein
Speicherdienst, ein biometrischer Speicher oder ein
Überwachungsanbieter nicht verfügbar war. Die Sitzung bleibt
bestehen; wiederholen Sie dieselbe Anfrage, bis sie `200`
zurückgibt. Einige der gespeicherten Dateien oder das
Gesichts-Embedding sind möglicherweise bereits gelöscht, verlassen
Sie sich nach einem `503` also nicht darauf. Wiederholungsversuche
konvergieren auf ein einziges biometrisches Template.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
examples:
Session deletion unavailable:
summary: >-
Ein Speicherdienst oder ein Monitoring-Anbieter war nicht
verfügbar
value:
detail: >-
The session could not be deleted because a storage service
or a monitoring provider is unavailable. The session is
still in place; repeat the request to finish deleting it.
Biometric store unavailable:
summary: >-
Ein Biometriespeicher war während des Aufbewahrens oder
Löschens einer Vorlage nicht verfügbar
value:
detail: >-
The biometric-template operation could not finish because
an external store is unavailable. The operation is
retryable.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: curl (default policy)
source: |-
curl -X DELETE \
https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \
-H 'x-api-key: YOUR_API_KEY'
- lang: curl
label: curl (retain template)
source: |-
curl -X DELETE \
https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"retain_face_embeddings": true, "face_retention_days": 365}'
- lang: curl
label: curl (privacy erasure)
source: |-
curl -X DELETE \
https://verification.didit.me/v3/session/11111111-2222-3333-4444-555555555555/delete/ \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{"deletion_instruction": "privacy_erasure", "instruction_id": "dsar-2026-0142"}'
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.sessions.delete(
"11111111-2222-3333-4444-555555555555",
retain_face_embeddings=True,
face_retention_days=365,
instruction_id="post-approval-cleanup-2026-08",
)
print(result)
- lang: javascript
label: Node.js
source: >-
import Didit from "@didit-protocol/sdk-node";
// Reads DIDIT_API_KEY.
const didit = new Didit();
const result = await
didit.sessions.delete("11111111-2222-3333-4444-555555555555", {
retain_face_embeddings: true,
face_retention_days: 365,
instruction_id: "post-approval-cleanup-2026-08",
});
console.log(result);
- lang: go
label: Go
source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Sessions.Delete(ctx, \"11111111-2222-3333-4444-555555555555\", didit.SessionsDeleteParams{\n\tRetainFaceEmbeddings: didit.Bool(true),\n\tFaceRetentionDays: didit.Int(365),\n\tInstructionID: didit.String(\"post-approval-cleanup-2026-08\"),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)"
- lang: java
label: Java
source: >-
import me.didit.Didit;
import me.didit.types.SessionsDeleteParams;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result =
client.sessions().delete("11111111-2222-3333-4444-555555555555",
SessionsDeleteParams.builder()
.retainFaceEmbeddings(true)
.faceRetentionDays(365L)
.instructionId("post-approval-cleanup-2026-08")
.build());
System.out.println(result);
- lang: php
label: PHP
source: >-
sessions->delete('11111111-2222-3333-4444-555555555555', [
'retain_face_embeddings' => true,
'face_retention_days' => 365,
'instruction_id' => 'post-approval-cleanup-2026-08',
]);
print_r($result->toArray());
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.sessions.delete(
"11111111-2222-3333-4444-555555555555",
retain_face_embeddings: true,
face_retention_days: 365,
instruction_id: "post-approval-cleanup-2026-08"
)
puts result.to_h
- lang: csharp
label: .NET
source: >-
using System;
using System.Text.Json;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var result = await
client.Sessions.DeleteAsync("11111111-2222-3333-4444-555555555555",
new SessionsDeleteParams
{
RetainFaceEmbeddings = true,
FaceRetentionDays = 365,
InstructionId = "post-approval-cleanup-2026-08",
});
Console.WriteLine(JsonSerializer.Serialize(result));
components:
schemas:
InFiledReportError:
type: object
description: >-
Die Löschung wird verweigert, da sich die ausgewählten Daten in einem
abgeschlossenen regulatorischen Bericht befinden. Es wird nichts
gelöscht. Löschen Sie den Bericht und wiederholen Sie die Anfrage.
required:
- detail
- code
properties:
detail:
type: string
code:
type: string
enum:
- in_filed_report
description: >-
Stabiler Fehlercode für eine Löschung, die durch einen finalisierten
regulatorischen Bericht blockiert wird.
reports:
type: array
items:
$ref: '#/components/schemas/FiledRegulatoryReport'
description: >-
Berichte, die das Löschen einer Person, eines Unternehmens, eines
Falls oder einer Sitzung blockieren.
transactions:
type: array
items:
$ref: '#/components/schemas/FiledReportTransaction'
description: >-
Transaktionen, die das Löschen einer Transaktion blockieren, jeweils
mit den Berichten, in denen sie aufgeführt sind.
FiledRegulatoryReport:
type: object
description: >-
Ein finalisierter regulatorischer Bericht, der die angeforderte Löschung
verhindert.
required:
- uuid
- report_number
- report_type
- case_uuid
properties:
uuid:
type: string
format: uuid
description: Berichts-UUID.
report_number:
type: string
description: In der Console angezeigte Berichtsnummer (z. B. SAR-0001).
report_type:
type: string
enum:
- SAR
- STR
- CTR
- TTR
- UTR
- IFT
- CBR
- TFR
description: Art des aufsichtsrechtlichen Berichts.
case_uuid:
type: string
format: uuid
description: Fall, zu dem der Bericht gehört.
FiledReportTransaction:
type: object
description: >-
Eine Transaktion, die nicht gelöscht werden kann, da ein abgeschlossener
regulatorischer Bericht sie auflistet.
required:
- uuid
- transaction_id
- reports
properties:
uuid:
type: string
format: uuid
description: Didit-Transaktions-UUID.
transaction_id:
type: string
description: >-
Die Transaktionskennung, die bei der Erstellung der Transaktion
angegeben wurde.
reports:
type: array
items:
$ref: '#/components/schemas/FiledRegulatoryReport'
description: Abgeschlossene Berichte, die diese Transaktion aufführen.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
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.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.