> ## 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. # API-Schlüssel mit eingeschränkten Rechten – Didit KYC API > Didit: Eigene API-Schlüssel pro Dienst oder Partner, nur mit nötigen Rechten, IP-Allowlist, Ablaufdatum und sofortigem Widerruf. Prompt für API-Schlüssel mit eingeschränktem Zugriff Prompt in die Zwischenablage kopieren \

\````# Goal - call Didit with a scoped API key

Every application has a primary secret with full access, and any number of named API keys.
A named key carries its own access: read or write per resource, optional limits, an optional IP allowlist and an optional expiry date.
Keys are created, edited, rotated and revoked in the Business Console (Developers -> API keys); there is no API to manage them.

\## Sending the key

\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/decision/ \
-H "x-api-key: $DIDIT_API_KEY"
\```

Read the key from an environment variable or a secrets manager, never from source code.

\## What each answer means

\| Status | Meaning |
\|---|---|
\| 401 | The key is missing, wrong, revoked or expired |
\| 403 | The key has no access to this resource or action, or the request came from an address outside its IP list |
\| 404 | The session is outside the key's workflows or statuses, so to this key it does not exist |

A key without media access receives decisions with every image, video and PDF URL set to null, and gets 403 on PDF reports.
A key without sessions write receives session_url and session_token as null.

\## Resources

sessions, decisions, media (read only), users, businesses, transactions, workflows, webhooks, applications, analytics (read only), api-keys.
Read covers GET requests, write covers POST, PUT, PATCH and DELETE.
Standalone checks (face match, ID verification, AML screening and the other /v3 standalone APIs) need sessions write.
Creating a person with send_verification_link: true (POST /v3/users/create/) needs users write and sessions write; without sessions write it answers 403 and nothing is created.

\## Limits

\- workflow_ids: only sessions of these workflows are visible, and sessions can only be created with them.
\- approved sessions only: declined, in-review and unfinished sessions are hidden.
\- A key with either limit cannot have access to users, businesses, transactions or analytics.

\## Rotation

Rotating a key returns a new secret once; the previous secret keeps working for 24 hours.````

\
Einfügen in Jede Anwendung beginnt mit einem **primären Secret**, das vollen Zugriff auf alles hat, was die Anwendung tun kann. Sie können daneben **benannte API-Schlüssel** anlegen, einen pro Dienst oder Partner, jeweils nur mit dem Zugriff, den er benötigt. Geben Sie Ihrem Auszahlungsanbieter einen Schlüssel, der genehmigte Sitzungen eines einzelnen Workflows lesen, aber nichts ändern kann. Behalten Sie für Ihr Backend einen eigenen Schlüssel und widerrufen Sie jeweils einen der beiden, ohne den anderen anzutasten.> [!NOTE] > > Schlüssel, die vor der Einführung des eingeschränkten Zugriffs angelegt wurden, behalten vollen Zugriff. > Für sie ändert sich nichts, bis Sie ihren Zugriff bearbeiten.***## Wo Sie sie findenWählen Sie in der [**Business-Konsole**](https://business.didit.me) Ihre Anwendung aus und öffnen Sie **Developers -> API keys**.Die Liste zeigt alle Schlüssel der Anwendung mit ihrem Status, ihren Anfragen in den letzten 30 Tagen, dem Ersteller, ihrem Zugriff und dem Zeitpunkt der letzten Nutzung. Klicken Sie auf einen Schlüssel, um ihn rechts in der Vorschau anzuzeigen, oder öffnen Sie seine vollständige Seite mit Nutzung, Zugriff, letzten Anfragen, einem Schnellstart-Snippet und seiner Aktivität.Schlüssel gehören jeweils zu einer Anwendung und funktionieren nur für diese. Ein Schlüssel hat die Umgebung der Anwendung: Schlüssel einer Sandbox-Anwendung erzeugen niemals kostenpflichtige Verifizierungen.***## Weiterleitungs-URLs und zulässige DomainsÖffnen Sie **Developers > API keys > Redirects and domains**, um zwei Listen für die ausgewählte Anwendung und Umgebung festzulegen.| Liste | Was sie steuert | | - | - | | **Weiterleitungs-URLs** | Wohin Didit den Browser nach dem Ende einer gehosteten Verifizierung schickt. Eine URL muss exakt übereinstimmen, einschließlich des Pfads. | | **Zulässige Domains** | Die Origins (Schema, Host und optional Port, etwa `https://app.example.com`), in die der gehostete Verifizierungsablauf eingebettet werden darf und an die er den Benutzer zurücksenden darf. |Wenn die Liste **Zulässige Domains** Einträge enthält, lehnt [Sitzung erstellen](https://docs.didit.me/de/sessions-api/create-session.md) jeden `callback` mit einem Fehler `400` ab, der nicht auf einer dieser Domains liegt. Eine leere Liste bedeutet keine Einschränkung. Serverseitige Aufrufe sind davon nicht betroffen.***## Schlüssel erstellen**1. Details**Benennen Sie den Schlüssel nach dem Dienst, der ihn verwendet, und legen Sie fest, wann er abläuft: nie, nach 30 Tagen, nach 90 Tagen, nach einem Jahr oder an einem Datum Ihrer Wahl. Ein abgelaufener Schlüssel funktioniert am Ende dieses Tages (UTC) nicht mehr.**2. Zugriff**Beginnen Sie mit einer Voreinstellung und passen Sie sie anschließend pro Ressource an. Der Schlüssel kann nie mehr als das.**3. Prüfung**Die Konsole zeigt genau an, was der Schlüssel darf und was nicht, bevor Sie ihn weitergeben.**4. Geheimer Schlüssel**Kopieren Sie das Geheimnis und speichern Sie es in Ihrem Secrets-Manager. Das vollständige Geheimnis wird nur dieses eine Mal angezeigt. Falls Sie es verlieren, rotieren Sie den Schlüssel, um einen neuen zu erhalten.### Voreinstellungen| Voreinstellung | Zugriff | | - | - | | **Vollzugriff** | Jede Ressource, lesend und schreibend, einschließlich anderer API-Schlüssel. Für Ihr eigenes Backend. | | **Nur Lesezugriff** | Sitzungen und Entscheidungen, Medien optional. Der Schlüssel kann nichts erstellen, ändern oder löschen. Für einen Partner, der Ergebnisse benötigt. | | **Benutzerdefiniert** | Sie wählen für jede Ressource Keine, Lesen oder Schreiben. |### RessourcenLesen umfasst `GET`-Anfragen für eine Ressource; Schreiben umfasst außerdem `POST`, `PUT`, `PATCH` und `DELETE`.| Ressource | Lesen | Schreiben | | - | - | - | | **Sitzungen** | Sitzungen auflisten und öffnen | Sitzungen erstellen, aktualisieren und löschen, Sitzungen importieren und eigenständige Prüfungen ausführen (Gesichtsabgleich, Ausweisverifizierung, AML-Screening und die übrigen eigenständigen APIs) | | **Entscheidungen** | Ergebnisse, Risiko-Scores, extrahierte Daten und den Verlauf des AML-Screenings | Genehmigen, ablehnen oder zur Prüfung weiterleiten sowie Status von Funktionen und AML-Treffern ändern | | **Medien** | ID-Bilder, Selfies, Videos und PDF-Berichte | - | | **Personen** (`users`) | Endbenutzer und alles, was über sie verifiziert wurde | Benutzer erstellen, aktualisieren und löschen sowie deren Überwachung. Das Erstellen eines Benutzers mit einem Verifizierungslink erfordert zusätzlich Schreibzugriff auf **Sitzungen** | | **Unternehmen** (`businesses`) | Unternehmensprofile, deren Dokumente und Eigentümer | Unternehmen erstellen, aktualisieren und löschen sowie deren Überwachung | | **Transaktionen** | Transaktionen, Alerts, Regeln, Monitoring-Ereignisse, Daten zur Travel Rule und Wallet-Screening | Transaktionen und Ereignisse senden, deren Status ändern sowie Einstellungen zur Travel Rule, das Wallet-Adressbuch und Transfers verwalten | | **Workflows** | Workflows, Fragebögen, Listen und Sperrlisten | Erstellen und bearbeiten | | **Webhooks** | Endpoints und Zustellungen (mit Lesezugriff auf **Entscheidungen**, da eine Zustellung das gesendete Sitzungs-Payload enthält) | Endpoints hinzufügen, bearbeiten und löschen sowie Zustellungen erneut senden | | **Anwendungseinstellungen** (`applications`) | Anpassung und Guthaben | Anpassung ändern und das Guthaben aufladen | | **Analysen** | Kennzahlen und Berichtsexporte | - | | **API-Schlüssel** | Für die Schlüsselverwaltung reserviert | Für die Schlüsselverwaltung reserviert |Ein Schlüssel mit benutzerdefiniertem Zugriff funktioniert in der öffentlichen API: bei den Endpoints für Sitzungen, Benutzer, Unternehmen, Transaktionen, Workflows und Webhooks sowie bei den eigenständigen Prüfungen. Endpoints, die nur die Business Console nutzt, antworten darauf mit `403`; dafür ist ein Schlüssel mit Vollzugriff erforderlich.Ein Schlüssel ohne Lesezugriff auf **Medien** erhält Sitzungsentscheidungen, bei denen jede Bild-, Video- und PDF-URL auf `null` gesetzt ist, und PDF-Berichtsendpoints antworten mit `403`. Ein Schlüssel ohne Schreibzugriff auf **Sitzungen** erhält nie den Verifizierungslink oder das Sitzungstoken einer Sitzung, da jeder, der sie besitzt, die Verifizierung im Namen des Endbenutzers abschließen kann: Diese Felder werden als `null` zurückgegeben. Aus demselben Grund erfordert das Anlegen einer Person mit `send_verification_link: true` zusätzlich zum Schreibzugriff auf **Personen** auch Schreibzugriff auf **Sitzungen**, da dabei eine Sitzung erstellt und ihr Link per E-Mail versendet wird. Ohne diesen Zugriff antwortet der Aufruf mit `403` und legt nichts an.### Beschränkungen| Beschränkung | Wirkung | | - | - | | **Workflows** | Der Schlüssel sieht nur Sitzungen der von Ihnen gewählten Workflows und kann nur Sitzungen mit diesen erstellen. Für jede andere Sitzung wird `404` zurückgegeben, als wäre sie nicht vorhanden. | | **Nur genehmigte Sitzungen** | Abgelehnte, in Prüfung befindliche und unvollständige Sitzungen bleiben für den Schlüssel verborgen. | | **IP-Adressen** | Der Schlüssel funktioniert nur von den von Ihnen angegebenen Adressen oder CIDR-Bereichen aus (bis zu 20, IPv4 oder IPv6). Anfragen von jeder anderen Adresse antworten mit `403`. | | **Läuft ab** | Nach diesem Datum antwortet jede Anfrage mit dem Schlüssel mit `401`. |Ein Schlüssel, der auf bestimmte Workflows oder auf genehmigte Sitzungen beschränkt ist, funktioniert an den Sitzungsendpoints, an denen die Beschränkung angewendet werden kann. Er kann nicht auf Personen, Unternehmen, Transaktionen oder Analysen zugreifen und keine eigenständigen Prüfungen ausführen.***## So antwortet die API auf einen eingeschränkten Schlüssel| Status | Bedeutung | | - | - | | **401** | Der Schlüssel fehlt, ist falsch, widerrufen oder abgelaufen. | | **403** | Der Schlüssel hat keinen Zugriff auf diese Ressource oder Aktion, oder die Anfrage kam von einer Adresse außerhalb seiner IP-Liste. | | **404** | Die Sitzung liegt außerhalb der vom Schlüssel erlaubten Workflows oder Statuswerte. |Sitzungslisten liefern nur die Sitzungen zurück, die die Beschränkungen des Schlüssels zulassen.***## Zugriff bearbeitenÖffnen Sie das Menü eines Schlüssels, seine Vorschau oder seine Seite und wählen Sie **Zugriff bearbeiten**. Ändern Sie Voreinstellung, Ressourcen, Beschränkungen oder Ablaufdatum und prüfen Sie dann nur die Änderungen, jeweils vorher und nachher. Das Geheimnis bleibt gleich, daher muss nichts neu bereitgestellt werden, und der neue Zugriff gilt innerhalb einer Minute.Das primäre Geheimnis hat immer Vollzugriff und kann nicht bearbeitet werden.***## Schlüssel rotierenBeim Rotieren wird das Geheimnis eines Schlüssels ersetzt. Das neue Geheimnis wird nur einmal angezeigt, und das bisherige Geheimnis funktioniert weitere **24 Stunden**, damit Sie das neue ohne Ausfallzeit bereitstellen können. Danach antwortet jede Anfrage mit dem alten Geheimnis mit `401`.Das primäre Geheimnis wird auf dieselbe Weise rotiert, mit derselben Überlappung von 24 Stunden.***## Schlüssel widerrufenBeim Widerrufen wird ein Schlüssel sofort gestoppt: Jede Anfrage mit ihm antwortet mit `401`. Dies kann nicht rückgängig gemacht werden. Das primäre Geheimnis kann nicht widerrufen werden; rotieren Sie es stattdessen.***## Nutzung und Audit-LogFür jeden Schlüssel werden seine Anfragen der letzten 30 Tage, seine Fehlerrate und Latenz sowie seine neuesten Anfragen mit ihren Statuscodes angezeigt, einschließlich der Anfragen, die seine Beschränkungen abgelehnt haben.Jeder mit einem API-Schlüssel ausgeführte Aufruf erscheint in den [Audit-Logs](https://docs.didit.me/de/console/audit-logs.md) der Organisation mit dem Namen des Schlüssels, mit dem er ausgeführt wurde.***## Wer API-Schlüssel verwalten kannZum Verwalten von API-Schlüsseln benötigen Sie die Berechtigung **API-Schlüssel**: Mit Leserechten können Sie die Schlüssel einsehen, mit Schreibrechten können Sie sie erstellen, bearbeiten, rotieren und widerrufen. Weitere Informationen finden Sie unter [Rollen und Berechtigungen](https://docs.didit.me/de/console/roles-permissions.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.