> ## 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. # Benutzer löschen API: Batch-Löschung und DSGVO-Löschung > Löschen Sie Didit-Benutzer gesammelt nach vendor_data oder alle Benutzer einer Anwendung. DSGVO- und CCPA-konform (Recht auf Vergessenwerden). Prompt zum Stapellöschen von Benutzern Prompt in die Zwischenablage kopieren \

\`Goal: Permanently delete one or many Didit User entities. The matching user records, their tag links, their comment history, and every retained biometric template anchored to them are removed permanently. Verification sessions are NOT removed by this endpoint; delete those separately with POST /v3/sessions/delete/.

Endpoint: POST https://verification.didit.me/v3/users/delete/
Auth header: x-api-key: 
Content-Type: application/json

Request body — provide at least one selector:
\- vendor_data_list: string[] — your own identifiers (case-insensitive after normalisation).
\- didit_internal_id_list: string[] — Didit internal user IDs, the didit_internal_id returned by the create and get endpoints. Can be combined with vendor_data_list; the two are OR'd.
\- delete_all: true — wipe every user in this application. No confirmation, no undo. Takes precedence: when delete_all is true, the two lists are ignored.

\- retain_face_embeddings: boolean, default false — your explicit choice to keep one image-free biometric template of each deleted person for duplicate detection. Everything else about the person is deleted. Requires face_retention_days.
\- face_retention_days: integer 1 to 3650 — how many days that template is kept. Sent without retain_face_embeddings: true it returns 400 on face_retention_days.

This endpoint never narrows delete_all with filters. The Console's filter_* batch params (filter_search, filter_status, filter_country, filter_date_from, filter_date_to, filter_tag, filter_latest_verification_status, filter_risk, filter_has_sessions, filter_has_open_alerts, filter_aml_monitoring, filter_can_sign_in, filter_auth_status, filter_auth_method, filter_auth_mfa_enabled) are NOT supported here. Any of them sent with a value, even false, is rejected with a 400 keyed by that field, and any other unknown filter_* key with "Unknown filter.", so a narrowed intent does not wipe the whole application. Exception: filter_has_approved_sessions and filter_has_declined_sessions are neither rejected nor applied, so with delete_all they still delete every user. Do not send them.

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

Response 200:
\{
"deleted": 
}

Biometric templates: unless you set retain_face_embeddings to true, if the application retained image-free biometric templates for these users after session deletion (see /management-api/biometric-templates/overview), Didit purges every one of them before the user is deleted, so the person stops matching in duplicate detection and Face Search. The purge is audited with instruction_source: vendor_user_delete.

Idempotency: re-sending the same list returns deleted: 0 after the first run (unmatched IDs are silently skipped). There is no undo.

Failure modes:
\- 400 — no selector supplied, or a Console-only filter_* param was sent.
No selector: {"vendor_data_list": ["This field is required unless delete_all is true."]}. An unknown filter_* key: {"filter_": ["Unknown filter."]}.
\- 401 — missing/invalid x-api-key.
\- 403 — the API key is revoked or is not valid for this application.
\- 409 — the selection includes a person in a finalized regulatory report. Nothing is deleted. The body has code: in_filed_report and reports[] with uuid, report_number, report_type and case_uuid. Delete the reports, then repeat the request.
\- 409 — code: subject_deletion_in_progress: another request is still deleting one of the selected people. This request deleted nothing; repeat it once that deletion has finished.
\- 429 — rate-limited.
\- 503 — {"detail": "The biometric-template operation could not finish because an external store is unavailable. The operation is retryable."} A retained biometric template could not be purged. No user in the request is deleted; the affected template is already excluded from matching. Repeat the same request.

WARNING — delete_all: true: there is no confirmation step and no undo. Restrict to API keys you intentionally provision for batch maintenance.

When to prefer status change instead:
\- For day-to-day blocking, use PATCH /v3/users/{vendor_data}/update-status/ with {"status": "BLOCKED"} — it keeps the audit trail intact while rejecting future sessions for the same identifier.

For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`

