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

# Entity-Lebenszyklus: Benutzer- und Unternehmensstatus

> Zustände und Übergänge der Didit-Entitäten Benutzer und Unternehmen: Erstellung, Verifizierung, ACTIVE/FLAGGED/BLOCKED und Löschung. Pay-per-Call.

Jede Benutzer- und Unternehmensentität in Didit durchläuft einen vorhersehbaren Lebenszyklus. Dieser Lebenszyklus ist der Schlüssel zur Gestaltung Ihrer Abläufe für Onboarding, laufende Überwachung und Behebung.

## Lebenszyklusdiagramm

```mermaid theme={null}
stateDiagram-v2
    [*] --> ACTIVE: Created (API, console, or auto from session)
    ACTIVE --> FLAGGED: Rule match / analyst review / suspicious pattern
    FLAGGED --> ACTIVE: Analyst clears / remediation completed
    ACTIVE --> BLOCKED: Manual block / blocklist match
    FLAGGED --> BLOCKED: Investigation concludes blocked
    BLOCKED --> ACTIVE: Manual unblock (analyst only)
```

## Status im Detail

| Status | Bedeutung | Durchsetzung |
| - | - | - |
| `ACTIVE` | Standard, Entität ist unbeanstandet | Neue Sitzungen und Transaktionen laufen über Ihre konfigurierten Workflows und Regeln |
| `FLAGGED` | Entität hat ein offenes Problem, das eine Prüfung erfordert | Neue Sitzungen laufen weiterhin, werden aber standardmäßig auf `IN_REVIEW` gesetzt; Transaktionen können je nach Regeln automatisch eskaliert werden |
| `BLOCKED` | Entität ist von Ihrer Plattform gesperrt | Neue Sitzungen werden automatisch abgelehnt; neue Transaktionen werden automatisch abgelehnt; für diese `vendor_data` können keine neuen Sitzungslinks erstellt werden |

> [!NOTE]
>
> Durch eine Statusänderung über `PATCH /v3/users/{vendor_data}/update-status/` oder `PATCH /v3/businesses/{vendor_data}/update-status/` wird ein Webhook (`user.status.updated` / `business.status.updated`) ausgelöst, damit nachgelagerte Systeme in Echtzeit reagieren können.

## Phasen des Lebenszyklus

**1. Erstellung**

Eine Entität wird auf eine von drei Arten erstellt:

* **Automatisch erstellt**, wenn Sie eine Sitzung mit einer neuen `vendor_data` starten. Die Entität wird im Status `ACTIVE` angelegt.
* **Vorab per API erstellt** über `POST /v3/users/create/` oder `POST /v3/businesses/create/`. Der Status ist standardmäßig `ACTIVE`.
* **In der Konsole erstellt** durch einen Compliance-Beauftragten. Der Status beginnt mit `ACTIVE`, sofern der Beauftragte nichts anderes angibt.

Jede Entität erhält eine von Didit generierte `uuid` und eine kundeneigene `vendor_data`-Kennung.

**2. Verifizierung**

