Getting it to the reader / options.callback_url
Get a webhook when a PDF render finishes
An address notified after a render, so the calling code does not have to hold the request open waiting.
What it is for
For work that happens outside a user's request cycle: a nightly statement run, a document generated in response to an event, anything where the code that asked for the document is not the code that will do something with it.
The request
Sent to options.callback_url. Everything else on this page is what happens around it.
{
"html": "<!doctype html>...",
"options": {
"callback_url": "https://your-app.example/hooks/render-complete"
}
}The actual limits
Read from the implementation rather than remembered, so these are the numbers the API enforces rather than the ones a roadmap intends.
- The URL is validated the same way a URL render is: http or https only, and the hostname must resolve entirely to publicly routable addresses.
- An invalid or private URL is skipped silently rather than failing the render, because a broken callback should not cost you the document.
- Delivery is best effort. Treat it as a notification, not as a guaranteed queue.
What failure looks like
The silent skip is the thing to know about. A callback_url that fails validation does not error, so a typo produces a render that succeeds and a callback that never arrives, with nothing in the response to say why. Validate the URL on your side before sending it.
Plan availability
Available on Growth and above. On smaller plans the field is accepted and ignored rather than rejected, which means testing it on a plan that does not have it looks exactly like a broken endpoint.
When this is the wrong tool
When the caller can simply wait. A synchronous render returns the bytes in the response, and for a document a user is waiting for that is both simpler and faster than a callback plus a fetch. Callbacks earn their complexity in background work, not in request handling.
Frequently asked
Is render callbacks available on the free plan?
Available on Growth and above. On smaller plans the field is accepted and ignored rather than rejected, which means testing it on a plan that does not have it looks exactly like a broken endpoint.
Where do these numbers come from?
The running implementation. Every figure on this page, from payload ceilings to per-plan limits, is what the API enforces today rather than what a specification says it should. If one of them is wrong, the API is the thing to believe.
Related capabilities
Options that come up in the same request, and one from each of the other groups.
Password protect a generated PDF
Encrypts the output so a reader is asked for a password before the document opens.
Render an HTML string to PDF over an API
Send a complete HTML document in the request body and get the PDF bytes back in the response.
Set the PDF page size in an API request
Six named paper sizes, passed in the request options, with A4 as the default when nothing is given.
Print background colours and images in a PDF
Controls whether background colours and images survive into the PDF. On by default here, which is the opposite of a browser's own default.
Render many PDFs in one API call
Up to several hundred documents in one request, each stored and returned as a link, with per-item success or failure rather than one all-or-nothing result.
Check API usage and remaining document quota
How many documents have been used this billing period, what the limit is, and what the plans are, all readable from the API rather than from a dashboard.
Everything the API does
The full list, grouped by which part of the request it belongs to.
API reference
The complete parameter documentation, including the parts with nothing interesting to say about them.
100 free documents a month, and a playground that runs a real render without a key.