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

# Verifizierungsstatus: Sitzungslebenszyklus & Codes

> Alle Didit-Sitzungsstatus im Detail: Genehmigt, Abgelehnt, In Prüfung und mehr. Entscheidungen, Wiederholungsversuche und Webhooks handhaben.

Jede Verifizierungssitzung durchläuft eine Reihe von Statuswerten. Wenn Sie diese verstehen, können Sie den Fortschritt der Benutzer überwachen, Compliance-Entscheidungen automatisieren und die Konversion optimieren.

Dieses Enum ist die zentrale Referenz für die Zeichenfolgen, die von `GET /v3/session/<id>/decision/` und jedem Didit-Webhook zurückgegeben werden.

***

## Alle Statuswerte

> [!NOTE]
>
> Jeder Status ist ein **exakter String**, der von der Didit-API und Webhooks zurückgegeben wird. Verwenden Sie in Ihrem Code immer einen strikten Zeichenfolgenabgleich (z. B. `=== "In Review"`) – bei diesen Werten wird zwischen Groß- und Kleinschreibung unterschieden und sie enthalten Leerzeichen. Der Wert `Kyc Expired` verwendet zudem nur ein einzelnes großes `K` (nicht `KYC`).

| Status | String-Wert | Beschreibung |
| - | - | - |
| Not Started | `"Not Started"` | Sitzung erstellt, Benutzer hat den Link noch nicht geöffnet |
| In Progress | `"In Progress"` | Benutzer führt die Verifizierung aktiv durch |
| Approved | `"Approved"` | Alle Prüfungen bestanden – Identität verifiziert |
| Declined | `"Declined"` | Eine oder mehrere Prüfungen sind fehlgeschlagen |
| In Review | `"In Review"` | Für manuelle Compliance-Prüfung markiert |
| Awaiting User | `"Awaiting User"` | Warten darauf, dass eine oder mehrere Parteien ihre Verifizierung abschließen (KYB) |
| Resubmitted | `"Resubmitted"` | Benutzer wurde aufgefordert, bestimmte Schritte zu wiederholen |
| Expired | `"Expired"` | Zeitüberschreitung der Sitzung, bevor der Benutzer den Link geöffnet hat |
| Abandoned | `"Abandoned"` | Benutzer hat begonnen, aber nicht rechtzeitig abgeschlossen |
| KYC Expired | `"Kyc Expired"` | Zuvor genehmigte Sitzung, deren verifiziertes Dokument sein Ablaufdatum überschritten hat |

***

## Sitzungsstatus

> [accordion] Nicht gestartet — "Not Started"
>
> **API-Wert:** `"Not Started"`
>
> Die Sitzung wurde über die API erstellt, aber der Benutzer **hat den Verifizierungslink noch nicht geöffnet**.
>
> * **Was zu tun ist:** Warten Sie, bis der Benutzer beginnt, oder senden Sie eine Erinnerung, wenn zu viel Zeit vergeht.
> * **Geht über in:** `"In Progress"`, `"Expired"`

> [accordion] In Bearbeitung — "In Progress"
>
> **API-Wert:** `"In Progress"`
>
> Der Benutzer hat den Link geöffnet und **schließt aktiv Verifizierungsschritte ab** (Dokumentenerfassung, Liveness-Erkennung etc.).
>
> * **Was zu tun ist:** Keine Aktion erforderlich — der Benutzer durchläuft den Ablauf.
> * **Geht über in:** `"Approved"`, `"Declined"`, `"In Review"`, `"Abandoned"`

> [accordion] Genehmigt — "Approved"
>
> **API-Wert:** `"Approved"`
>
> Alle Verifizierungsprüfungen **wurden erfolgreich bestanden**. Die Identität des Benutzers wurde verifiziert.
>
> * **Was zu tun ist:** Gewähren Sie dem Benutzer Zugriff, aktualisieren Sie sein Profil und speichern Sie die Entscheidungsdaten.
> * **Webhook enthält:** Vollständiges `decision`-Objekt mit allen Funktionsergebnissen.
> * **Geht über in:** `"Kyc Expired"` (wenn das Ablaufdatum des verifizierten Dokuments überschritten wird — Standardeinstellung, sofern der **Expiration mode** für dieses Land und diesen Dokumenttyp nicht auf **Allow expired** gesetzt ist). Ein Prüfer oder der Update-Status-Endpoint kann den Status auch auf `"Declined"` oder `"Resubmitted"` setzen.