Sitzungen werden über `vendor_data` mit der Entität verknüpft. Jede Sitzung läuft über Ihren konfigurierten [Workflow](https://docs.didit.me/de/console/workflows.md): Ausweisverifizierung, Liveness-Erkennung, Gesichtsabgleich, AML, Dokumente, Registerabfrage für KYB und so weiter.

Abgeschlossene Sitzungen aktualisieren die aggregierten Zähler der Entität:

* `session_count`, `approved_count`, `declined_count`, `in_review_count`
* `features`-Map: der jeweils neueste Status jeder Funktion über alle Sitzungen (z. B. `{ "id_verification": "APPROVED", "aml": "IN_REVIEW" }`)
* Profilfelder werden aus der neuesten genehmigten Sitzung übernommen (z. B. `full_name`, `date_of_birth`, `portrait_image`).

**3. Aktive Nutzung**

Sobald eine Entität eine oder mehrere genehmigte Sitzungen hat, können Sie:

* **Transaktionen einreichen**, die sich über `vendor_data` im Transaktions-Payload auf die Entität beziehen
* **Laufende AML-Überwachung ausführen**: periodische Neuprüfungen anhand von Sanktionslisten sowie Listen politisch exponierter Personen und negativer Medienberichte
* **Erneut verifizieren nach Zeitplan**: neue Sitzungen für dieselbe `vendor_data` in regelmäßigen Abständen erstellen
* **Risikosignale aggregieren** über Sitzungen und Transaktionen

**4. Statusübergänge**

Der Status einer Entität ändert sich automatisch oder manuell.

**Automatische Übergänge**

* `ACTIVE → FLAGGED`, wenn eine Transaktion den Prüfschwellenwert überschreitet oder eine Regel die Entität auf eine Beobachtungsliste setzt.
* `ACTIVE → BLOCKED`, wenn eine Gesichtsbiometrie mit einem Eintrag der Sperrliste übereinstimmt.

Eine abgelehnte Sitzung setzt die Entität nicht auf die Sperrliste, daher bleibt ihr Status unverändert. Die Aufnahme einer abgelehnten Person auf die Sperrliste ist ein manueller Schritt: Fügen Sie den Eintrag über die [Sperrlistenseite](https://docs.didit.me/de/console/blocklist-users.md) oder die [Lists-API](https://docs.didit.me/de/management-api/lists/overview.md) hinzu. Ein Eintrag vom Typ `USER` (die `vendor_data`) setzt den Status auf `BLOCKED`.

**Manuelle Übergänge** erfolgen, wenn ein Analyst den Status in der Konsole ändert oder wenn Sie den Endpoint `update-status` aufrufen.

Jeder Übergang löst einen Webhook `user.status.updated` oder `business.status.updated` aus.

**5. Löschung**

Entitäten werden über `POST /v3/users/delete/` oder `POST /v3/businesses/delete/` (Batch) gelöscht. Der Entitätsdatensatz wird dauerhaft entfernt. Beim Löschen eines Benutzers werden außerdem alle [biometrischen Templates](https://docs.didit.me/de/management-api/biometric-templates/overview.md) entfernt, die nach dem Löschen der Sitzung für ihn aufbewahrt wurden. Dadurch wird die Person bei der Duplikaterkennung und der Gesichtssuche nicht mehr als Übereinstimmung erkannt.

Verifizierungssitzungen werden von diesen Endpoints nicht erfasst, ebenso wenig Transaktionen. Löschen Sie Sitzungen mit [Sitzung löschen](https://docs.didit.me/de/sessions-api/delete-session.md) oder [Sitzungen im Batch löschen](https://docs.didit.me/de/management-api/sessions/batch-delete.md). Transaktionen werden in der Konsole gelöscht.

## Aktivitätszeitstempel

Entitäten erfassen Aktivitäten, damit Sie veraltete oder aktive Profile erkennen können:

| Zeitstempel | Aktualisiert, wenn |
| - | - |
| `first_session_at` | Die erste Sitzung für diese Entität wurde erstellt |
| `last_session_at` | Die neueste Sitzung wurde erstellt oder aktualisiert |
| `last_activity_at` | Eine Änderung ist erfolgt: Sitzung, Transaktion, Statusänderung oder Profilaktualisierung |

Verwenden Sie diese Zeitstempel, um inaktive Entitäten zu filtern, erneute Verifizierungen zu planen oder die laufende Überwachung auszulösen.

## Ereignisse während des Lebenszyklus

| Lebenszyklusphase | Ausgelöste Webhooks |
| - | - |
| Erstellung (automatisch aus einer Sitzung) | `status.updated` (Sitzung), `user.data.updated` oder `business.data.updated` |
| Verifizierung | `status.updated` (Sitzung), `data.updated` |
| Statusänderung | `user.status.updated` oder `business.status.updated` |
| Transaktion eingereicht | `transaction.created` |
| Transaktionsstatus geändert | `transaction.status.updated` |

Informationen zu den Payload-Strukturen und zur Zustellung finden Sie unter [Entitäts-Webhooks](https://docs.didit.me/de/entities/webhooks.md).

## Nächste Schritte

> [card] [Verknüpfung von Vendor-Daten](https://docs.didit.me/de/entities/vendor-data-linking.md)
>
> Wie `vendor_data` Sitzungen, Transaktionen und Entitäten miteinander verknüpft.

> [card] [Benutzervorgänge](https://docs.didit.me/de/entities/users/operations.md)
>
> Benutzer-Entitäten erstellen, aktualisieren, Status ändern und löschen.

> [card] [Unternehmensvorgänge](https://docs.didit.me/de/entities/businesses/operations.md)
>
> Unternehmens-Entitäten erstellen, aktualisieren, Status ändern und löschen.


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