Blog
How to generate PDFs at scale
Generating one PDF is easy. Generating fifty thousand on the first of the month, reliably, without melting your servers, is an architecture problem. Here are the patterns that hold up.
Do not render on the request path
Rendering is slow and memory-heavy. Holding an HTTP request open while you render a large set leads to timeouts and retries that double the work. Submit the job and return immediately, then deliver results asynchronously.
Batch, then use webhooks
Batch submit
Send many documents in one call instead of one request per document, which cuts overhead and rate-limit pressure.
Async delivery
Get a webhook when the batch finishes, so nothing blocks and you are not polling.
Stored output
Persist each PDF and hand back URLs, so you are not moving large payloads through your app.
Make it idempotent and retryable
- Key each document by a stable id so a retry never produces a duplicate.
- Treat transient failures as retryable with backoff, not as hard errors.
- Record per-item status so you can re-run only the failures.
- Cap concurrency so a spike does not exhaust memory or downstream limits.
Why a render API wins at volume
A self-hosted browser fleet means you own pooling, recycling, autoscaling, and crash recovery for the single most fragile part of the pipeline. A render API absorbs that and scales elastically, so your job is orchestration, not browser babysitting.
Frequently asked
How do I generate thousands of PDFs without timeouts?
Submit a batch and receive results via webhook instead of rendering on the request path. This keeps requests fast and lets rendering scale independently.
How do I avoid duplicate PDFs on retry?
Make generation idempotent by keying each document with a stable id, so a retried job reuses the same key instead of creating a second document.
500 free documents a month, flat pricing after that, and a live playground you can try without signing up.