Screen Wallet PDF
Stateless companion to POST /v3/wallet-screening/: repost the exact JSON body that endpoint returned — including the report_signature it added — and get back a Didit-branded PDF of the same result. No provider is called and nothing is billed or persisted; this only re-renders a result Didit already produced. The signature ties the PDF to an unmodified result: editing risk_score, severity, sanctions_hit, or any other signed field before reposting fails with 400.
Why it’s stateless
Standalone wallet screening writes nothing to the transactions table, so there is no stored record for this endpoint to render from. Instead, you repost the exact JSON thatPOST /v3/wallet-screening/ already gave you, and Didit renders that payload into a PDF without calling a provider again.
The report_signature field
Every POST /v3/wallet-screening/ response now includes a report_signature field — an opaque signature scoped to your application. This endpoint verifies it before rendering, so a caller can’t edit risk_score, severity, sanctions_hit, or any other field and get a clean-looking Didit-branded PDF for a result Didit never produced.
Always repost the full response body unmodified, including report_signature. Reordering keys is fine; changing any signed value is not.
Billing
No provider call is made and nothing is billed — this only re-renders a result you already paid for when you calledPOST /v3/wallet-screening/.
Errors
Next steps
Screen Wallet
On-demand wallet screening
Authorizations
Body
The unmodified JSON object returned by POST /v3/wallet-screening/, including report_signature.
Same shape as the POST /v3/wallet-screening/ response — pass that response body back verbatim, including report_signature.
Opaque HMAC-SHA256 signature over this exact result, scoped to your application. Not meaningful on its own — repost the full response body, unmodified and including this field, to POST /v3/wallet-screening/pdf/ to render it as a PDF. The PDF endpoint rejects the request with 400 if report_signature is missing or if any signed field (e.g. risk_score, severity, sanctions_hit) was edited before repost.
Provider that performed the screening (e.g. merklescience, crystal).
Always WALLET_SCREENING for this endpoint.
WALLET_SCREENING Normalised 0-100 risk score. Higher means greater exposure to risky entities.
Risk bucket derived from risk_score: 0-9 UNKNOWN, 10-39 LOW, 40-69 MEDIUM, 70-89 HIGH, 90-100 CRITICAL. UNKNOWN is the lowest band, not a separate no-data state: risk_score 0 (the common clean-address case) means no adverse assessment, while a non-zero score in the 1-9 range is a real but sub-LOW signal - read the risk_score, not just the band. Never treat UNKNOWN as an affirmative low-risk or clear rating; do not display it as a pass.
UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL Screening outcome status.
SCREENED, PENDING, ERROR Human-readable summary of the screening result.
The screened address, echoed back.
The blockchain that was screened.
True if the address has direct or indirect sanctions exposure.
Highest-weighted high-risk category, or null when none is dominant (e.g. sanctioned, mixer, stolen_funds).
Where the address received funds from, attributed by entity. Each entry is an exposure breakdown.
Where the address sent funds to, attributed by entity. Same item shape as source_of_funds with exposure_direction = outgoing.
Direct and indirect counterparty entities with received/sent amounts and risk levels.
Response
The rendered PDF document, returned directly as binary application/pdf — there is no JSON wrapper.
The response is of type file.