Enqueue up to 100 async renders in a single request. All items are validated atomically — if any item fails authorization, the whole batch is rejected and no credits are consumed.
POST
/v1/renders/batchAuth requiredBody parameters
itemsrequiredarray
Up to 100 render requests, each with the same shape as
/v1/renders.Example request
json
{
"items": [
{ "template_id": "abc...", "format": "pdf", "data": { "name": "Asha" } },
{ "template_id": "abc...", "format": "pdf", "data": { "name": "Ravi" } },
{ "template_id": "abc...", "format": "pdf", "data": { "name": "Priya" } }
]
}Response
202 Accepted, one entry per item, in the order you sent them.
json
{
"jobs": [
{ "id": "d1e2f3a4-...", "render_id": "0a9b8c7d-...", "status": "queued" },
{ "id": "e2f3a4b5-...", "render_id": "1b0c9d8e-...", "status": "queued" },
{ "id": "f3a4b5c6-...", "render_id": "2c1d0e9f-...", "status": "queued" }
]
}Batches are the cheapest way to generate a mail-merge or CSV-driven campaign. One HTTP call, one rate-limit slot, 100 renders.
Atomic authorization
Every item's
template_id is authorized before any credit is charged. If any item fails (bad UUID, cross-workspace template, missing template), the whole batch is rejected with batch_rejected and no jobs are enqueued. The body lists only the failing items, each with its index and its own error code. The status is 400, except when the failing item names a template that does not exist — then it is 404.