> [accordion] Abgelehnt — "Declined"
>
> **API-Wert:** `"Declined"`
>
> Eine oder mehrere Verifizierungsprüfungen sind **fehlgeschlagen**. Der Benutzer hat die Verifizierung nicht bestanden.
>
> * **Was zu tun ist:** Benachrichtigen Sie den Benutzer. Fordern Sie optional eine erneute Einreichung an, falls das Problem behebbar ist.
> * **Webhook enthält:** Vollständiges `decision`-Objekt mit Warnungen, die das Fehlschlagen erklären.
> * **Geht über in:** `"Resubmitted"` (falls von einem Prüfer angefordert). Ein Prüfer oder der Update-Status-Endpoint kann den Status auch auf `"Approved"` setzen.

> [accordion] In Prüfung — "In Review"
>
> **API-Wert:** `"In Review"`
>
> Automatische Prüfungen haben **Warnungen ausgelöst, die eine manuelle Prüfung erfordern**. Ein Compliance-Prüfer muss die endgültige Entscheidung treffen.
>
> * **Was zu tun ist:** Ein Prüfer sollte die Sitzung in der Console öffnen und sie genehmigen, ablehnen oder eine erneute Einreichung anfordern.
> * **Webhook enthält:** Vollständiges `decision`-Objekt mit Warnungen.
> * **Geht über in:** `"Approved"`, `"Declined"`, `"Resubmitted"`

> [accordion] Warten auf Benutzer — "Awaiting User"
>
> **API-Wert:** `"Awaiting User"`
>
> Wird in **KYB-Sitzungen (Unternehmensverifizierung)** verwendet, wenn im Schritt „Key People“ die Liste der Parteien übermittelt und untergeordnete KYC- / KYB-Sitzungen erstellt wurden. Die übergeordnete Sitzung wartet, bis **alle erforderlichen Parteien ihre individuelle Verifizierung abgeschlossen haben**.
>
> * **Was zu tun ist:** Überwachen Sie die Status der untergeordneten KYC-Sitzungen. Sobald alle erforderlichen Parteien fertig sind (genehmigt, abgelehnt oder abgelaufen), fasst die übergeordnete Sitzung diese automatisch zu ihrem finalen Status zusammen.
> * **Webhook enthält:** Die aktuelle Liste der Parteien und die Status ihrer untergeordneten Sitzungen.
> * **Geht über in:** `"Approved"`, `"Declined"`, `"In Review"` (sobald alle untergeordneten Sitzungen einen Endstatus erreicht haben)
> * **Übergang von:** `"In Progress"` (nachdem der Schritt „Key People“ übermittelt wurde)
> * **Hinweis:** Wenn eine untergeordnete KYC-Sitzung erneut eingereicht wird, kehrt die übergeordnete Sitzung zu `"Awaiting User"` zurück, bis die erneut eingereichte Sitzung abgeschlossen ist. Ein `"Declined"` beim KYB Registry Check hat Vorrang vor `"Awaiting User"`.

> [accordion] Erneut eingereicht — "Resubmitted"
>
> **API-Wert:** `"Resubmitted"`
>
> Ein Prüfer hat den Benutzer aufgefordert, **bestimmte Verifizierungsschritte zu wiederholen** (z. B. ein unscharfes Dokumentenfoto neu aufzunehmen).
>
> * **Was zu tun ist:** Warten Sie, bis der Benutzer die erneut durchzuführenden Schritte abgeschlossen hat. Das System führt automatisch eine Neubewertung durch.
> * **Webhook enthält:** `resubmit_info`-Objekt mit der Liste der zu wiederholenden Funktionen und Gründen.
> * **Geht über in:** `"Approved"`, `"Declined"`, `"In Review"` oder `"Abandoned"`, wenn das Sitzungszeitfenster endet, bevor die Person die Schritte wiederholt.

> [accordion] Abgelaufen — "Expired"
>
> **API-Wert:** `"Expired"`
>
> Die Sitzung **ist abgelaufen, bevor der Benutzer den Verifizierungslink geöffnet hat**.
>
> * **Was zu tun ist:** Erstellen Sie eine neue Sitzung und senden Sie dem Benutzer einen neuen Link.
> * **Terminaler Status** — keine weiteren Übergänge.

> [accordion] Abgebrochen — "Abandoned"
>
> **API-Wert:** `"Abandoned"`
>
> Der Benutzer hat die Verifizierung **begonnen, aber nicht innerhalb des zulässigen Zeitrahmens abgeschlossen**.
>
> * **Was zu tun ist:** Senden Sie eine Erinnerung oder erstellen Sie eine neue Sitzung.
> * **Keine automatischen Übergänge.** Ein Prüfer oder `PATCH /v3/session/{sessionId}/update-status/` kann den Status weiterhin auf `"Approved"`, `"Declined"` oder `"Resubmitted"` setzen.

