Batch Video Generation API: Rendering Many Videos From One Integration

A batch video generation API is any endpoint that turns a list of inputs into a list of finished videos. Fifty product SKUs into fifty vertical ads. Twelve topics into twelve narrated shorts. One spreadsheet of localized scripts into one video per language.

The thing people expect when they search for this is a single POST that accepts an array and returns an array. Almost nobody ships that, and the reason is not laziness. A text completion returns in a second, so batching it into one request is a real optimization. A video render takes minutes. Holding one HTTP connection open while fifty of them finish is a timeout waiting to happen, and it gives you nothing to look at while it runs.

So batch video generation in practice means three different things, and picking the right one is most of the work.

The shape that actually works: fan out, then poll

Every published pipeline on Treza is a versioned API endpoint. You POST inputs to it, and it answers immediately:

POST /api/pipelines/<pipeline-id>/invoke
Authorization: Bearer treza_live_...
Content-Type: application/json

{ "inputs": { "topic": "how tides work" } }

The response is HTTP 202 with a runId. The render is now queued on the background worker, and your connection is free. To find out how it went, you poll:

GET /api/pipelines/<pipeline-id>/invoke?runId=<run-id>
Authorization: Bearer treza_live_...

That returns the run status, and once it finishes, the outputs, the duration, and the usage for the run. Polling costs nothing.

Batching is then a loop in your own code. Fire one POST per item, collect the run ids, and poll them until each lands. That is more code than an array endpoint, but it buys you per-item progress instead of one opaque wait, and a single failed item does not take the other forty-nine with it.

Two real limits govern that pace, and they are worth knowing before you write the loop rather than after. Invocations are rate limited to 60 requests per minute for an account. And one pipeline will hold at most 10 runs in flight at once; the eleventh gets a 429 with the code TOO_MANY_CONCURRENT_RUNS. Both are boring numbers, but a batch script that ignores them turns a fifty-item job into fifty errors. Write the loop with a small worker pool and a retry on 429, and it just works.

The shape inside the graph: one run that fans out for you

Sometimes you do not want a script at all. You want the batch to be part of the pipeline, so that a single scheduled run produces the whole set.

The Run Pipeline node does this. It calls another published pipeline you own as a step inside the current one. Turn on its For each option, wire a JSON array into it, and it runs the sub-pipeline once per item and collects the results.

The settings on that node are the batch controls:

• Concurrency decides how many sub-runs execute at once, from 1 to 4, defaulting to 2.
• Max items caps the fan-out at 50, defaulting to 20, so a malformed array cannot spend your balance. Extra items are dropped and noted on the run.
• Continue on error is on by default. One failed item does not stop the rest, and the node only fails when every item fails.

Its outputs are an array of the sub-pipeline results, plus a result object with per-run status, outputs, and cost for each item. Nesting goes one level deep, which is a deliberate limit rather than an oversight: a batch that can spawn batches that spawn batches is a very expensive way to discover a bug.

The upstream half of this pattern is whatever produces the array: a language model node returning a JSON list of twelve topics, a JSON Parse node on a payload your system sent, or a Code node building the list from run history. The node does not care where the array came from, only that it is an array.

The shape over time: batching by schedule

The third answer is that a lot of what people call batch is really cadence. You do not need twelve videos at 10am. You need one video a day for twelve days, which is easier on every part of the system, including the audience.

A scheduled pipeline runs the published version on an interval or a cron expression in the timezone you choose. The script node keeps memory of previous runs, so a daily automation produces a new video each time instead of regenerating last Tuesday's. Publishing is part of the same run, through the official YouTube and TikTok APIs, with visibility as a setting so an automated run can go live or stage privately for review.

If your batch has no deadline, this shape is strictly better than fan-out. It spreads the spend, it spreads the risk, and a bad prompt shows up on day one instead of across the whole set.

What a batch costs, and what a failure costs

