Zum Hauptinhalt springen
Sitzungen sind die Verifizierungseinheit bei Didit. Wenn Sie eine Verifizierung starten, wird eine Sitzung erstellt. Sobald die Verifizierung abgeschlossen ist, enthält die Sitzung den vollständigen Entscheidungs-Payload. Dieselbe Sitzungs-API unterstützt beide Arten: In der Academy-Lektion zu dem, was Benutzer sehen, vergleicht das Kapitel bei 5:34 den gehosteten Ablauf mit dem Aufbau eigener Oberflächen. Genau diese Abwägung nimmt Ihnen diese API ab.

​
Die Art wird durch den Workflow bestimmt

Wenn Sie eine Sitzung erstellen, übergeben Sie eine workflow_id. Der Workflow-Typ bestimmt, ob die Sitzung eine Sitzung zur Benutzerverifizierung (KYC) oder zur Unternehmensverifizierung (KYB) ist. Aufrufer wählen die Art nicht separat aus. KYB-Workflows erzeugen Sitzungen zur Unternehmensverifizierung (KYB); KYC-Workflows erzeugen Sitzungen zur Benutzerverifizierung (KYC).

​
Der Diskriminator session_kind

Jede Sitzungsantwort – unabhängig davon, ob sie beim Erstellen, Abrufen, Auflisten, Aktualisieren des Status, Teilen oder Importieren entsteht – enthält ein Feld auf oberster Ebene:
  • "user": Die Sitzung ist eine Sitzung zur Benutzerverifizierung (KYC). Die Antwort enthält benutzerspezifische Funktions-Arrays.
  • "business": Die Sitzung ist eine Sitzung zur Unternehmensverifizierung (KYB). Die Antwort enthält unternehmensspezifische Funktions-Arrays.
Verwenden Sie dieses Feld, um auf Ihrer Seite die passende Struktur auszuwählen.
Die Enum-Werte sind die kurzen Bezeichner "user" und "business". Wir halten sie kurz, damit die API komfortabler zu nutzen ist. Die vollständigen Namen Benutzerverifizierung (KYC) und Unternehmensverifizierung (KYB) werden in der gesamten Dokumentation zur Verdeutlichung verwendet.

​
Funktions-Arrays je nach Art

Welche Funktions-Arrays in einer Entscheidung vorkommen, hängt von der Art ab. Felder, die bei einer Art fehlen, erscheinen in dieser Antwort schlicht nicht (keine Nullwerte, keine Platzhalter):

​
Gemeinsame Felder auf oberster Ebene

Jede Sitzung (beider Arten) enthält diese Felder:

​
Abgedeckte Endpoints

Die folgenden Endpoints akzeptieren beide Arten. Es gibt keine separaten Pfade /v3/business-session/*.

​
So funktionieren Abfragen

Sitzungen zur Benutzerverifizierung (KYC) und zur Unternehmensverifizierung (KYB) sind zwei getrennte Arten. IDs sind UUIDs, daher sind Kollisionen ausgeschlossen. Wenn Sie einen Endpoint mit einer session_id aufrufen, geht Didit wie folgt vor:
  1. Die ID wird zuerst in der Tabelle für Benutzerverifizierungen (KYC) gesucht, da dort der größte Teil des Traffics anfällt.
  2. Bei keinem Treffer wird die Tabelle für Unternehmensverifizierungen (KYB) durchsucht.
  3. Wenn keine der beiden Tabellen einen Treffer hat, wird 404 zurückgegeben.
Sie müssen der API nie mitteilen, welche Art Sie suchen.

​
Status-Werte sind identisch

Die Status-Werte sind für beide Arten gleich. Die API gibt sie genau so zurück, wie sie hier aufgeführt sind: "Not Started", "In Progress", "Approved", "Declined", "In Review", "Abandoned", "Expired", "Kyc Expired", "Resubmitted", "Awaiting User". Der Abgleich erfolgt exakt und unter Beachtung der Groß- und Kleinschreibung. Die vollständige Referenz finden Sie unter Verifizierungsstatus.

​
Webhooks

Webhook-Ereignisse enthalten bereits ein Feld session_kind, damit Ihre Webhook-Handler Ereignisse pro Art verarbeiten können: Informationen zur Signaturprüfung und zur Wiederholungslogik finden Sie unter Webhooks. Den Katalog der Ereignisse für die Unternehmensverifizierung finden Sie unter KYB-Webhooks.

​
Nächste Schritte

Sitzung erstellen

Starten Sie eine Verifizierung: Benutzerverifizierung oder Unternehmensverifizierung.

Sitzung abrufen

Rufen Sie die Entscheidung ab. Funktioniert für beide Arten.

Sitzungen auflisten

Filtern Sie nach session_kind.

Status aktualisieren

Genehmigen, ablehnen, prüfen oder erneut einreichen.

PDF erstellen

PDF-Berichte je Art.

Teilen und importieren

Sitzungen zwischen Anwendungen übertragen.
Zuletzt geändert am 7. November 2026