\
Einfügen in ## ÜberblickLöscht eine oder mehrere [Benutzer-Entitäten](https://docs.didit.me/de/entities/users/overview.md). 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](https://docs.didit.me/de/sessions-api/delete-session.md) oder [Mehrere Sitzungen löschen](https://docs.didit.me/de/management-api/sessions/batch-delete.md). Auch Transaktionen werden nicht erfasst. Löschen Sie sie mit [Mehrere Transaktionen löschen](https://docs.didit.me/de/management-api/transactions/delete.md).## 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](https://docs.didit.me/de/management-api/biometric-templates/overview.md), 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 BerichtIst 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:```json theme={null} { "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](https://docs.didit.me/de/management-api/regulatory-reports/delete.md) 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öschungEine 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:```json theme={null} { "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.## BerechtigungenJeder 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](https://docs.didit.me/de/console/roles-permissions.md) 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- [Datenaufbewahrung](https://docs.didit.me/de/console/data-retention.md) - [Audit-Logs](https://docs.didit.me/de/console/audit-logs.md) - [Benutzeroperationen](https://docs.didit.me/de/entities/users/operations.md) - [Biometrische Templates](https://docs.didit.me/de/management-api/biometric-templates/overview.md) ## OpenAPI ````yaml de/openapi-25.json POST /v3/users/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/users/delete/: post: tags: - Users summary: Benutzer im Batch löschen description: >- **Benutzer dauerhaft löschen**: Die Benutzerdatensätze werden dauerhaft entfernt. Für das alltägliche Blockieren empfiehlt sich [Benutzerstatus aktualisieren](#patch-/v3/users/-vendor_data-/update-status/) mit `BLOCKED`. Wählen Sie Benutzer mit `vendor_data_list`, mit `didit_internal_id_list` oder mit beiden gleichzeitig aus; oder übergeben Sie `delete_all: true`. Dieser Endpoint schränkt `delete_all` niemals durch Filter ein. Die Personenfilter der Console werden mit einem `400` abgelehnt (siehe die `400`-Antwort), sodass eine eingegrenzte Absicht nicht zu einer vollständigen Löschung führt. Zwei Ausnahmen: `filter_has_approved_sessions` und `filter_has_declined_sessions` werden weder abgelehnt noch angewendet; mit `delete_all: true` löschen sie also weiterhin jeden Benutzer; senden Sie diese nicht mit. **Biometrische Templates:** Sofern Sie `retain_face_embeddings` nicht auf `true` setzen, wird jedes bildfreie biometrische Template, das für diese Benutzer nach der Sitzungslöschung aufbewahrt wurde (siehe `/v3/biometric-templates/`), vor dem Löschen des Benutzers bereinigt, sodass die Person bei der Duplikaterkennung und der Gesichtssuche nicht mehr übereinstimmt. Mit `retain_face_embeddings: true` und `face_retention_days` entscheiden Sie sich dafür, ein bildfreies biometrisches Template pro Person für diese Anzahl an Tagen aufzubewahren, und nichts anderes über die Person wird behalten. Kann ein Template nicht bereinigt werden, weil ein biometrischer Speicher nicht verfügbar ist, gibt der Aufruf `503` zurück, kein Benutzer in der Anfrage wird gelöscht und ein erneutes Ausführen der Anfrage schließt den Vorgang ab. **Eingereichte behördliche Berichte:** Befinden sich die ausgewählten Daten in einem finalisierten behördlichen Bericht, wird die gesamte Anfrage mit `409` abgelehnt und nichts wird 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: batch_delete_users requestBody: required: true content: application/json: schema: type: object description: >- 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. properties: vendor_data_list: type: array items: type: string description: >- Ihre eigenen zu löschenden Kennungen, exakt so abgeglichen wie übermittelt. didit_internal_id_list: type: array items: type: string format: uuid description: >- Interne Didit-Benutzer-IDs, die gelöscht werden sollen – die von den Create- und Get-Endpoints zurückgegebene `didit_internal_id`. delete_all: type: boolean default: false description: Wenn `true`, werden alle Benutzer in der Anwendung gelöscht. retain_face_embeddings: type: boolean default: false description: >- 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: type: integer minimum: 1 maximum: 3650 description: >- 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. example: 365 examples: Specific users: summary: Benutzer nach vendor_data löschen value: vendor_data_list: - user-123 - user-456 By Didit internal ID: summary: Benutzer nach didit_internal_id löschen value: didit_internal_id_list: - 3f1c0d3e-8f0a-4c2e-9a3d-9b1f5f4a2c11 All users: summary: Alle Benutzer in dieser Anwendung löschen value: delete_all: true Keep face templates: summary: >- Benutzer löschen und anonyme Gesichtsvorlagen für 365 Tage behalten value: vendor_data_list: - user-123 retain_face_embeddings: true face_retention_days: 365 responses: '200': description: >- Benutzer gelöscht. Gibt die Anzahl der tatsächlich gelöschten Benutzer zurück. content: application/json: schema: type: object properties: deleted: type: integer description: >- Anzahl der gelöschten Benutzer (schließt vendor_data-Werte aus, die mit nichts übereinstimmten). examples: Deleted some: value: deleted: 2 Nothing matched: value: deleted: 0 '400': description: >- Validierungsfehler; es wird nichts gelöscht. Fehler sind nach Feldnamen geschlüsselt. Ohne Selektor (wenn weder eine der Listen angegeben noch `delete_all` auf `true` gesetzt ist) lautet der Body `{"vendor_data_list": ["This field is required unless delete_all is true."]}`; eine leere Liste wird unter ihrem eigenen Schlüssel mit `"This list may not be empty."` abgelehnt. Ein reiner Console-Filter (`filter_search`, `filter_status`, `filter_country`, `filter_date_from`, `filter_date_to`, `filter_tag`, `filter_latest_verification_status`, `filter_risk`, `filter_has_sessions`, `filter_has_open_alerts`, `filter_aml_monitoring`, `filter_can_sign_in`, `filter_auth_status`, `filter_auth_method` oder `filter_auth_mfa_enabled`) wird abgelehnt, sobald er einen Wert enthält, selbst `false`, mit einem Objekt, das nach jedem solchen Feld geschlüsselt ist. Jeder andere unbekannte `filter_*`-Schlüssel wird mit `"Unknown filter."` abgelehnt. content: application/json: examples: Missing selector: summary: Weder list noch delete_all angegeben value: vendor_data_list: - This field is required unless delete_all is true. Console-only filter: value: filter_has_sessions: >- This filter is Console-only and is not supported by this endpoint. '401': description: >- Keine Anmeldedaten angegeben. Anfragen an `/v3/users/*`-Pfade ohne einen `x-api-key`-Header (oder `Authorization: Bearer`-Token) werden von der Authentifizierungs-Middleware abgelehnt, bevor sie die API erreichen. content: application/json: examples: Missing credentials: value: detail: >- You must be authenticated with a valid access token to access this endpoint. '403': description: >- Ungültiger oder widerrufener API-Schlüssel, oder der Schlüssel kann keine Benutzer für diese Anwendung löschen. Ein fehlender Schlüssel gibt `403` zurück; ein falscher, widerrufener oder abgelaufener Schlüssel gibt `401` zurück. content: application/json: examples: Forbidden: value: detail: You do not have permission to perform this action. '409': description: >- Es wird nichts gelöscht. `code` gibt den Grund an: `in_filed_report`, wenn die Auswahl eine Person in einem finalisierten behördlichen Bericht enthält, `subject_deletion_in_progress`, wenn eine andere Anfrage noch eine der ausgewählten Personen löscht. Wiederholen Sie die Anfrage, sobald dieser Löschvorgang abgeschlossen ist. content: application/json: schema: oneOf: - $ref: '#/components/schemas/InFiledReportError' - $ref: '#/components/schemas/SubjectDeletionInProgressError' '429': description: >- Rate-Limit überschritten; drosseln Sie die Anfragen und wiederholen Sie den Versuch nach dem in `Retry-After` angegebenen Intervall. content: application/json: examples: Rate limited: value: detail: Request was throttled. Expected available in 30 seconds. '503': description: >- Ein Biometriespeicher war während des Aufbewahrens oder Löschens eines biometrischen Templates nicht verfügbar. Es wurde nichts gelöscht; wiederholen Sie dieselbe Anfrage. Wiederholungsversuche sind idempotent und führen zu einem einzigen Template. content: application/json: schema: type: object properties: detail: type: string examples: Retryable: 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 source: |- 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"]}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.users.batch_delete( vendor_data_list=["user-123", "user-456"], ) 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.users.batchDelete({ vendor_data_list: ["user-123", "user-456"], }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Users.BatchDelete(ctx, didit.UsersBatchDeleteParams{\n\tVendorDataList: didit.Some([]string{\"user-123\", \"user-456\"}),\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- 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); - lang: php label: PHP source: |- users->batchDelete([ 'vendor_data_list' => ['user-123', 'user-456'], ]); print_r($result->toArray()); - lang: ruby label: Ruby source: >- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.users.batch_delete(vendor_data_list: ["user-123", "user-456"]) 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.Users.BatchDeleteAsync(new UsersBatchDeleteParams { VendorDataList = new string[] { "user-123", "user-456" }, }); 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. SubjectDeletionInProgressError: type: object description: >- Eine andere Anfrage löscht diese Person oder dieses Unternehmen noch. Diese Anfrage hat nichts gelöscht und kann wiederholt werden, sobald dieser Löschvorgang abgeschlossen ist; eine Wiederholung löscht dann alles, was noch ausgewählt ist. required: - detail - code properties: detail: type: string code: type: string enum: - subject_deletion_in_progress description: >- Stabiler Fehlercode für eine Person oder ein Unternehmen, die bzw. das von einer anderen Anfrage noch gelöscht wird. 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.