Rendering is asynchronous — there is no sync mode
The render request schema definesoptions.sync, but the render endpoint does not honor it.
Every render is enqueued and the endpoint returns 202 with status: "queued" and
downloadUrl: null. Do not wait on the create response for a finished PDF — poll the render,
or use a webhook.
Status enum
The authoritative render status values are:| Status | Meaning |
|---|---|
queued | accepted, waiting for a worker |
rendering | a worker is producing the PDF |
succeeded | terminal — downloadUrl is populated |
failed | terminal — errorMessage explains why |
cancelled | defined in the enum but never produced today (no cancellation path) |
succeeded and failed. There is no processing status — if you saw it in an older
doc, the real intermediate state is rendering. You can treat cancelled defensively, but it will
not occur.
downloadUrl durability
When a render succeeds, downloadUrl is the rendered PDF’s object-storage URL:
- It is a permanent, public, non-presigned URL (the project’s public bucket base + the asset key). It does not expire on a TTL, and the path is unguessable (keyed by the render’s UUID).
- It is
nulluntil the render succeeds, and alsonullif the deployment has no public bucket configured.
Re-fetch later (offline replay)
GET /v1/renders/:id remains valid for your project key
indefinitely after completion. This is the durable record for offline-first flows: the render
may fire only on reconnect, and you can re-fetch its result by id at any later time.