Business and source identifiers
Store the customer, report, order, product, or credential id and the source-record version. These values identify the intended business output when a job is retried or regenerated.
High-Volume Rendering
Track every document
Track every document
in a high-volume run
Process high-volume rendering runs reliably with asynchronous jobs, configurable concurrency, webhook notifications, and automated status reconciliation.
Free account, no credit card
Work out what your run actually costs
Estimate final-output volume from 3 inputs: records per run, outputs per record, and runs per month. A 2,000-record list with 1 certificate each uses 2,000 renders per run. The same list with an invoice and receipt, run 4 times a month, uses 16,000 renders before proofs, retries, and unrelated account work.
How often it runs
- Documents per run
- 1,500
- Renders per month
- 1,500
- Rendering at once
- 2
Starter at 5,000 renders covers this, at $29 a month.
Concurrency is one input to completion time, not a duration guarantee. Measure a representative sample that includes real assets, fonts, page counts, and delivery. Then test a larger run with the same submission pacing before committing to a deadline.
Build the run manifest before submitting jobs
The manifest is the run's source of expected work. Create one row per intended output before calling the render API. Update that row as the job moves through validation, submission, rendering, review, and delivery. The manifest lets an operator explain what remains without reconstructing the run from webhook logs.
Template and output contract
Record the template version, output type, size or page settings, locale, and any profile name. A later investigation can then reproduce the requested shape rather than only its data.
Submission and job state
Keep the submission time, request fingerprint where applicable, job id, current status, attempt count, and terminal error. Never infer job success from a missing webhook.
Result and review state
Link the returned asset or file reference and any required human or automated review. A rendered file may still be rejected because its source data or visual result is wrong.
Delivery state
Track the destination, path or record, delivery attempts, and final result independently from rendering. A successful document that never reached storage leaves the run incomplete.
Retry and exception decision
Record whether a failed row will retry, wait for corrected input, remain excluded by an approved exception, or stop the run. Name the owner and reason for every unresolved state.
Test the manifest with at least 5 outcomes: success, invalid input, render failure, missed webhook, and delivery failure. A run controller that can close those states on 5 records can use the same model for 5,000; only pacing and completion time change.
What changes when a run grows from 5 to 5,000
A small sample proves the template, not the whole operating process. Larger runs need a manifest, controlled submission rate, status reconciliation, partial retry, delivery tracking, and an owner for unresolved work.
- One row is malformed. A date is missing, a number is null, or a name field contains an address. Validate each record before submission where possible. If one job fails, mark that manifest row and continue reconciling the other expected results.
- Something upstream fails for a minute. An image host, font source, or other dependency can fail during a run. Define which errors are safe to retry, the attempt limit, the delay, and the final escalation state. Do not retry malformed input as if it were transient.
- The webhook endpoint is down. Consume success and failure webhooks, but do not make one endpoint the only record of the run. Query unresolved job ids through the Jobs API and reconcile the manifest after the endpoint recovers.
- Somebody runs it twice. Reuse stable business identifiers and keep every job result. Retry unresolved manifest rows instead of blindly resubmitting the full set. Cache behavior should be treated as an optimization, not the source of idempotency.
- Nobody is at their desk. Async jobs continue outside the initiating browser request. Your service still needs to store job ids, receive or recover status, alert on unresolved work, and close the run.
Four batch shapes with different controls
A batch may be scheduled, event-driven, one-time, or continuous. Its deadline, repetition, input stability, destination, and acceptable retry behavior determine how to operate it.
The monthly billing run
A known source set closes on a fixed date and each output belongs to a different account. Reconcile the expected manifest, review financial values upstream, and track both render and delivery before closing the period run.
The catalogue refresh
Product images may need new renders after price, badge, photo, or layout changes. Keep a dependency map so the workflow can identify affected products and profiles rather than resubmitting every catalog asset.
The one-off migration
Historical records need documents before an older system is retired. Preserve source ids, template versions, and run results. Prove retrieval and reconcile failures before the old source becomes unavailable.
The trickle that adds up to a batch
A steady event stream may never arrive as one list, but it still consumes monthly volume and concurrency. Monitor queue age, render use, error rate, and delivery status across the full reporting period.
Where the rows come from
A source list still needs a defined schema, stable identifier, validation, and transformation into the template's field contract. Keep those steps explicit so a source-system change does not silently alter thousands of outputs.
- Straight from your own database. Query the records, validate them, build the expected manifest, and submit through the API. Eight official SDKs cover supported languages, while your application owns pacing, state, retries, and reconciliation.
- From a form, one at a time. A submission can start one or more async jobs. Even without a scheduled batch, monitor the accumulated monthly volume and keep the business record linked to each result.
- From a spreadsheet somebody maintains. A connector or export can read rows from the tool where the owner maintains them. Validate headers, types, blanks, duplicates, and changed columns before rendering.
- From a CSV or a URL list. For capture work, validate each publicly reachable URL and its output settings. Treat each address as its own manifest row and record the capture result.
- From a schedule, with no list at all. A schedule starts the workflow, but it does not define the data cutoff, expected outputs, failure owner, or delivery rules. Record those as part of the run configuration.
These sources can use the same render APIs. The extra work at 5,000 records is operational: manifests, pacing, status storage, retries, reconciliation, and delivery. Design that layer before scaling the source list.
When an existing batch script needs attention
A maintained script may already meet the requirement. Evaluate it by ownership, failure visibility, capacity, template-change cost, retry boundaries, and recovery. Replace it only when a hosted workflow improves the constraints that matter.
- It fails without telling anyone. A loop can catch an exception and continue without closing the gap. Compare the source manifest with terminal job and delivery states, and alert on every unresolved row.
- Concurrency was set by trial and error. Local worker count may have been chosen against an older workload. A hosted plan publishes concurrency, but you still need representative timing tests and submission pacing to meet the run deadline.
- The template lives in the code. A code-owned template changes through the software release process. A workspace template can use visual and code views with roles and history. Choose ownership based on the review and release controls the document needs.
- Restarting is all or nothing. Keep per-record job state so a stopped run can resume from unresolved manifest rows. Stable business ids and recorded attempts matter more than relying on cache behavior.
- Nobody owns it until it breaks. Name the owner for the source data, template, run operation, delivery destination, and incident response. A hosted API changes infrastructure ownership, not business ownership.
Keep a small, stable, tested, and owned script when it meets the requirement. Consider a migration when measured operations, recovery, or template-maintenance costs justify it, and compare outputs before switching production traffic.
Give every output an explicit destination
Rendering and delivery have separate failure states. Define the destination, path, access, retention, and business-record link before submission. Then reconcile delivery rather than assuming a successful render means the file reached its owner.
Into your own bucket
Route to supported Amazon S3, Google Cloud Storage, Azure Blob Storage, Cloudflare R2, Backblaze B2, or DigitalOcean Spaces. Supply required region, path, class, and credentials on the supported request surface.
Under a name that means something
Build the path from stable customer, period, report, or business-record identifiers. Validate unsafe characters and collisions before sending 5,000 results into one prefix.
Behind your own domain
Use an eligible custom CDN host when the plan and delivery design call for branded asset URLs. Confirm access, cache, expiry, and replacement behavior.
Attached to the record
Continue through a connector only when its published action can attach or store the file on the required record. Track that action's result separately.
Merged into one file
When a recipient needs one file, merge the approved generated documents and cover sheet in the required order. Record both component and merged-file results.
Or nowhere at all
Secure and zero-retention modes cover stricter persistence needs. Verify exact purge and delivery behavior before building the run's retention requirement around them.
Controls for a recoverable large run
One failure, one retry
Store each job id and retry only unresolved records whose failure type is safe to retry. Keep the attempt history with the manifest row.
Async submission
The API returns a job id while work continues. Your service keeps ownership of status, timeout, cancellation, reconciliation, and escalation.
Webhooks with recovery polling
Use completion events for prompt updates and Jobs API checks for missed callbacks or run-level reconciliation. Treat unresolved status as work, not success.
Files land where you want them
Return output, keep eligible files in managed storage, or route to supported own storage. Record delivery state and destination for each file.
How a large run works
1
Send one request per document
Give each URL, HTML payload, or template record a manifest row, stable business id, and job state.
2
Queue them at your own pace
Submit within documented limits and measured pacing. Plan completion around published concurrency and representative timing.
3
Collect results as they finish
Consume webhooks, recover missed states through the Jobs API, and close the run only after reconciling every expected result.
High-volume rendering, answered
How many renders is my batch actually using?
One finished document uses 1 render. A list of 500 records producing 3 documents each uses 1,500 renders per run. Run it 4 times in a month and the final outputs use 6,000 renders, before proofs, retries, or other account work.
How long does a run of 5,000 take?
Measure it with representative documents. Published concurrency is 2 renders on the entry tier, 8 on Business, and 25 on Enterprise, but completion time also depends on document complexity, queue conditions, input assets, retries, and delivery. Test a smaller batch before setting a deadline.
What happens when one row in the batch is bad?
Track each document by its own job id. A bad input can fail independently, but the batch workflow must reconcile every expected result and handle any shared upstream or delivery failure. Retry only the rows and failure types your policy allows.
Do I need a different endpoint for large runs?
Use the same render APIs with async jobs or batch orchestration. Larger runs add operational work: input manifests, submission pacing, job tracking, partial failure, retries, delivery, and reconciliation. You do not need a different rendering product, but you do need a run-level workflow.
Does re-running a batch cost me twice?
Do not assume a repeated batch is free. Cache behavior depends on the request and documented policy, and changed or non-cacheable work can render again. Persist the manifest and job results so you can retry only unresolved records instead of submitting the full set blindly.
Where do the finished files end up?
Return files to your application, keep eligible outputs in managed storage, or route them to supported S3, Google Cloud Storage, Azure, R2, B2, or DigitalOcean Spaces storage. Supply a stable path and record delivery status separately from render status.
How many documents can I generate at once?
Submit work within the plan's volume, concurrency, rate, and payload limits. Store each job id and reconcile its result. Published allowances run from $9 a month for 1,000 renders to $1,000 for 100,000. For very large or deadline-bound runs, test pacing and completion time first.
Do I have to poll for results?
Webhooks provide success and failure events as jobs finish. Keep polling or Jobs API reconciliation as a recovery path for missed events, endpoint outages, and run-level checks. Silence should never count as completion.
Test a representative batch
from manifest to delivery
Start with real records and verify pacing, job states, partial failure, retry, delivery, and reconciliation before scaling the run.
No credit card required.