> ## 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 cronologia utente: tutte le sessioni di un utente
> Scarica con Didit un unico PDF con tutte le sessioni di verifica di un utente, tramite vendor_data, per audit, SAR e export di compliance.
Prompt PDF della cronologia utente
Copia il prompt negli appunti
\
\`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.`
\
Incolla in
## PanoramicaRestituisce un unico PDF con la cronologia completa delle verifiche di un'[entità User](https://docs.didit.me/it/entities/users/overview.md), identificata tramite `vendor_data`.
È lo stesso documento che la Console produce da **User detail → Actions → Download PDF**, così i team di compliance possono automatizzare le esportazioni invece di cliccare una volta per ogni utente.Il report contiene:- **Una copertina** con il riepilogo del profilo (nome, data di nascita, stati di emissione, email e numeri di telefono approvati), lo stato più recente di ogni funzionalità, i contatori delle sessioni e un indice delle sessioni incluse.
- **Un report completo per ogni sessione inclusa**, in ordine cronologico (dalla più vecchia alla più recente). Ciascuno è lo stesso report che [Generate PDF](https://docs.didit.me/it/sessions-api/generate-pdf.md) restituisce per quella sessione singola.## Sessioni idonee e limiteSono incluse solo le sessioni di Verifica degli utenti (KYC) in stato `Approved`, `Declined`, `In Review` o `Kyc Expired`. Le sessioni in qualsiasi altro stato (`Not Started`, `In Progress`, `Abandoned`, `Expired`, …) vengono saltate.Il report è limitato alle **20 sessioni più recenti** tra quelle idonee a essere incluse nel report. Quando un utente ne ha di più, vengono incluse le 20 più recenti e la copertina indica quante sessioni più vecchie sono state escluse. Usa [List sessions](https://docs.didit.me/it/sessions-api/list-sessions.md) filtrato per `vendor_data` quando ti serve l'elenco completo in JSON.## RispostaIl corpo della risposta è il PDF stesso (`application/pdf`), non un wrapper JSON né un URL di download. L'intestazione `Content-Disposition` è `attachment; filename=user_.pdf`, dove `didit_internal_id` è l'identificativo Didit stabile dell'utente.## White labelQuando la personalizzazione White label è attiva per la tua applicazione, la copertina e ogni report di sessione riportano il tuo logo e l'URL della tua informativa sulla privacy al posto del branding Didit, esattamente come l'endpoint per sessione. Configurala in **Console → Customization**.## Cache e latenzaNon viene usata nessuna cache: ogni chiamata ricalcola il report a partire dai dati correnti, quindi un report richiesto dopo una revisione manuale riflette la decisione del revisore. Due chiamate possono produrre file diversi byte per byte; archivia il file scaricato quando ti serve una copia immutabile.Il rendering è sincrono e scarica ogni immagine memorizzata di ogni sessione inclusa, quindi un utente con molte sessioni ricche di contenuti multimediali può richiedere decine di secondi. Imposta un timeout di lettura generoso sul client (si consigliano 120 s) e scrivi il corpo della risposta su disco in streaming. La generazione si interrompe a un limite di tempo lato server invece di proseguire finché il client non rinuncia: se questo limite viene raggiunto, il report restituisce comunque un PDF valido con le sessioni più recenti e la copertina indica quante sono state omesse.## Barra finaleL'URL canonico termina con una barra finale (`…/generate-pdf/`). Una richiesta senza barra viene servita direttamente con la stessa risposta: non c'è alcun redirect `301`, quindi nessun client deve seguire redirect e `curl` non ha bisogno di `-L`. Usa l'URL con la barra come negli esempi; è la forma che compare nella specifica OpenAPI e nei tuoi log.## Errori| Stato | Quando | `detail` |
| - | - | - |
| `401` | Manca l'header `x-api-key` (e manca anche un token `Authorization: Bearer`). | `You must be authenticated with a valid access token to access this endpoint.` |
| `403` | Chiave API non valida o revocata, oppure un token utente della Console al posto di una chiave API. | `You do not have permission to perform this action.` |
| `403` | L'utente esiste ma nessuna delle sue sessioni si trova in uno stato idoneo per il report. | `This user has no sessions in review, declined, approved or kyc expired to report.` |
| `404` | Nessun utente con questo `vendor_data` nell'applicazione associata alla chiave API, inclusi gli utenti che appartengono a un'altra applicazione. | `User not found.` |
| `429` | Più di 50 generazioni PDF al minuto dalla stessa credenziale. Il budget è condiviso con [Generate PDF](https://docs.didit.me/it/sessions-api/generate-pdf.md). Attendi `Retry-After` secondi. | `Session PDF generation rate limit exceeded. You can make up to 50 requests per minute.` |## Esempi> [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()));
> ```## PermessiQualsiasi chiave API attiva dell'applicazione può chiamare questo endpoint. Le chiavi API di Didit sono
**limitate all'applicazione, non al ruolo**: i [ruoli e i permessi](https://docs.didit.me/it/console/roles-permissions.md) della Console
(`read:users` e gli altri) determinano cosa una *persona* può fare nella Console e non vengono valutati
per il traffico della Management API. Una chiave può esportare solo gli utenti della propria applicazione.## Correlati- [Generate PDF](https://docs.didit.me/it/sessions-api/generate-pdf.md) – lo stesso report per una singola sessione
- [Cronologia KYC utente](https://docs.didit.me/it/entities/users/kyc-history.md) – elenco e ispezione delle sessioni di un utente in JSON
- [Esporta PDF e CSV](https://docs.didit.me/it/console/export-pdf-csv.md) – il lato Console di entrambe le esportazioni
- [Get user](https://docs.didit.me/it/management-api/users/get.md) – il profilo dell'utente e la mappa delle funzionalità in JSON
## OpenAPI
````yaml it/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 di verifica dell'identità. Autenticati con l'intestazione x-api-key.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/users/{vendor_data}/generate-pdf/:
get:
tags:
- Users
summary: Scarica il report PDF della cronologia utente completa
description: >-
Genera e scarica un PDF pronto per la compliance contenente la
cronologia completa delle verifiche dell'utente identificato da
`vendor_data`. È lo stesso documento prodotto dalla Console da **User
detail → Actions → Download PDF**, quindi le esportazioni periodiche per
la compliance non richiedono più l'intervento manuale di una persona
nella Console.
**Cosa contiene il report.** Un frontespizio con il riepilogo del
profilo (nome, data di nascita, stati di emissione, email e telefoni
approvati), lo stato più recente di ciascuna funzionalità, i contatori
delle sessioni e un indice delle sessioni incluse — seguiti dal report
standard di ciascuna sessione inclusa, in ordine cronologico (dalla meno
recente alla più recente). Ciascun report di sessione è lo stesso
documento restituito da `GET /v3/session/{sessionId}/generate-pdf/` per
quella sessione.
**Sessioni idonee.** Sono incluse solo le sessioni di Verifica degli
utenti (KYC) in stato `Approved`, `Declined`, `In Review` o `Kyc
Expired`; le sessioni in qualsiasi altro stato vengono ignorate. Se
l'utente non ha alcuna sessione in uno di questi stati, l'endpoint
restituisce `403` — vedi sotto.
**Limite.** Il report è limitato alle **20 sessioni più recenti**
rendicontabili. Quando un utente ne ha di più, vengono incluse le 20 più
recenti e il frontespizio indica quante sessioni meno recenti sono state
escluse. Usa `GET /v3/sessions/?vendor_data=…` per l'elenco completo in
formato JSON.
**Branding.** Se la tua applicazione dispone della personalizzazione
White label, il frontespizio e il report di ciascuna sessione vengono
generati con il tuo logo e l'URL dell'informativa sulla privacy; in caso
contrario, riportano il branding di Didit. I report sono generati in
inglese — non è presente alcun parametro per la lingua.
**Nessuna memorizzazione nella cache.** Ogni chiamata rigenera il PDF a
partire dai dati correnti, quindi un report generato dopo una revisione
manuale riflette la decisione del revisore. Due chiamate per lo stesso
utente possono produrre file differenti a livello di byte — archivia il
file scaricato se necessiti di una copia immutabile.
**Latenza.** La generazione è sincrona e scarica ogni immagine
archiviata di ciascuna sessione inclusa, quindi per un utente con molte
sessioni ricche di contenuti multimediali possono essere necessarie
decine di secondi. Utilizza un timeout di lettura lato client generoso
(consigliati 120 s) ed esegui lo streaming del body su disco. La
generazione si interrompe al raggiungimento di un limite di tempo lato
server invece di continuare fino al timeout del client: se tale limite
viene raggiunto, la risposta è comunque un PDF valido contenente le
sessioni più recenti, e il frontespizio indica quante sono state omesse.
**Ambito.** L'utente viene risolto all'interno dell'applicazione a cui
appartiene la chiave API. Una chiave non può mai esportare un utente di
un'altra applicazione — per essa tale utente non esiste e l'endpoint
restituisce `404`.
**Barra finale.** Il percorso canonico termina con una barra finale
(`…/generate-pdf/`). Una richiesta priva di barra viene gestita
direttamente con la stessa risposta — non c'è alcun reindirizzamento
`301`, quindi nessun client deve seguire i reindirizzamenti e `curl` non
necessita di `-L`. Usa l'URL con la barra finale come negli esempi.
operationId: get_user_generate_pdf
parameters:
- name: vendor_data
in: path
required: true
schema:
type: string
description: >-
Il tuo identificatore univoco per l'utente: una stringa a formato
libero (NON un UUID). È lo stesso valore che hai passato come
`vendor_data` durante la creazione delle sessioni dell'utente,
confrontato esattamente come inviato. Codificalo come URL; un valore
contenente `/` non può essere indirizzato tramite questo percorso.
example: user-abc-123
responses:
'200':
description: >-
Il documento PDF renderizzato, restituito direttamente come binario
`application/pdf` — non sono presenti wrapper JSON né
reindirizzamenti tramite URL di download. Il corpo inizia con i byte
magici `%PDF`. Salvalo in un file `.pdf` o trasmettilo in streaming
al tuo chiamante.
headers:
Content-Disposition:
description: >-
`attachment; filename=user_{didit_internal_id}.pdf` — il file
prende il nome dall'identificatore Didit stabile dell'utente
(`didit_internal_id` su `GET /v3/users/{vendor_data}/`), non da
`vendor_data`.
schema:
type: string
example: >-
attachment;
filename=user_f4e5e1f2-94a9-4f86-8c16-2b7d9b4db418.pdf
Content-Length:
description: >-
Dimensione totale del PDF in byte; il corpo non è frammentato in
blocchi.
schema:
type: integer
example: 148213
content:
application/pdf:
schema:
type: string
format: binary
'401':
description: >-
Nessuna credenziale fornita. Le richieste ai percorsi `/v3/users/*`
senza un'intestazione `x-api-key` (o token `Authorization: Bearer`)
vengono rifiutate dal middleware di autenticazione prima di
raggiungere 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: >-
Errore di autorizzazione o di idoneità. Distingui i due casi tramite
la stringa `detail`:
- `"You do not have permission to perform this action."` — la chiave
API non è valida o è stata revocata, oppure la richiesta include un
token utente della Console anziché una chiave API dell'applicazione.
- `"This user has no sessions in review, declined, approved or kyc
expired to report."` — l'utente esiste nella tua applicazione ma
nessuna delle sue sessioni è ancora in uno stato idoneo per la
generazione del report (ad esempio ogni sessione è ancora `In
Progress`, oppure l'utente è stato creato tramite `POST
/v3/users/create/` e non ha mai eseguito la verifica). Attendi un
webhook `status.updated` prima di richiedere il report.
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: >-
Chiave API revocata o non valida, oppure un token utente
della Console
value:
detail: You do not have permission to perform this action.
No reportable sessions:
summary: >-
L'utente esiste ma non ha una sessione Approved / Declined /
In Review / Kyc Expired
value:
detail: >-
This user has no sessions in review, declined, approved or
kyc expired to report.
'404':
description: >-
Nessun utente con il `vendor_data` fornito esiste nell'applicazione
associata alla chiave API. Gli utenti di altre applicazioni sono
invisibili a questa chiave e restituiscono lo stesso errore `404`.
content:
application/json:
schema:
type: object
properties:
detail:
type: string
example: User not found.
examples:
Unknown user:
summary: >-
vendor_data non corrisponde ad alcun utente di questa
applicazione
value:
detail: User not found.
'429':
description: >-
Limite di frequenza superato. La generazione di PDF ha un limite
dedicato di **50 richieste al minuto per credenziale** (chiave API,
token Bearer o IP di origine se non autenticato), condiviso tra
questo endpoint e `GET /v3/session/{sessionId}/generate-pdf/`, oltre
al limite globale di 600 richieste GET al minuto. Attendi i secondi
indicati in `Retry-After` (riportati anche nelle intestazioni
`X-RateLimit-*`), poi riprova. I report non vengono memorizzati in
cache lato server, pertanto scarica ciascun report una sola volta e
archivia il file invece di recuperarlo nuovamente.
headers:
Retry-After:
description: Secondi da attendere prima di riprovare la richiesta.
schema:
type: integer
minimum: 1
example: 30
X-RateLimit-Limit:
description: >-
Numero massimo di generazioni di PDF consentite nella finestra
temporale corrente (50).
schema:
type: integer
example: 50
X-RateLimit-Remaining:
description: Richieste rimanenti nell'intervallo corrente.
schema:
type: integer
example: 0
X-RateLimit-Reset:
description: Timestamp Unix (secondi) in cui la finestra corrente si azzera.
schema:
type: integer
example: 1750000000
content:
application/json:
schema:
type: object
properties:
detail:
type: string
description: >-
Spiegazione di facile lettura del superamento del limite
di frequenza.
example: >-
Session PDF generation rate limit exceeded. You can make
up to 50 requests per minute.
examples:
Throttled:
summary: >-
Più di 50 generazioni di PDF in un minuto dalla stessa
credenziale
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 chiave API della tua applicazione, da Developers -> API keys nella
Business Console. La chiave primaria ha accesso completo. Una chiave con
nome può avere un ambito definito: nessuno, lettura o scrittura per
risorsa, limitata ad alcuni workflow o a sessioni approvate, a un elenco
di indirizzi IP e a una data di scadenza. 401 indica che la chiave è
errata, revocata o scaduta; 403 indica che non è stata inviata alcuna
chiave, che la chiave non ha accesso a questa risorsa o azione, oppure
che la richiesta proviene da un indirizzo non incluso nel suo elenco IP;
404 su una route di sessione indica che la sessione non rientra nei
workflow o negli stati previsti dalla chiave. Una chiave senza accesso
ai media riceve gli URL di immagini, video e PDF come null, e una chiave
senza permessi di scrittura sulle sessioni riceve link e token di
sessione come null. Consulta https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.