> ## 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.
# Benutzerhistorie PDF-API: alle Sitzungen eines Benutzers
> Laden Sie mit Didit einen PDF-Bericht aller Sitzungen eines Benutzers herunter, zugeordnet über vendor_data, für Audits und SARs.
PDF-Prompt zum Benutzerverlauf
Prompt in die Zwischenablage kopieren
\
\`Goal: download one audit-ready PDF containing the full verification history of a Didit user.
Endpoint: GET https://verification.didit.me/v3/users/{vendor_data}/generate-pdf/
Auth header: x-api-key: YOUR_API_KEY
Path param:
\- vendor_data (string, REQUIRED) - your own identifier for the user, the same value you pass when creating sessions. Free-form string, NOT a UUID. URL-encode it; it cannot contain "/".
curl - save the PDF to disk:
curl --fail 'https://verification.didit.me/v3/users/user-abc-123/generate-pdf/' \
-H 'x-api-key: YOUR_API_KEY' \
\--output user-history.pdf
Response:
\- Body is binary (application/pdf). DO NOT parse as JSON.
\- Content-Disposition: attachment; filename=user_{didit_internal_id}.pdf
\- Content: a cover page (profile summary, feature status, session index) followed by the standard report of every included session, oldest first. Each session report is the same document GET /v3/session/{session_id}/generate-pdf/ returns.
\- Only sessions in "Approved", "Declined", "In Review" or "Kyc Expired" are included, capped at the 20 most recent. The cover states when older sessions were left out.
\- Identical to the Console export at User detail → Actions → Download PDF. White-label logo and privacy-policy URL apply when enabled.
\- Rendering is synchronous and takes a few seconds per session: use a read timeout of at least 120s and stream the body to disk.
Failure modes (envelope {"detail": "..."}):
\- 401 - no credentials supplied.
\- 403 - missing API key (a wrong, revoked or expired key gets 401), a Console user token instead of an API key, OR the user exists but has no session in a reportable status ("This user has no sessions in review, declined, approved or kyc expired to report.").
\- 404 - {"detail": "User not found."} - no user with that vendor_data in the application behind the API key. A key can never export a user of another application.
\- 429 - shares the PDF rate limit with the per-session endpoint (50 requests per minute per credential). Wait Retry-After seconds.
Trailing slash: the canonical route ends with "/". Call it as written above.
When to call:
\- Periodic compliance exports of a customer's whole KYC history.
\- SAR / regulator attachments that must cover every verification of one person.
\- Pulling a user's history into your own back office without a Console login.
Related: GET /v3/session/{session_id}/generate-pdf/ for a single session; GET /v3/sessions/?vendor_data=... for the JSON list of sessions.
For end-to-end Didit integration, paste in the full prompt at /integration/integration-prompt.`
\
Einfügen in
## ÜbersichtGibt ein einziges PDF mit dem vollständigen Verifizierungsverlauf einer [User-Entität](https://docs.didit.me/de/entities/users/overview.md) zurück, identifiziert über `vendor_data`.
Es ist dasselbe Dokument, das die Console über **User detail → Actions → Download PDF** erzeugt, sodass Compliance-Teams Exporte automatisieren können, statt pro Benutzer einmal zu klicken.Der Bericht enthält:- **Ein Deckblatt** mit der Profilübersicht (Name, Geburtsdatum, Ausstellungsstaaten, genehmigte E-Mail-Adressen und Telefonnummern), dem aktuellen Status jeder Funktion, den Sitzungszählern und einem Verzeichnis der enthaltenen Sitzungen.
- **Ein vollständiger Sitzungsbericht pro enthaltener Sitzung**, in chronologischer Reihenfolge (älteste zuerst). Jeder davon ist derselbe Bericht, den [PDF generieren](https://docs.didit.me/de/sessions-api/generate-pdf.md) für diese Sitzung allein zurückgibt.## Berechtigte Sitzungen und ObergrenzeNur Benutzerverifizierungs-Sitzungen (KYC) mit dem Status `Approved`, `Declined`, `In Review` oder `Kyc Expired` sind enthalten. Sitzungen mit einem anderen Status (`Not Started`, `In Progress`, `Abandoned`, `Expired`, …) werden übersprungen.Der Bericht ist auf die **20 neuesten** berichtsfähigen Sitzungen begrenzt. Hat ein Benutzer mehr, werden die neuesten 20 aufgenommen, und das Deckblatt gibt an, wie viele ältere Sitzungen weggelassen wurden. Verwenden Sie [Sitzungen auflisten](https://docs.didit.me/de/sessions-api/list-sessions.md) mit dem Filter `vendor_data`, wenn Sie die vollständige Liste als JSON benötigen.## AntwortDer Body ist das PDF selbst (`application/pdf`), kein JSON-Wrapper und keine Download-URL. Der Header `Content-Disposition` lautet `attachment; filename=user_.pdf`, wobei `didit_internal_id` die stabile Didit-Kennung des Benutzers ist.## White-LabelWenn White-Label-Anpassung für Ihre Anwendung aktiviert ist, tragen das Deckblatt und jeder Sitzungsbericht Ihr Logo und Ihre URL der Datenschutzrichtlinie statt Didit-Branding, genau wie beim Endpoint pro Sitzung. Konfigurieren Sie dies unter **Console → Customization**.## Caching und LatenzEs wird nichts gecacht: Jeder Aufruf rendert den Bericht aus den aktuellen Daten neu, sodass ein Bericht, der nach einer manuellen Prüfung angefordert wird, die Entscheidung des Prüfers widerspiegelt. Zwei Aufrufe können byteweise unterschiedliche Dateien erzeugen. Archivieren Sie die heruntergeladene Datei, wenn Sie eine unveränderliche Kopie benötigen.Das Rendering ist synchron und lädt jedes gespeicherte Bild jeder enthaltenen Sitzung herunter, daher kann ein Benutzer mit vielen medienintensiven Sitzungen mehrere Dutzend Sekunden benötigen. Verwenden Sie ein großzügiges Read-Timeout auf dem Client (empfohlen: 120 s) und streamen Sie den Body auf die Festplatte. Die Generierung bricht bei einem serverseitigen Zeitbudget ab, statt so lange weiterzulaufen, bis Ihr Client aufgibt. Wird dieses Budget erreicht, gibt der Bericht trotzdem ein gültiges PDF mit den neuesten Sitzungen zurück, und das Deckblatt gibt an, wie viele ausgelassen wurden.## Abschließender SchrägstrichDie kanonische Route endet mit einem abschließenden Schrägstrich (`…/generate-pdf/`). Eine Anfrage ohne diesen wird direkt mit derselben Antwort bedient: Es gibt keine `301`-Weiterleitung, sodass kein Client Weiterleitungen folgen muss und `curl` kein `-L` braucht. Verwenden Sie die URL mit Schrägstrich wie in den Beispielen, denn sie ist die Form, die die OpenAPI-Spezifikation und Ihre Logs zeigen.## Fehler| Status | Wann | `detail` |
| - | - | - |
| `401` | Kein `x-api-key`-Header (und kein `Authorization: Bearer`-Token). | `You must be authenticated with a valid access token to access this endpoint.` |
| `403` | Ungültiger oder widerrufener API-Schlüssel oder ein Console-Benutzer-Token statt eines API-Schlüssels. | `You do not have permission to perform this action.` |
| `403` | Der Benutzer existiert, aber keine seiner Sitzungen hat einen meldbaren Status. | `This user has no sessions in review, declined, approved or kyc expired to report.` |
| `404` | Kein Benutzer mit dieser `vendor_data` in der Anwendung hinter dem API-Schlüssel, einschließlich Benutzern, die zu einer anderen Anwendung gehören. | `User not found.` |
| `429` | Mehr als 50 PDF-Generierungen pro Minute mit denselben Zugangsdaten. Das Kontingent wird mit [PDF generieren](https://docs.didit.me/de/sessions-api/generate-pdf.md) geteilt. Warten Sie `Retry-After` Sekunden. | `Session PDF generation rate limit exceeded. You can make up to 50 requests per minute.` |## Beispiele> [tab] curl
>
> ```bash theme={null}
> curl --fail 'https://verification.didit.me/v3/users/user-abc-123/generate-pdf/' \
> -H 'x-api-key: YOUR_API_KEY' \
> --output user-history.pdf
> ```> [tab] Python
>
> ```python theme={null}
> import requests
>
> response = requests.get(
> "https://verification.didit.me/v3/users/user-abc-123/generate-pdf/",
> headers={"x-api-key": "YOUR_API_KEY"},
> stream=True,
> timeout=120,
> )
> response.raise_for_status()
> with open("user-history.pdf", "wb") as fh:
> for chunk in response.iter_content(chunk_size=8192):
> fh.write(chunk)
> ```> [tab] JavaScript
>
> ```javascript theme={null}
> import { writeFile } from 'node:fs/promises';
>
> const vendorData = encodeURIComponent('user-abc-123');
> const response = await fetch(
> `https://verification.didit.me/v3/users/${vendorData}/generate-pdf/`,
> { headers: { 'x-api-key': process.env.DIDIT_API_KEY } },
> );
> if (!response.ok) throw new Error(`PDF generation failed: HTTP ${response.status}`);
> await writeFile('user-history.pdf', Buffer.from(await response.arrayBuffer()));
> ```## BerechtigungenJeder aktive API-Schlüssel der Anwendung kann diesen Endpoint aufrufen. API-Schlüssel von Didit sind
**anwendungsbezogen, nicht rollenbezogen**: Die [Rollen und Berechtigungen](https://docs.didit.me/de/console/roles-permissions.md) der Console
(`read:users` und die übrigen) bestimmen, was eine *Person* in der Console tun darf, und werden für
Management-API-Anfragen nicht ausgewertet. Ein Schlüssel kann nur Benutzer seiner eigenen Anwendung exportieren.## Verwandte Seiten- [PDF generieren](https://docs.didit.me/de/sessions-api/generate-pdf.md) – derselbe Bericht für eine einzelne Sitzung
- [KYC-Verlauf des Benutzers](https://docs.didit.me/de/entities/users/kyc-history.md) – Auflisten und Prüfen der Sitzungen eines Benutzers als JSON
- [PDF und CSV exportieren](https://docs.didit.me/de/console/export-pdf-csv.md) – die Console-Seite beider Exporte
- [Benutzer abrufen](https://docs.didit.me/de/management-api/users/get.md) – Profil und Funktionsübersicht des Benutzers als JSON
## OpenAPI
````yaml de/openapi-25.json GET /v3/users/{vendor_data}/generate-pdf/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API für Ausweisverifizierung. Authentifizierung über den x-api-key-Header.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/users/{vendor_data}/generate-pdf/:
get:
tags:
- Users
summary: Den vollständigen Benutzerverlauf als PDF-Bericht herunterladen
description: >-
Rendern und laden Sie ein compliance-fähiges PDF herunter, das den
vollständigen Verifizierungsverlauf des durch `vendor_data`
identifizierten Benutzers enthält. Es handelt sich um dasselbe Dokument,
das die Console über **User detail → Actions → Download PDF** generiert,
sodass für regelmäßige Compliance-Exporte niemand mehr manuell in der
Console klicken muss.
**Was der Bericht enthält.** Ein Deckblatt mit der Profilübersicht
(Name, Geburtsdatum, Ausstellungsstaaten, genehmigte E-Mails und
Telefonnummern), dem aktuellen Status jeder Funktion, den
Sitzungszählern und einem Index der enthaltenen Sitzungen – gefolgt vom
Standardbericht jeder enthaltenen Sitzung in chronologischer Reihenfolge
(älteste zuerst). Jeder Sitzungsbericht ist dasselbe Dokument, das `GET
/v3/session/{sessionId}/generate-pdf/` für diese Sitzung zurückgibt.
**Qualifizierte Sitzungen.** Es werden nur
Benutzerverifizierungs-Sitzungen (KYC) im Status `Approved`, `Declined`,
`In Review` oder `Kyc Expired` einbezogen; Sitzungen in jedem anderen
Status werden übersprungen. Wenn der Benutzer keine Sitzung in einem
dieser Status hat, gibt der Endpoint `403` zurück – siehe unten.
**Obergrenze.** Der Bericht ist auf die **20 neuesten**
berichtspflichtigen Sitzungen begrenzt. Wenn ein Benutzer mehr hat,
werden die 20 neuesten einbezogen und das Deckblatt gibt an, wie viele
ältere Sitzungen ausgelassen wurden. Verwenden Sie `GET
/v3/sessions/?vendor_data=…` für die vollständige Liste als JSON.
**Branding.** Wenn Ihre Anwendung über White-Label-Anpassungen verfügt,
werden das Deckblatt und jeder Sitzungsbericht mit Ihrem Logo und der
URL Ihrer Datenschutzerklärung gerendert; andernfalls tragen sie das
Didit-Branding. Berichte werden auf Englisch gerendert – es gibt keinen
Sprachparameter.
**Kein Caching.** Jeder Aufruf rendert das PDF aus den aktuellen Daten
neu, sodass ein nach einer manuellen Prüfung erstellter Bericht die
Entscheidung des Prüfers widerspiegelt. Zwei Aufrufe für denselben
Benutzer können byte-unterschiedliche Dateien erzeugen – archivieren Sie
die heruntergeladene Datei, wenn Sie eine unveränderliche Kopie
benötigen.
**Latenz.** Das Rendern erfolgt synchron und lädt jedes gespeicherte
Bild jeder enthaltenen Sitzung herunter, sodass ein Vorgang für einen
Benutzer mit vielen medienintensiven Sitzungen mehrere zehn Sekunden
dauern kann. Verwenden Sie ein großzügiges Client-Lese-Timeout (120 s
empfohlen) und streamen Sie den Body auf die Festplatte. Die Generierung
stoppt bei einem serverseitigen Zeitbudget, anstatt so lange zu laufen,
bis Ihr Client aufgibt: Wird dieses Budget erreicht, ist die Antwort
dennoch ein gültiges PDF mit den neuesten Sitzungen, und das Deckblatt
gibt an, wie viele ausgelassen wurden.
**Geltungsbereich.** Der Benutzer wird innerhalb der Anwendung
aufgelöst, zu der der API-Schlüssel gehört. Ein Schlüssel kann niemals
einen Benutzer einer anderen Anwendung exportieren – ein solcher
Benutzer existiert für ihn nicht und der Endpoint gibt `404` zurück.
**Nachgestellter Schrägstrich.** Die kanonische Route endet mit einem
nachgestellten Schrägstrich (`…/generate-pdf/`). Eine Anfrage ohne
diesen wird direkt mit derselben Antwort bedient – es gibt keine
`301`-Weiterleitung, sodass kein Client Weiterleitungen folgen muss und
`curl` kein `-L` benötigt. Verwenden Sie die URL mit Schrägstrich wie in
den Beispielen.
operationId: get_user_generate_pdf
parameters:
- name: vendor_data
in: path
required: true
schema:
type: string
description: >-
Ihre eindeutige Kennung für den Benutzer — ein Freitext-String
(KEINE UUID). Dies ist derselbe Wert, den Sie beim Erstellen der
Sitzungen des Benutzers als `vendor_data` übergeben haben, exakt wie
übermittelt abgeglichen. Kodieren Sie ihn URL-konform; ein Wert, der
`/` enthält, kann über diese Route nicht adressiert werden.
example: user-abc-123
responses:
'200':
description: >-
Das gerenderte PDF-Dokument, direkt als binäres `application/pdf`
zurückgegeben — es gibt keinen JSON-Wrapper und keine
Download-URL-Umleitung. Der Body beginnt mit den Magic Bytes `%PDF`.
Speichern Sie es in einer `.pdf`-Datei oder leiten Sie es per Stream
an Ihren Aufrufer weiter.
headers:
Content-Disposition:
description: >-
`attachment; filename=user_{didit_internal_id}.pdf` — die Datei
ist nach der stabilen Didit-Kennung des Benutzers benannt
(`didit_internal_id` bei `GET /v3/users/{vendor_data}/`), nicht
nach `vendor_data`.
schema:
type: string
example: >-
attachment;
filename=user_f4e5e1f2-94a9-4f86-8c16-2b7d9b4db418.pdf
Content-Length:
description: >-
Gesamtgröße des PDFs in Bytes; der Nachrichtentext ist nicht in
Chunks aufgeteilt.
schema:
type: integer
example: 148213
content:
application/pdf:
schema:
type: string
format: binary
'401':
description: >-
Keine Anmeldedaten angegeben. Anfragen an `/v3/users/*`-Pfade ohne
einen `x-api-key`-Header (oder `Authorization: Bearer`-Token) werden
von der Authentifizierungs-Middleware abgelehnt, bevor sie die API
erreichen.
content:
application/json:
examples:
Missing credentials:
value:
detail: >-
You must be authenticated with a valid access token to
access this endpoint.
'403':
description: >-
Autorisierungs- oder Zulässigkeitsfehler. Unterscheiden Sie beide
anhand des `detail`-Strings:
- `"You do not have permission to perform this action."` — Der
API-Schlüssel ist ungültig oder widerrufen, oder die Anfrage enthält
ein Console-Benutzer-Token anstelle eines Anwendungs-API-Schlüssels.
- `"This user has no sessions in review, declined, approved or kyc
expired to report."` — Der Benutzer existiert in Ihrer Anwendung,
aber keine seiner Sitzungen befindet sich bisher in einem
berichtsfähigen Status (zum Beispiel ist jede Sitzung noch `In
Progress`, oder der Benutzer wurde über `POST /v3/users/create/`
erstellt und wurde noch nie verifiziert). Warten Sie auf einen
Webhook `status.updated`, bevor Sie den Bericht anfordern.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: >-
This user has no sessions in review, declined, approved or
kyc expired to report.
examples:
Invalid credentials:
summary: >-
Widerrufener oder ungültiger API-Schlüssel oder ein
Console-Benutzertoken
value:
detail: You do not have permission to perform this action.
No reportable sessions:
summary: >-
Benutzer existiert, hat aber keine Sitzung mit dem Status
Approved / Declined / In Review / Kyc Expired
value:
detail: >-
This user has no sessions in review, declined, approved or
kyc expired to report.
'404':
description: >-
In der Anwendung hinter dem API-Schlüssel existiert kein Benutzer
mit den angegebenen `vendor_data`. Benutzer anderer Anwendungen sind
für diesen Schlüssel unsichtbar und geben denselben `404` zurück.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: User not found.
examples:
Unknown user:
summary: >-
vendor_data stimmt mit keinem Benutzer dieser Anwendung
überein
value:
detail: User not found.
'429':
description: >-
Rate-Limit überschritten. Die PDF-Generierung hat zusätzlich zum
globalen GET-Limit von 600/Min ein dediziertes Limit von **50
Anfragen pro Minute pro Anmeldeinformation** (API-Schlüssel,
Bearer-Token oder Quell-IP, wenn nicht authentifiziert), das von
diesem Endpoint und `GET /v3/session/{sessionId}/generate-pdf/`
gemeinsam genutzt wird. Warten Sie `Retry-After` Sekunden (wird auch
in den `X-RateLimit-*`-Headern widergespiegelt) und versuchen Sie es
dann erneut. Berichte werden serverseitig nicht zwischengespeichert;
laden Sie daher jeden Bericht einmal herunter und speichern Sie die
Datei, anstatt sie erneut abzurufen.
headers:
Retry-After:
description: >-
Anzahl der Sekunden, die vor einer erneuten Anfrage gewartet
werden muss.
schema:
type: integer
minimum: 1
example: 30
X-RateLimit-Limit:
description: >-
Maximale Anzahl an PDF-Generierungen, die im aktuellen
Zeitfenster zulässig sind (50).
schema:
type: integer
example: 50
X-RateLimit-Remaining:
description: Im aktuellen Zeitfenster verbleibende Anfragen.
schema:
type: integer
example: 0
X-RateLimit-Reset:
description: >-
Unix-Zeitstempel (Sekunden), zu dem das aktuelle Zeitfenster
zurückgesetzt wird.
schema:
type: integer
example: 1750000000
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: Lesbare Erklärung der Rate-Limit-Überschreitung.
example: >-
Session PDF generation rate limit exceeded. You can make
up to 50 requests per minute.
examples:
Throttled:
summary: >-
Mehr als 50 PDF-Generierungen in einer Minute mit denselben
Zugangsdaten
value:
detail: >-
Session PDF generation rate limit exceeded. You can make
up to 50 requests per minute.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: cURL
source: |-
curl --fail \
'https://verification.didit.me/v3/users/user-abc-123/generate-pdf/' \
-H 'x-api-key: YOUR_API_KEY' \
--output user-history.pdf
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
content = client.users.generate_pdf(
"user-abc-123",
)
with open("download.pdf", "wb") as file:
file.write(content)
- lang: javascript
label: Node.js
source: >-
import { writeFile } from "node:fs/promises";
import Didit from "@didit-protocol/sdk-node";
// Reads DIDIT_API_KEY.
const didit = new Didit();
const content = await didit.users.generatePdf("user-abc-123");
await writeFile("download.pdf", Buffer.from(await
content.arrayBuffer()));
- lang: go
label: Go
source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresp, err := client.Users.GeneratePDF(ctx, \"user-abc-123\")\nif err != nil {\n\tlog.Fatal(err)\n}\ndefer resp.Body.Close()\nfile, err := os.Create(\"download.pdf\")\nif err != nil {\n\tlog.Fatal(err)\n}\ndefer file.Close()\nif _, err := io.Copy(file, resp.Body); err != nil {\n\tlog.Fatal(err)\n}"
- lang: java
label: Java
source: |-
import java.nio.file.Path;
import me.didit.Didit;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
client.users().generatePdf("user-abc-123")
.writeTo(Path.of("download.pdf"));
- lang: php
label: PHP
source: |-
users->generatePdf('user-abc-123');
$content->saveTo('download.pdf');
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
content = didit.users.generate_pdf("user-abc-123")
File.binwrite("download.pdf", content)
- lang: csharp
label: .NET
source: |-
using System;
using Didit;
// Reads DIDIT_API_KEY.
using var client = new DiditClient();
var content = await client.Users.GeneratePdfAsync("user-abc-123");
await content.SaveToAsync("download.pdf");
components:
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in
der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter
Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese-
oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte
Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und
auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen
oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde,
der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder
die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei
einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows
oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff
erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne
Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als
null. Siehe https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.