Advanced Topics¶
Remote assets & security¶
Your HTML can reference remote assets (images, stylesheets, fonts) by URL. When it does, Zindle fetches those resources through a security screen before rendering.
- Requests to private, internal, or non-public network addresses are blocked to prevent server-side request forgery (SSRF). If your HTML references such a URL, the request fails with
422 SSRF_BLOCKED. - To avoid any remote-fetch surprises, you can inline assets directly in your HTML — e.g. base64
data:URIs for images, and<style>blocks instead of linked stylesheets. Inlined content always renders and is typically faster. - Only standard public
http(s)resources are fetched. Other schemes are not supported.
If a render is blocked and you believe the URL is legitimate and public, inline the asset as a workaround and contact support.
Idempotency¶
To safely retry a request without rendering (and billing) twice, include an idempotency key:
If a request with the same key was already processed, the API responds 200 with a JSON body {"error":{"code":"ALREADY_RENDERED", ...}} instead of the PDF. In other words, a replay is acknowledged but does not return the PDF again.
Because of this, treat the idempotency key as a guard against accidental double-submission (e.g. a network retry), not as a way to re-download a previously generated PDF. If you need the PDF again, render it as a fresh request (without the same key), or store the PDF on your side when you first receive it.
Support¶
Include the X-Render-ID header value from a failed or unexpected response when contacting support — it lets us trace the specific request.