Applicant report (PDF / HTML)¶

GET /v1/applicants/{externalUserId}/report returns an audit-grade case-file for the applicant — the same document your operators see in the portal "Print report" view, rendered server-side. Use it for regulator audits, archival, or to attach to internal case notes.

Usage¶

curl -X GET 'https://api.compliance.example/v1/applicants/user-12345/report?format=pdf&lang=en' \
  -H 'X-Api-Key: pk_live_...' \
  -H 'X-Api-Secret: ...' \
  -H 'X-Environment: production' \
  -o user-12345.pdf

Query parameters¶

Param	Values	Default	Effect
`format`	`pdf` \| `html`	`pdf`	Output format
`lang`	`en` \| `ru`	`en`	Render language

What's included¶

A fixed partner section set: status block, profile, documents (with embedded data-URI images, latest approved per level). Operator-only sections (internal notes, EXIF, device intel) are stripped — partners get exactly the partner-safe subset.

There is no ?include= picker on the partner surface — the renderer always emits the partner default. The section picker stays on the operator-portal version of the report.

Notes¶

Synchronous + blocking. Large KYB cases (10+ children) can take several seconds. If your gateway has a strict timeout, plan around that; async-job mode is on the roadmap for genuine multi-second cases.
Content-Type reflects the chosen format — application/pdf or text/html.
Every download is audited — applicant.report_downloaded lands on /review-history with actorType=partner.
Identical to portal output modulo the section trim — both call into the same renderer (ApplicantReportEndpoint.RenderForApplicantAsync).

Webhooks vs report¶

If you just need to react to the applicant's verdict, use the applicantReviewed webhook (cheap, push-based). The report is for archival — generate it once at terminal-decision time and store the bytes on your side.