> [accordion] KYC abgelaufen — "Kyc Expired"
>
> **API-Wert:** `"Kyc Expired"`
>
> Das während der Sitzung verifizierte Dokument hat **sein eigenes Ablaufdatum überschritten**. Auslöser ist dieses Datum, kein ab der Genehmigung gemessenes Zeitfenster, und es wird zuvor keine Warnung gesendet.
>
> * **Was zu tun ist:** Bitten Sie den Benutzer, sich in einer neuen Sitzung erneut zu verifizieren. `status.updated` übermittelt den Übergang, und das Ergebnis der Ausweisverifizierung enthält eine `DOCUMENT_EXPIRED`-Warnung.
> * **Gesteuert über:** den **Expiration mode** dieses Landes und Dokumenttyps unter *Ausweisverifizierung → Additional settings by country & document type* — **Reject expired** (Standard) überwacht das Dokument, **Allow expired** bedeutet, dass die Sitzung nie diesen Status erhält.
> * **Keine automatischen Übergänge.** Ein Prüfer oder `PATCH /v3/session/{sessionId}/update-status/` kann den Status weiterhin auf `"Approved"`, `"Declined"` oder `"Resubmitted"` setzen.

***

## Statusübergänge

| Von | Nach | Auslöser |
| - | - | - |
| `"Not Started"` | `"In Progress"` | Benutzer öffnet den Verifizierungslink |
| `"Not Started"` | `"Expired"` | Sitzungs-TTL läuft ab, bevor der Benutzer den Link öffnet |
| `"In Progress"` | `"Approved"` | Alle automatisierten Prüfungen sind erfolgreich |
| `"In Progress"` | `"Declined"` | Eine oder mehrere Prüfungen schlagen fehl |
| `"In Progress"` | `"In Review"` | Prüfungen lösen Warnungen aus, die eine menschliche Prüfung erfordern |
| `"In Progress"` | `"Awaiting User"` | KYB-Schritt für Schlüsselpersonen übermittelt; übergeordnete Sitzung wartet auf untergeordnete KYC-Parteien |
| `"In Progress"` | `"Abandoned"` | Benutzer schließt den Vorgang nicht innerhalb des Zeitrahmens ab |
| `"Awaiting User"` | `"Approved"` | Alle erforderlichen KYB-Parteien schließen ab und aggregierte Prüfungen sind erfolgreich |
| `"Awaiting User"` | `"Declined"` | Eine erforderliche Partei wird abgelehnt oder die KYB-Registerprüfung schlägt fehl |
| `"Awaiting User"` | `"In Review"` | Aggregiertes KYB-Ergebnis erfordert eine manuelle Prüfung |
| `"In Review"` | `"Approved"` | Prüfer genehmigt manuell |
| `"In Review"` | `"Declined"` | Prüfer lehnt manuell ab |
| `"In Review"` | `"Resubmitted"` | Prüfer fordert die Wiederholung bestimmter Schritte an |
| `"Declined"` | `"Resubmitted"` | Prüfer fordert die Wiederholung bestimmter Schritte an |
| `"Approved"` | `"Resubmitted"` | Prüfer fordert die Wiederholung bestimmter Schritte an |
| `"Approved"` | `"Declined"` | Prüfer oder API legt die jeweils andere Entscheidung fest |
| `"Declined"` | `"Approved"` | Prüfer oder API legt die jeweils andere Entscheidung fest |
| `"Abandoned"`, `"Kyc Expired"` | `"Approved"`, `"Declined"`, `"Resubmitted"` | Prüfer oder API entscheidet über eine Sitzung, die ohne Entscheidung endete |
| `"Resubmitted"` | `"Abandoned"` | Das Sitzungszeitfenster endet, bevor die Person die Schritte wiederholt |
| `"Resubmitted"` | `"Approved"` | Erneut eingereichte Schritte bestehen alle Prüfungen |
| `"Resubmitted"` | `"Declined"` | Erneut eingereichte Schritte schlagen fehl |
| `"Resubmitted"` | `"In Review"` | Erneut eingereichte Schritte lösen neue Warnungen aus |
| `"Resubmitted"` (untergeordnetes KYB) | `"Awaiting User"` (übergeordnetes KYB) | Übergeordnete Sitzung geht wieder in den Wartezustand über, bis die untergeordnete Sitzung abgeschlossen ist |
| `"Approved"` | `"Kyc Expired"` | Das Ablaufdatum des verifizierten Dokuments wird überschritten (Ablaufmodus ist **Reject expired**) |

