Get Started
Integrate / SDKs
User Verification
Business Verification
Transaction Monitoring
ChangelogGenerate PDF
Render and download a compliance-ready PDF report for a finished verification session. The same path serves both User Verification (KYC) and Business Verification (KYB) sessions — the server looks the sessionId up in both tables and picks the matching report template.
Eligible statuses. The session must already carry a final or reviewable status:
- KYC sessions:
Approved,Declined,In Review, orKyc Expired. - KYB sessions:
Approved,Declined, orIn Review.
Any other status (Not Started, In Progress, Expired, Abandoned, …) returns 403 with an explanatory detail string — see the 403 response below.
What the report contains. The PDF mirrors the console session view at the moment of the request:
- KYC — rolled-up session status, the warnings list, and one section per executed feature: ID Verification (document images plus extracted fields), NFC, Liveness, Face Match, Email Verification, Phone Verification, Proof of Address, Questionnaire answers, Database Validation, AML Screening, and IP Analysis — followed by session tags, console review activity (comments and status changes), and the session event timeline.
- KYB — registry checks (company data), AML screenings, business document verifications, key-people checks, questionnaire responses, phone/email verifications, IP analyses, and the session event timeline, followed by tags and review activity.
Branding. If your application has white-label customization, the report is rendered with your logo and links to your privacy-policy URL; otherwise it carries Didit branding. Reports are rendered in English — there is no language parameter.
No caching. Every call re-renders the PDF from the current session data, so a report generated after a manual review reflects the reviewer’s decision. Two calls for the same session can produce byte-different files — archive the downloaded file if you need an immutable copy.
Latency. Rendering downloads every stored image (document sides, selfies, extra files) before composing the PDF, so media-heavy sessions can take several seconds. Use a generous client read timeout (60 s recommended) and stream the body to disk.
Trailing slash. The canonical route ends with a trailing slash (…/generate-pdf/). Requests without it receive a 301 redirect to the slashed URL — most HTTP clients follow it automatically for GET, but plain curl needs -L (or call the slashed URL directly, as in the samples).
If you need the underlying data as JSON instead of a rendered report, use GET /v3/session/{sessionId}/decision/.
KYC and KYB support
Works for both User Verification (KYC) and Business Verification (KYB) sessions. Didit routes to the appropriate PDF template automatically:- User Verification (KYC) session → report with ID verification, liveness, face match, AML, POA sections.
- Business Verification (KYB) session → report with company registry, key people (UBOs/officers), documents, AML, questionnaire, phone, email, and IP analysis sections when those features are part of the workflow.
Filename convention
| Kind | Filename |
|---|---|
| User | session_<session_id>.pdf |
| Business | business_<session_id>.pdf |
Content-Disposition: attachment; filename=... header.
Status requirement
The session must be inAPPROVED, DECLINED, or IN_REVIEW to generate a PDF. In-progress or not-started sessions return 403.
Examples
- User Verification (KYC) PDF
- Business Verification (KYB) PDF
White-label
When the application has white-label customization enabled, the PDF uses your logo and privacy-policy URL. Configure at Console → Customization.Permission
Requiresread:sessions. Same scope for both kinds.
Related
- Sessions overview
- Retrieve session — JSON version of the same decision
- KYB response schema — fields included in business PDFs
Authorizations
Path Parameters
UUID of the User Verification (KYC) or Business Verification (KYB) session to render — the session_id returned by POST /v3/session/. The same path works for both session kinds; use the Content-Disposition filename on the response to tell which report type you received.
Must be a well-formed, lowercase UUID. The route only matches valid UUIDs, so a malformed value is rejected by the URL router before any application code runs and the response is a 404 HTML page rather than the JSON {"detail": ...} envelope shown below. The route's UUID converter only matches the canonical lowercase form — uppercase-hex UUIDs are rejected with the HTML 404.
"11111111-2222-3333-4444-555555555555"
Response
The rendered PDF document, returned directly as binary application/pdf — there is no JSON wrapper and no download-URL indirection. The body starts with the %PDF magic bytes (PDF 1.7). Save it to a .pdf file or stream it through to your caller.
The response is of type file.