> ## 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.

# Sessions API: Einheitliche KYC- und KYB-Verifizierung

> Didit Sessions API: KYC und KYB über einen Endpoint. Pay-per-use, Inferenz unter 2s, 220+ Länder, 14,000+ Dokumente, $10 kostenloses Credit/Monat.

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:

| Art | Was verifiziert wird | Entscheidungs-Payload enthält |
| - | - | - |
| **Sitzung zur Benutzerverifizierung (KYC)** | Eine einzelne Person | Ausweisverifizierung, Liveness-Erkennung, Gesichtsabgleich, Adressnachweis (POA), NFC-Verifizierung, Datenbankvalidierung, Telefonverifizierung, E-Mail-Verifizierung, AML-Screening, Fragebögen, Geräte- und IP-Analyse |
| **Sitzung zur Unternehmensverifizierung (KYB)** | Ein Unternehmen bzw. eine juristische Person | Abgleich mit dem Unternehmensregister, Schlüsselpersonen (Geschäftsführer und wirtschaftlich Berechtigte), Dokumentenprüfungen, Telefonverifizierung, E-Mail-Verifizierung, AML-Screening, Fragebögen, Geräte- und IP-Analyse |

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.

[Der gehostete Ablauf vs. eigene Oberflächen: Didit Academy](https://www.youtube.com/embed/LzGe-dMWjUw?start=334\&rel=0\&playsinline=1)

## Die Art wird durch den Workflow bestimmt

Wenn Sie eine [Sitzung erstellen](https://docs.didit.me/de/sessions-api/create-session.md), ü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:

```json theme={null}
{
  "session_id": "...",
  "session_kind": "user",
  ...
}
```

* `"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.

> [!NOTE]
>
> 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):

| Funktions-Array | Benutzerverifizierung (KYC) | Unternehmensverifizierung (KYB) |
| - | :-: | :-: |
| `id_verifications` | ✅ | — |
| `liveness_checks` | ✅ | — |
| `face_matches` | ✅ | — |
| `nfc_verifications` | ✅ | — |
| `poa_verifications` | ✅ | — |
| `database_validations` | ✅ | — |
| `registry_checks` | — | ✅ |
| `document_verifications` | — | ✅ |
| `key_people_checks` | — | ✅ |
| `aml_screenings` | ✅ | ✅ |
| `phone_verifications` | ✅ | ✅ |
| `email_verifications` | ✅ | ✅ |
| `questionnaire_responses` | ✅ | ✅ |
| `ip_analyses` | ✅ | ✅ |
| `reviews` | ✅ | ✅ |
| `contact_details` | ✅ | ✅ |

## Gemeinsame Felder auf oberster Ebene

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

| Feld | Beschreibung |
| - | - |
| `session_id` | UUID der Sitzung |
| `session_kind` | `"user"` (Benutzerverifizierung / KYC) oder `"business"` (Unternehmensverifizierung / KYB) |
| `session_number` | Fortlaufende Nummer innerhalb der Anwendung |
| `session_url` | URL der gehosteten Verifizierungsseite |
| `status` | Gesamtstatus der Sitzung: `APPROVED`, `DECLINED`, `IN_REVIEW`, `IN_PROGRESS` usw. |
| `workflow_id` | UUID des verwendeten Workflows |
| `vendor_data` | Ihre Kennung für die Entität. [Mehr erfahren](https://docs.didit.me/de/entities/vendor-data-linking.md) |
| `metadata` | Frei wählbares JSON, das Sie beim Erstellen angehängt haben |
| `callback` | Optionale Callback-URL |
| `features` | Kommagetrennte Liste der Funktionen, die der Workflow ausführt |
| `expected_details` | Optionaler Payload mit erwarteten Daten für die Kreuzvalidierung |
| `created_at`, `expires_at` | Zeitstempel |

## Abgedeckte Endpoints

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

| Endpoint | Funktioniert für |
| - | - |
| [`POST /v3/session/`](https://docs.didit.me/de/sessions-api/create-session) | Erstellt je nach Workflow-Typ eine Sitzung zur Benutzerverifizierung (KYC) oder zur Unternehmensverifizierung (KYB) |
| [`GET /v3/session/{id}/decision/`](https://docs.didit.me/de/sessions-api/retrieve-session) | Ruft beide Arten ab. Die Zuordnung erfolgt anhand von `session_id` |
| [`GET /v3/sessions/`](https://docs.didit.me/de/sessions-api/list-sessions) | Listet beide Arten auf. Verwenden Sie den Query-Parameter `session_kind`, um zu filtern |
| [`PATCH /v3/session/{id}/update-status/`](https://docs.didit.me/de/sessions-api/update-status) | Aktualisiert beide Arten |
| [`DELETE /v3/session/{id}/delete/`](https://docs.didit.me/de/sessions-api/delete-session) | Löscht beide Arten |
| [`GET /v3/session/{id}/generate-pdf/`](https://docs.didit.me/de/sessions-api/generate-pdf) | Erzeugt ein PDF für beide Arten und wählt die Vorlage für Benutzerverifizierung (KYC) oder Unternehmensverifizierung (KYB) |
| [`POST /v3/session/{id}/share/`](https://docs.didit.me/de/sessions-api/share-session/share) | Das Freigabe-Token enthält `session_kind` |
| [`POST /v3/session/import-shared/`](https://docs.didit.me/de/sessions-api/share-session/import) | Importiert beide Arten und übernimmt `session_kind` aus dem Token |

## 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](https://docs.didit.me/de/integration/verification-statuses.md).

## Webhooks

Webhook-Ereignisse enthalten bereits ein Feld `session_kind`, damit Ihre Webhook-Handler Ereignisse pro Art verarbeiten können:

| Ereignis | Art | Wird ausgelöst, wenn |
| - | - | - |
| `status.updated` | Beide | Der Status einer Sitzung hat sich geändert. Der Payload enthält `session_kind: "user"` oder `"business"`. |
| `data.updated` | Beide | Die Daten einer Sitzung haben sich geändert (Ergebnisse der Funktionen, Aktualisierung des Unternehmensregisters, laufende AML-Überwachung). Der Payload enthält `session_kind`. |
| `business.status.updated` / `business.data.updated` | Unternehmensentität | Die verknüpfte Unternehmensentität hat sich geändert. |
| `user.status.updated` / `user.data.updated` | Benutzerentität | Die verknüpfte Benutzerentität hat sich geändert. |

Informationen zur Signaturprüfung und zur Wiederholungslogik finden Sie unter [Webhooks](https://docs.didit.me/de/integration/webhooks.md). Den Katalog der Ereignisse für die Unternehmensverifizierung finden Sie unter [KYB-Webhooks](https://docs.didit.me/de/business-verification/webhooks.md).

## Nächste Schritte

> [card] [Sitzung erstellen](https://docs.didit.me/de/sessions-api/create-session.md)
>
> Starten Sie eine Verifizierung: Benutzerverifizierung oder Unternehmensverifizierung.

> [card] [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md)
>
> Rufen Sie die Entscheidung ab. Funktioniert für beide Arten.

> [card] [Sitzungen auflisten](https://docs.didit.me/de/sessions-api/list-sessions.md)
>
> Filtern Sie nach `session_kind`.

> [card] [Status aktualisieren](https://docs.didit.me/de/sessions-api/update-status.md)
>
> Genehmigen, ablehnen, prüfen oder erneut einreichen.

> [card] [PDF erstellen](https://docs.didit.me/de/sessions-api/generate-pdf.md)
>
> PDF-Berichte je Art.

> [card] [Teilen und importieren](https://docs.didit.me/de/sessions-api/share-session/overview.md)
>
> Sitzungen zwischen Anwendungen übertragen.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.