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

# Benutzer-KYC-Historie: Sitzungen & erneute Verifizierung

> Didit-Verifizierungssitzungen eines Benutzers abrufen, Ergebnisse prüfen, erneute Verifizierung auslösen und Compliance-Berichte exportieren.



Prompt zum KYC-Verlauf
        Prompt in die Zwischenablage kopieren



      
      

\<pre>

\````# Goal — read a user's full KYC history and trigger re-verification

Every KYC session a user has ever run stays permanently linked to the User entity via `vendor_data`. The session list endpoint is the entry point; the decision endpoint is the detail view.

\## List every session for a user

\```bash
curl -G https://verification.didit.me/v3/sessions/ \
-H "x-api-key: $DIDIT_API_KEY" \
\--data-urlencode "vendor_data=user-42" \
\--data-urlencode "page_size=50"
\```

Response covers every status (approved, declined, in review, abandoned, expired). Paginate with the `next` cursor / `page` param until empty.

\## Inspect a single session decision

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

V3 returns plural arrays — always iterate them:

\- `id_verifications[]`
\- `liveness_checks[]`
\- `face_matches[]`
\- `aml_screenings[]`
\- `nfc_verifications[]`
\- `proof_of_address_checks[]`

Never assume V2 singular fields.

\## Trigger re-verification

Annual re-KYC, document expiry, trigger-based re-checks — same pattern: create a new session against the same `vendor_data`. The new session attaches to the existing User entity and updates the `features` map on completion.

\```bash
curl -X POST https://verification.didit.me/v3/session/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{"workflow_id": "wf_reverification", "vendor_data": "user-42"}'
\```

\## Fast path — fully verified right now?

The User entity carries a `features` map summarising the **latest** state of each feature across all sessions:

\```bash
curl https://verification.didit.me/v3/users/user-42/ \
-H "x-api-key: $DIDIT_API_KEY"
\# data.features = { id_verification: "APPROVED", liveness: "APPROVED", aml: "IN_REVIEW", ... }
\```

Use `features` for "is the user verified right now?" without iterating every session.

\## Generate a PDF for any session

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

\## Generate the full user history PDF

One file with a cover page plus the report of every reportable session (`Approved`, `Declined`, `In Review`, `Kyc Expired`) of the user, capped at the 20 most recent. Same document as Console → User detail → Actions → Download PDF. Synchronous render: use a 120s read timeout.

\```bash
curl --fail https://verification.didit.me/v3/users/user-42/generate-pdf/ \
-H "x-api-key: $DIDIT_API_KEY" \
-o user-history.pdf
\```

404 = no such user in this application; 403 = user has no reportable session yet.

\## Resubmit vs new session

\| Scenario | Use |
\|---|---|
\| Declined for fixable reason (blurry ID, bad lighting) | Resubmit the existing session (re-deliver `url`); the workflow advances through resubmission |
\| Annual / trigger-based re-KYC | Create a brand new session via `POST /v3/session/` |
\| Transaction-rule triggered remediation | The transaction creates a remediation session automatically (`Awaiting User` status) |

\## Share a session with a partner (Reusable KYC)

\```bash
\# Issue a shareable token
curl -X POST https://verification.didit.me/v3/session/$SESSION_ID/share/ \
-H "x-api-key: $DIDIT_API_KEY"

\# Receiver imports the shared session
curl -X POST https://verification.didit.me/v3/session/import-shared/ \
-H "x-api-key: $RECEIVER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"share_token": "..."}'
\```

\## Failure modes

\- `404` on the user — wrong `vendor_data` casing or no sessions yet.
\- Empty `results[]` — no sessions for this `vendor_data` in this application.
\- Stale signed image URLs — re-fetch the decision.
\- Sharing rejected — receiving application must have Reusable KYC enabled.

\## Sources of truth

\- /sessions-api/retrieve-session — V3 decision schema
\- /management-api/users/generate-pdf — full user history PDF
\- /reference/data-models — per-feature plural-array contract
\- /core-technology/reusable-kyc/overview — share / import pattern
\- /entities/users/data-model — features map computation
\- /integration/integration-prompt — canonical end-to-end prompt````

\</pre>



      
      

Einfügen in

Jede KYC-Sitzung zur Benutzerverifizierung, die ein Benutzer je durchgeführt hat, bleibt dauerhaft mit seiner Benutzer-Entität verknüpft. Sie können den vollständigen Verlauf abrufen, einzelne Sitzungsergebnisse prüfen, eine erneute Verifizierung auslösen und Compliance-Berichte exportieren.## Alle Sitzungen eines Benutzers auflistenFiltern Sie die Sitzungsliste nach `vendor_data`:```bash theme={null}
curl -G https://verification.didit.me/v3/sessions/ \
  -H "x-api-key: YOUR_API_KEY" \
  --data-urlencode "vendor_data=user-42" \
  --data-urlencode "page_size=50"
