> ## 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.
# API PDF d'historique utilisateur : toutes les sessions
> Didit : un PDF regroupant toutes les sessions de vérification d'un utilisateur, par vendor_data, pour audits, SAR et exports de conformité.
Prompt PDF de l'historique utilisateur
Copier le prompt dans le presse-papiers
\
\`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.`
\
Coller dans
## Vue d'ensembleRenvoie un PDF unique contenant l'historique complet des vérifications d'une [entité Utilisateur](https://docs.didit.me/fr/entities/users/overview.md), identifiée par `vendor_data`.
Il s'agit du même document que celui produit par la Console via **User detail → Actions → Download PDF**, afin que les équipes conformité puissent automatiser les exports au lieu de cliquer une fois par utilisateur.Le rapport contient :- **Une page de couverture** avec le résumé du profil (nom, date de naissance, États de délivrance, e-mails et téléphones approuvés), le dernier statut de chaque fonctionnalité, les compteurs de sessions et un index des sessions incluses.
- **Un rapport complet par session incluse**, par ordre chronologique (la plus ancienne en premier). Chacun correspond au rapport que [Générer un PDF](https://docs.didit.me/fr/sessions-api/generate-pdf.md) renvoie pour cette session seule.## Sessions éligibles et plafondSeules les sessions de vérification d'utilisateurs (KYC) dont le statut est `Approved`, `Declined`, `In Review` ou `Kyc Expired` sont incluses. Les sessions ayant un autre statut (`Not Started`, `In Progress`, `Abandoned`, `Expired`, …) sont ignorées.Le rapport est limité aux **20 sessions exploitables les plus récentes**. Lorsqu'un utilisateur en possède davantage, les 20 plus récentes sont incluses et la page de couverture indique le nombre de sessions plus anciennes omises. Utilisez [Lister les sessions](https://docs.didit.me/fr/sessions-api/list-sessions.md) en filtrant par `vendor_data` lorsque vous avez besoin de la liste complète au format JSON.## RéponseLe corps de la réponse est le PDF lui-même (`application/pdf`), et non un objet JSON ni une URL de téléchargement. L'en-tête `Content-Disposition` vaut `attachment; filename=user_.pdf`, où `didit_internal_id` est l'identifiant Didit stable de l'utilisateur.## Marque blancheLorsque la personnalisation en marque blanche est activée sur votre application, la page de couverture et chaque rapport de session affichent votre logo et l'URL de votre politique de confidentialité à la place de la marque Didit, exactement comme l'endpoint par session. Configurez-la dans **Console → Customization**.## Mise en cache et latenceAucune mise en cache : chaque appel régénère le rapport à partir des données actuelles, de sorte qu'un rapport demandé après un examen manuel reflète la décision du réviseur. Deux appels peuvent produire des fichiers différant octet par octet ; archivez le fichier téléchargé lorsque vous avez besoin d'une copie immuable.Le rendu est synchrone et télécharge chaque image stockée de chaque session incluse ; un utilisateur ayant de nombreuses sessions riches en médias peut donc prendre plusieurs dizaines de secondes. Utilisez un délai de lecture client généreux (120 s recommandé) et diffusez le corps de la réponse directement sur le disque. La génération s'arrête à un budget de temps côté serveur plutôt que de continuer jusqu'à ce que votre client abandonne : si ce budget est atteint, le rapport renvoie tout de même un PDF valide avec les sessions les plus récentes, et la page de couverture indique le nombre de sessions omises.## Barre oblique finaleLa route canonique se termine par une barre oblique (`…/generate-pdf/`). Une requête sans barre oblique est traitée directement et renvoie la même réponse : il n'y a pas de redirection `301`, donc aucun client n'a besoin de suivre les redirections et `curl` n'a pas besoin de `-L`. Utilisez l'URL avec barre oblique, comme dans les exemples ; c'est la forme que présentent la spécification OpenAPI et vos journaux.## Erreurs| Statut | Quand | `detail` |
| - | - | - |
| `401` | Aucun en-tête `x-api-key` (et aucun jeton `Authorization: Bearer`). | `You must be authenticated with a valid access token to access this endpoint.` |
| `403` | Clé API invalide ou révoquée, ou jeton utilisateur de la Console utilisé à la place d'une clé API. | `You do not have permission to perform this action.` |
| `403` | L'utilisateur existe, mais aucune de ses sessions n'est dans un statut exploitable. | `This user has no sessions in review, declined, approved or kyc expired to report.` |
| `404` | Aucun utilisateur avec ce `vendor_data` dans l'application liée à la clé API, y compris les utilisateurs appartenant à une autre application. | `User not found.` |
| `429` | Plus de 50 générations de PDF par minute avec le même identifiant d'authentification. Ce quota est partagé avec [Générer un PDF](https://docs.didit.me/fr/sessions-api/generate-pdf.md). Attendez le nombre de secondes indiqué dans `Retry-After`. | `Session PDF generation rate limit exceeded. You can make up to 50 requests per minute.` |## Exemples> [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()));
> ```## AutorisationsToute clé API active de l'application peut appeler cet endpoint. Les clés API Didit sont **limitées à l'application, et non à un rôle** : les [rôles et autorisations](https://docs.didit.me/fr/console/roles-permissions.md) de la Console (`read:users` et les autres) déterminent ce qu'une *personne* peut faire dans la Console, et ne sont pas évalués pour le trafic de l'API de gestion. Une clé ne peut exporter que les utilisateurs de sa propre application.## Voir aussi- [Générer un PDF](https://docs.didit.me/fr/sessions-api/generate-pdf.md) : le même rapport pour une seule session
- [Historique KYC de l'utilisateur](https://docs.didit.me/fr/entities/users/kyc-history.md) : lister et inspecter les sessions d'un utilisateur au format JSON
- [Export PDF et CSV](https://docs.didit.me/fr/console/export-pdf-csv.md) : l'équivalent dans la Console pour les deux exports
- [Obtenir un utilisateur](https://docs.didit.me/fr/management-api/users/get.md) : le profil de l'utilisateur et sa carte des fonctionnalités au format JSON
## OpenAPI
````yaml fr/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 de vérification d'identité. Authentifiez-vous avec l'en-tête x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/users/{vendor_data}/generate-pdf/:
get:
tags:
- Users
summary: Télécharger le rapport PDF complet de l'historique utilisateur
description: >-
Générez et téléchargez un PDF prêt pour la conformité contenant
l'historique complet des vérifications de l'utilisateur identifié par
`vendor_data`. Il s'agit du même document que celui produit par la
Console depuis **User detail → Actions → Download PDF**, afin que les
exports périodiques de conformité ne nécessitent plus l'intervention
manuelle d'une personne dans la Console.
**Ce que contient le rapport.** Une page de garde avec le récapitulatif
du profil (nom, date de naissance, États de délivrance, e-mails et
téléphones approuvés), le dernier état de chaque fonctionnalité, les
compteurs de sessions et un index des sessions incluses — suivie du
rapport standard de chaque session incluse, par ordre chronologique (la
plus ancienne en premier). Le rapport de chaque session est le même
document que celui renvoyé par `GET
/v3/session/{sessionId}/generate-pdf/` pour cette session.
**Sessions éligibles.** Seules les sessions de Vérification des
utilisateurs (KYC) avec le statut `Approved`, `Declined`, `In Review` ou
`Kyc Expired` sont incluses ; les sessions ayant un autre statut sont
ignorées. Si l'utilisateur n'a aucune session dans l'un de ces statuts,
l'endpoint renvoie `403` — voir ci-dessous.
**Plafond.** Le rapport est limité aux **20 sessions les plus récentes**
pouvant être incluses. Lorsqu'un utilisateur en a davantage, les 20 plus
récentes sont intégrées et la page de garde indique combien de sessions
plus anciennes ont été omises. Utilisez `GET
/v3/sessions/?vendor_data=…` pour obtenir la liste complète au format
JSON.
**Personnalisation de marque.** Si votre application dispose d'une
personnalisation en marque blanche, la page de garde et chaque rapport
de session sont générés avec votre logo et l'URL de votre politique de
confidentialité ; sinon, ils portent la marque Didit. Les rapports sont
générés en anglais — il n'y a pas de paramètre de langue.
**Aucune mise en cache.** Chaque appel régénère le PDF à partir des
données actuelles, de sorte qu'un rapport généré après un examen manuel
reflète la décision du réviseur. Deux appels pour le même utilisateur
peuvent produire des fichiers aux octets différents — archivez le
fichier téléchargé si vous avez besoin d'une copie immuable.
**Latence.** La génération est synchrone et télécharge chaque image
stockée de chaque session incluse ; ainsi, le traitement d'un
utilisateur ayant de nombreuses sessions riches en médias peut prendre
plusieurs dizaines de secondes. Utilisez un délai d'expiration de
lecture côté client généreux (120 s recommandées) et enregistrez le flux
du corps de la réponse sur le disque. La génération s'interrompt
lorsqu'un budget de temps côté serveur est atteint au lieu de s'exécuter
jusqu'à ce que votre client abandonne : si ce budget est atteint, la
réponse reste un PDF valide contenant les sessions les plus récentes, et
la page de garde indique combien ont été omises.
**Portée.** L'utilisateur est résolu au sein de l'application à laquelle
appartient la clé API. Une clé ne peut jamais exporter un utilisateur
d'une autre application — un tel utilisateur n'existe pas pour elle et
l'endpoint renvoie `404`.
**Barre oblique finale.** La route canonique se termine par une barre
oblique (`…/generate-pdf/`). Une requête sans cette barre oblique est
traitée directement avec la même réponse — il n'y a pas de redirection
`301`, de sorte qu'aucun client n'a besoin de suivre les redirections et
que `curl` n'a pas besoin de `-L`. Utilisez l'URL avec la barre oblique
finale comme dans les exemples.
operationId: get_user_generate_pdf
parameters:
- name: vendor_data
in: path
required: true
schema:
type: string
description: >-
Votre identifiant unique pour l'utilisateur — chaîne libre (PAS un
UUID). Il s'agit de la même valeur que vous avez transmise en tant
que `vendor_data` lors de la création des sessions de l'utilisateur,
mise en correspondance exactement telle qu'envoyée. Encodez-la au
format URL ; une valeur contenant `/` ne peut pas être ciblée par
cette route.
example: user-abc-123
responses:
'200':
description: >-
Le document PDF généré, renvoyé directement au format binaire
`application/pdf` — il n'y a pas d'encapsulation JSON ni
d'indirection par URL de téléchargement. Le corps commence par les
octets magiques `%PDF`. Enregistrez-le dans un fichier `.pdf` ou
transmettez-le en flux continu à votre appelant.
headers:
Content-Disposition:
description: >-
`attachment; filename=user_{didit_internal_id}.pdf` — le fichier
est nommé d'après l'identifiant Didit stable de l'utilisateur
(`didit_internal_id` sur `GET /v3/users/{vendor_data}/`), et non
d'après `vendor_data`.
schema:
type: string
example: >-
attachment;
filename=user_f4e5e1f2-94a9-4f86-8c16-2b7d9b4db418.pdf
Content-Length:
description: Taille totale du PDF en octets ; le corps n'est pas segmenté.
schema:
type: integer
example: 148213
content:
application/pdf:
schema:
type: string
format: binary
'401':
description: >-
Aucun identifiant fourni. Les requêtes vers les chemins
`/v3/users/*` sans en-tête `x-api-key` (ou token `Authorization:
Bearer`) sont rejetées par le middleware d'authentification avant
d'atteindre l'API.
content:
application/json:
examples:
Missing credentials:
value:
detail: >-
You must be authenticated with a valid access token to
access this endpoint.
'403':
description: "Échec d'autorisation ou d'éligibilité. Distinguez les deux grâce à la chaîne `detail`\_:\n\n- `\"You do not have permission to perform this action.\"` — la clé API est non valide ou révoquée, ou la requête comporte un token d'utilisateur de la Console au lieu d'une clé API d'application.\n- `\"This user has no sessions in review, declined, approved or kyc expired to report.\"` — l'utilisateur existe dans votre application mais aucune de ses sessions n'est encore dans un statut permettant de générer un rapport (par exemple, chaque session est encore `In Progress`, ou l'utilisateur a été créé via `POST /v3/users/create/` et n'a jamais été vérifié). Attendez un webhook `status.updated` avant de demander le rapport."
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: >-
Clé API révoquée ou invalide, ou token d'utilisateur de la
console
value:
detail: You do not have permission to perform this action.
No reportable sessions:
summary: >-
L'utilisateur existe mais n'a aucune session Approved /
Declined / In Review / Kyc Expired
value:
detail: >-
This user has no sessions in review, declined, approved or
kyc expired to report.
'404':
description: >-
Aucun utilisateur avec le `vendor_data` fourni n'existe dans
l'application associée à la clé API. Les utilisateurs d'autres
applications sont invisibles pour cette clé et renvoient le même
`404`.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: User not found.
examples:
Unknown user:
summary: >-
vendor_data ne correspond à aucun utilisateur de cette
application
value:
detail: User not found.
'429':
description: >-
Limite de débit dépassée. La génération de PDF fait l'objet d'une
limite dédiée de **50 requêtes par minute par identifiant
d'authentification** (clé API, token Bearer ou IP source en cas de
requête non authentifiée), partagée entre cet endpoint et `GET
/v3/session/{sessionId}/generate-pdf/`, en plus de la limite globale
de 600 GET/min. Attendez le nombre de secondes indiqué par
`Retry-After` (également indiqué dans les en-têtes `X-RateLimit-*`),
puis réessayez. Les rapports ne sont pas mis en cache côté serveur,
téléchargez donc chaque rapport une seule fois et conservez le
fichier au lieu de le récupérer à nouveau.
headers:
Retry-After:
description: Secondes à attendre avant de réessayer la requête.
schema:
type: integer
minimum: 1
example: 30
X-RateLimit-Limit:
description: >-
Nombre maximal de générations de PDF autorisées dans la fenêtre
actuelle (50).
schema:
type: integer
example: 50
X-RateLimit-Remaining:
description: Requêtes restantes dans la fenêtre actuelle.
schema:
type: integer
example: 0
X-RateLimit-Reset:
description: >-
Horodatage Unix (en secondes) auquel la fenêtre actuelle se
réinitialise.
schema:
type: integer
example: 1750000000
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
Explication lisible par l'humain du dépassement de la
limite de débit.
example: >-
Session PDF generation rate limit exceeded. You can make
up to 50 requests per minute.
examples:
Throttled:
summary: >-
Plus de 50 générations de PDF en une minute avec le même
identifiant
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: >-
La clé API de votre application, issue de Développeurs -> Clés API dans
la Business Console. La clé principale dispose d'un accès complet. Une
clé nommée peut être restreinte : aucun, lecture ou écriture par
ressource, limitée à certains workflows ou aux sessions approuvées, à
une liste d'adresses IP et à une date d'expiration. 401 signifie que la
clé est incorrecte, révoquée ou expirée ; 403 signifie qu'aucune clé n'a
été envoyée, que la clé n'a pas accès à cette ressource ou action, ou
que la requête provient d'une adresse hors de sa liste d'IP ; 404 sur
une route de session signifie que la session est hors des workflows ou
des statuts de la clé. Une clé sans accès aux médias reçoit les URL
d'images, de vidéos et de PDF à null, et une clé sans accès en écriture
aux sessions reçoit les liens et tokens de session à null. Voir
https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.