Billing is prepaid credits, charged per generation at the model's own rate. There is no subscription and no per-seat price, packs start at $5, and credits do not expire. A typical video generation settles around $1.06, so the arithmetic for a batch is close to linear: the model cost times the number of items, plus cents for the text, narration, and caption steps around it.

Two details change how a batch behaves in practice. First, only successful runs are charged, so a failed render costs nothing. Second, an invocation checks your balance before it queues, and the check accounts for runs already queued and not yet settled. A fifty-item fan-out cannot quietly overdraw the account partway through. It stops instead, which is the failure you want.

Every run lands in run history with what each node produced, which model it used, and what it cost. For a batch, that history is the deliverable as much as the videos are, because it is the only place that answers "which six of the fifty went wrong, and where." For the full breakdown of what a finished video costs once narration and captions are in the graph, see how much AI video generation actually costs.

Where agents fit

If the caller is an agent rather than your backend, the same pipelines are reachable over our hosted MCP server, where running a pipeline, checking a run, and reading the credit balance are tools rather than HTTP routes. An agent batching work through MCP hits exactly the same queue and the same limits as a script hitting /invoke.

There is also a path with no account in it. The x402 video generation API sells a single clip for a USDC payment on the request itself, at $0.42 for five seconds, $0.84 for ten, and $1.26 for fifteen. That is a per-clip purchase rather than a batch primitive, but for a wallet-holding agent that needs six clips, six paid requests is a legitimate batch.

Honest limits

Worth being straight about what this is not, as of September 2026.

There is no CSV upload that turns a spreadsheet into a queue of runs. If your list lives in a spreadsheet, something has to turn it into a JSON array first, whether that is your script or a node in the graph.

There is no single endpoint that takes an array of briefs and returns an array of videos. Fan-out from your own code is the equivalent, and the per-item visibility is the compensation.

The For each cap is 50 items per node and 4 concurrent sub-runs. For genuinely large jobs, the pattern is fan-out from your own code against the 10-in-flight ceiling, run in waves.

And model choice still matters more than batch mechanics. A fifty-item batch on a model that costs four times as much per second is a four times more expensive mistake, so it is worth testing the model on one item before committing the list. If you are starting from nothing, the AI video generator page is the shortest path to a first working pipeline, and batching is something you add to it once one run is right.

Frequently Asked Questions

What is a batch video generation API?

It is any interface that turns a list of inputs into a set of rendered videos without a person driving each one. Because renders take minutes rather than milliseconds, most implementations are asynchronous: you submit each item, get an identifier back immediately, and poll for results. The batch lives in the calling loop or in the workflow, not in one giant request.

Can I send an array of prompts in a single API call?

Not to the invoke endpoint, which takes one set of inputs and returns one run id. If you want the fan-out to live inside a single run, use the Run Pipeline node with For each turned on, and wire a JSON array into it. It will run the sub-pipeline once per item, up to 50 items, and collect the results with per-item status and cost.

How many videos can I generate at once?

One pipeline holds up to 10 runs in flight at a time, and invocations are limited to 60 requests per minute for an account. Inside a single run, the For each option on the Run Pipeline node executes up to 4 sub-runs concurrently, capped at 50 items. For larger jobs, run in waves against the 10-in-flight ceiling.

What happens when one item in a batch fails?

Nothing to the others. Each item is its own run, so a failed render does not cancel the rest, and a failed run is not charged. With For each, Continue on error is on by default and the node only fails when every item fails. The per-run detail on the output tells you which items failed and what they cost.

How is a batch billed?

Per generation, at each model's rate, from a prepaid credit balance with no subscription. Packs start at $5 and credits do not expire. Before a run is queued, the balance check accounts for runs already queued and unsettled, so a large batch stops rather than overdrawing partway through.

Do I need to write code to batch video generation?

No. A schedule on a published pipeline produces a video per interval with no caller at all, and the Run Pipeline node fans out over an array built by an earlier node in the same graph. Writing a loop against the API is the right answer when the list comes from your own system and you want the results back in it.