```Die Antwort enthält jede Sitzung, unabhängig von ihrem Status: genehmigt, abgelehnt, in Prüfung, abgebrochen oder abgelaufen.## Die Funktionsaggregationen verstehenDie `features`-Map der Benutzer-Entität spiegelt den **neuesten** Status jeder Funktion über alle Sitzungen hinweg wider:```json theme={null}
"features": {
  "id_verification": "APPROVED",
  "liveness": "APPROVED",
  "face_match": "APPROVED",
  "aml": "IN_REVIEW"
}
```Nutzen Sie dies als schnellen Weg, um die Frage „Ist der Benutzer gerade verifiziert?“ zu beantworten. Für den vollständigen Verlauf (alle Sitzungen, alle Funktionen, alle Ergebnisse) listen Sie die Sitzungen auf und prüfen jede Entscheidung.## Eine einzelne Sitzung prüfen```bash theme={null}
curl https://verification.didit.me/v3/session/{session_id}/decision/ \
  -H "x-api-key: YOUR_API_KEY"
```Die Entscheidung enthält:- Ergebnisse je Funktion (Ausweis, Liveness, Gesichtsabgleich, AML, Adressnachweis (POA), NFC usw.)
- Extrahierte Dokumentdaten und Bilder (signierte URLs)
- AML-Treffer mit Übereinstimmungswert und Risiko-Score
- Geräte- und IP-Analyse sowie Gerätekontext
- Notizen des Prüfers und manuelle AktionenDas vollständige Schema finden Sie unter [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md).## Erneute Verifizierung auslösenWenn ein Benutzer sich erneut verifizieren muss (z. B. bei einer jährlichen KYC-Erneuerung, Ablauf eines Dokuments oder einer auslöserbasierten erneuten Prüfung):```bash theme={null}
curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "wf_reverification",
    "vendor_data": "user-42"
  }'
```Die neue Sitzung wird derselben Benutzer-Entität zugeordnet. Nach Abschluss aktualisiert sich die `features`-Map der Entität und spiegelt die neuen Ergebnisse wider.## Erneute Einreichung oder neue Sitzung| Szenario | Verwendung |
| - | - |
| Die Sitzung des Benutzers wurde wegen eines behebbaren Problems abgelehnt (unscharfer Ausweis, schlechte Beleuchtung) | [Erneut einreichen](https://docs.didit.me/de/console/manual-review.md): dieselbe Sitzung, neuer Upload |
| Vollständige erneute Verifizierung oder periodisches erneutes KYC | Erstellen Sie eine völlig neue Sitzung |
| Nachbesserung, ausgelöst durch eine Transaktionsregel | Die Transaktion erstellt automatisch eine Nachbesserungssitzung (Status `AWAITING_USER`) |## Einen Compliance-Bericht exportierenFür Audits, SARs oder Anfragen von Aufsichtsbehörden erzeugen Sie für jede Sitzung ein PDF:```bash theme={null}
curl https://verification.didit.me/v3/session/{session_id}/generate-pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -o session-report.pdf
```Um den gesamten Verlauf eines Benutzers in einer Datei abzudecken, laden Sie das [PDF des Benutzerverlaufs](https://docs.didit.me/de/management-api/users/generate-pdf.md) herunter: eine Deckblattseite (Profilzusammenfassung, Funktionsstatus, Sitzungsindex), gefolgt vom vollständigen Bericht jeder berichtspflichtigen Sitzung, die älteste zuerst, begrenzt auf die 20 neuesten.```bash theme={null}
curl --fail https://verification.didit.me/v3/users/user-42/generate-pdf/ \
  -H "x-api-key: YOUR_API_KEY" \
  -o user-history.pdf
```Es ist dasselbe Dokument, das die Konsole unter *Users → \[user] → Actions → Download PDF* erzeugt. Für CSV-Massenexporte über viele Benutzer hinweg verwenden Sie den anwendungsweiten Export unter *Review & Operations → Export PDF/CSV*.## Eine Sitzung mit einem Dritten teilenWenn Sie die Verifizierung eines Benutzers mit einer Partner-App teilen möchten (z. B. bei einem Szenario mit wiederverwendbarem KYC), verwenden Sie:- `POST /v3/session/{session_id}/share/` erzeugt ein teilbares Token.
- `POST /v3/session/import-shared/` importiert eine geteilte Sitzung auf der empfangenden Seite.Das vollständige Muster finden Sie unter [Wiederverwendbares KYC](https://docs.didit.me/de/core-technology/reusable-kyc/overview.md).## Historienbasierte WorkflowsNutzen Sie den Sitzungsverlauf, um Compliance-Entscheidungen besser zu steuern:- **Schritte überspringen**, wenn der Benutzer innerhalb von N Tagen bereits eine genehmigte Liveness-Prüfung hat.
- **Zusätzliche Prüfungen anfordern**, wenn die neueste Sitzung des Benutzers abgelehnt wurde.
- **Markieren**, wenn die Anzahl der Sitzungen eines Benutzers unerwartet stark ansteigt.
- **AML-Nachprüfungen überwachen** im Rahmen der [laufenden Überwachung](https://docs.didit.me/de/core-technology/aml-screening/continuous-monitoring-aml-screening.md).## Nächste Schritte> [card] [Datenmodell](https://docs.didit.me/de/entities/users/data-model.md)
>
> Wie die Funktions-Map und die Zähler berechnet werden.> [card] [Sitzung abrufen](https://docs.didit.me/de/sessions-api/retrieve-session.md)
>
> Vollständiges Schema der Sitzungsentscheidung.> [card] [Wiederverwendbares KYC](https://docs.didit.me/de/core-technology/reusable-kyc/overview.md)
>
> Verifizierte Daten über Anwendungen hinweg wiederverwenden.


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