### Lebenszyklus-Diagramm

```mermaid theme={null}
flowchart LR
    NS["Not Started"] --> IP["In Progress"]
    NS --> EX["Expired"]
    IP --> AP["Approved"]
    IP --> DC["Declined"]
    IP --> IR["In Review"]
    IP --> AU["Awaiting User<br/>(KYB only)"]
    IP --> AB["Abandoned"]
    AU --> AP
    AU --> DC
    AU --> IR
    IR --> AP
    IR --> DC
    IR --> RS["Resubmitted"]
    DC --> RS
    AP --> RS
    AP <--> DC
    AB --> AP
    AB --> DC
    AB --> RS
    KE --> AP
    KE --> DC
    KE --> RS
    RS --> AB
    RS --> AP
    RS --> DC
    RS --> IR
    AP --> KE["Kyc Expired"]
```

***

## Terminal vs. Nicht-Terminal

| Kategorie | Statuswerte | Bedeutung |
| - | - | - |
| **Beschlossen** | `"Approved"`, `"Declined"`, `"Kyc Expired"` | Die Prüfungen führten zu einer Entscheidung und nichts ändert diese von selbst, außer `"Approved"` → `"Kyc Expired"`, wenn das Ablaufdatum des verifizierten Dokuments überschritten wird. Ein Prüfer oder der Update-Status-Endpoint kann die Entscheidung weiterhin ändern. |
| **Nicht-Terminal** | `"Not Started"`, `"In Progress"`, `"Resubmitted"`, `"Awaiting User"` | Weiterhin aktiv — wartet auf Benutzeraktion, untergeordnete Sitzungen oder Verarbeitung. |
| **Handlungsbedarf** | `"In Review"` | Erfordert manuelles Eingreifen Ihres Teams. |
| **Inaktiv** | `"Expired"`, `"Abandoned"` | Endete ohne Verifizierungsentscheidung. `"Expired"` ändert sich nie; ein Prüfer kann weiterhin über eine Sitzung mit Status `"Abandoned"` entscheiden. |

***

## Statuswerte in Ihrem Code verarbeiten

