Zum Hauptinhalt springen
GET
cURL

Übersicht

Gibt ein einziges PDF mit dem vollständigen Verifizierungsverlauf einer User-Entität 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 für diese Sitzung allein zurückgibt.

Berechtigte Sitzungen und Obergrenze

Nur 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 mit dem Filter vendor_data, wenn Sie die vollständige Liste als JSON benötigen.

Antwort

Der Body ist das PDF selbst (application/pdf), kein JSON-Wrapper und keine Download-URL. Der Header Content-Disposition lautet attachment; filename=user_<didit_internal_id>.pdf, wobei didit_internal_id die stabile Didit-Kennung des Benutzers ist.

White-Label

Wenn 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 Latenz

Es 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ägstrich

Die 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

Beispiele

Berechtigungen

Jeder aktive API-Schlüssel der Anwendung kann diesen Endpoint aufrufen. API-Schlüssel von Didit sind anwendungsbezogen, nicht rollenbezogen: Die Rollen und Berechtigungen 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

Autorisierungen

x-api-key
string
header
erforderlich

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.

Pfadparameter

vendor_data
string
erforderlich

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.

Antwort

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.

The response is of type file.

Zuletzt geändert am 7. November 2026