Verwenden Sie Webhooks oder die [Retrieve Session API](https://docs.didit.me/de/sessions-api/retrieve-session.md), um auf Statusänderungen zu reagieren.

> [!WARNING]
>
> Statuswerte sind **exakte, groß-/kleinschreibungssensitive Zeichenketten mit Leerzeichen**. Zum Beispiel `"In Review"` (nicht `"in_review"` oder `"IN_REVIEW"`). Verwenden Sie beim Abgleich immer strikte Gleichheit (`===`).

```javascript theme={null}
// All ten possible status string values (StatusChoices, source of truth):
// "Not Started"  | "In Progress" | "Approved"     | "Declined" |
// "In Review"    | "Resubmitted" | "Awaiting User"|
// "Expired"      | "Abandoned"   | "Kyc Expired"

async function handleWebhook(webhook) {
  const { status, vendor_data: vendorData } = webhook;

  switch (status) {
    case "Not Started":
      // Session created but user hasn't opened the link yet
      break;

    case "In Progress":
      // User is actively completing verification steps
      break;

    case "Approved":
      // All checks passed — grant access
      await db.users.update(vendorData, {
        verified: true,
        verifiedAt: new Date(),
        decision: webhook.decision,
      });
      break;

    case "Declined":
      // Verification failed — notify user
      await db.users.update(vendorData, {
        verificationStatus: "declined",
        declineReasons: webhook.decision?.warnings,
      });
      break;

    case "In Review":
      // Needs manual review by compliance team
      await db.users.update(vendorData, {
        verificationStatus: "pending_review",
      });
      break;

    case "Awaiting User":
      // KYB parent waiting for all child KYC parties to finish
      await db.users.update(vendorData, {
        verificationStatus: "awaiting_kyb_parties",
      });
      break;

    case "Resubmitted":
      // User will redo specific steps
      await db.users.update(vendorData, {
        verificationStatus: "resubmission_pending",
        resubmitInfo: webhook.resubmit_info,
      });
      break;

    case "Abandoned":
      // User started but didn't finish — send reminder
      await sendReminderEmail(vendorData);
      break;

    case "Expired":
    case "Kyc Expired":
      // Session expired — create a new one
      await createNewSession(vendorData);
      break;
  }
}
```

***

## Erneute Einreichung

Der Status **Resubmitted** ermöglicht es Ihrem Compliance-Team, Benutzern eine zweite Chance zu geben, ohne eine neue Sitzung zu erstellen.

**1. Prüfer leitet erneute Einreichung ein**

Öffnen Sie in der Konsole eine Sitzung mit Status `In Review` oder `Declined` und klicken Sie auf **Erneute Einreichung anfordern**. Wählen Sie aus, welche Schritte wiederholt werden müssen.

**2. Bisherige Daten werden archiviert**

Das System setzt die ausgewählten Funktionen zurück und markiert vorherige Daten als `previous_attempt` — wodurch der vollständige Audit-Trail erhalten bleibt.

**3. Benutzer wird benachrichtigt**

Wenn eine E-Mail verfügbar ist, erhält der Benutzer eine lokalisierte E-Mail mit einem direkten Link zur Fortsetzung.

**4. Benutzer wiederholt bestimmte Schritte**

Der Benutzer wiederholt nur die Schritte, die gekennzeichnet wurden — nicht die gesamte Verifizierung.

**5. System bewertet neu**

Nach Abschluss geht die Sitzung automatisch in `"Approved"`, `"Declined"` oder `"In Review"` über.

### Webhook-Payload für erneute Einreichung

```json theme={null}
{
  "session_id": "uuid-of-the-session",
  "status": "Resubmitted",
  "resubmit_info": {
    "nodes_to_resubmit": [
      { "node_id": "feature_ocr", "feature": "OCR" },
      { "node_id": "feature_liveness", "feature": "LIVENESS" }
    ],
    "reasons": {
      "feature_ocr": "DOCUMENT_EXPIRED",
      "feature_liveness": "LOW_LIVENESS_SCORE"
    }
  }
}
```

`reasons` ordnet jede erneut eingereichte `node_id` dem Warnungscode des relevantesten Logs für diesen Schritt zu (dieselben Codes, die die [Entscheidung](https://docs.didit.me/de/reference/data-models.md) meldet), sodass Sie dies Ihren eigenen Texten zuordnen können. Dies ist auch der Code, den der Bildschirm für die erneute Einreichung des gehosteten Flows und die E-Mail zur erneuten Einreichung für den Benutzer lokalisieren, mit Ausnahme von Warnungen, die ein Screening- oder Betrugssignal offenlegen würden (Duplikate, AML, Sperrliste, organisationsübergreifende Prüfungen, Standortintegrität und ähnliches): Für diese sieht die Person einen generischen Grund, und `resubmit_info.reasons` in Ihrem Webhook enthält immer den echten Code. Ein Schritt ohne aufgezeichnete Warnung hat keinen Eintrag.

### Welche Funktionen können erneut eingereicht werden?

Jede Funktion mit einem nicht genehmigten Status: **Declined**, **In Review**, **Not Finished**, **Not Started** oder **Expired**.

> [!TIP]
>
> Sie können für dieselbe Sitzung mehrfach eine erneute Einreichung anfordern. Jeder Zyklus archiviert die Daten des vorherigen Versuchs, sodass Sie vollständige Transparenz über die Verifizierungshistorie des Benutzers haben.

***

## Bewährte Vorgehensweisen

> [card] „In Prüfung“ überwachen
>
> Richten Sie Alerts (E-Mail oder Slack) in Ihrer Didit Console ein, um benachrichtigt zu werden, wenn Sitzungen eine manuelle Prüfung erfordern.

> [card] Erneute Einreichung bevorzugen
>
> Wenn das Problem behebbar ist (unscharfes Foto, falsche Dokumentenseite), fordern Sie eine erneute Einreichung an, anstatt abzulehnen. Dies verbessert die Konversionsrate.

> [card] Abbrüche nachverfolgen
>
> Hohe Raten abgebrochener oder abgelaufener Sitzungen können auf Reibungspunkte in der UX hinweisen. Ziehen Sie in Betracht, die Sitzungs-TTL anzupassen oder die Benutzerführung zu verbessern.

> [card] Idempotente Handler
>
> Bei Webhooks kann es zu Wiederholungsversuchen kommen. Verwenden Sie `session_id` als eindeutigen Schlüssel, um sicherzustellen, dass Sie jede Statusänderung nur einmal verarbeiten.

> [!WARNING]
>
> Verifizieren Sie Webhook-Signaturen immer, bevor Sie Payloads verarbeiten. Didit bietet drei Methoden: `X-Signature`, `X-Signature-V2` (empfohlen) und das veraltete `X-Signature-Simple`, welches nur die Nachrichtenhülle und niemals den Inhalt von `decision` authentifiziert. Details finden Sie unter [Webhooks](https://docs.didit.me/de/integration/webhooks.md#signaturprüfung).


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