Video generation API batch queue: dispatch many clips without a request burst

A video generation API batch queue turns a list of requested clips into controlled individual submissions. The current Genace video endpoint accepts one request object and returns one job_id. It does not provide a documented bulk-video submission envelope in this route. Build the batch coordinator in your application rather than sending an array and hoping it becomes several jobs.

Every accepted item needs its own request record, remote identifier, budget reservation, and collection outcome. The batch is then a summary over those records, not a single connection that must remain open until every video finishes.

Give each item a durable identity

Item field	Operational purpose
batch_id and item_id	Identify the business task independently of execution
specification_hash	Detect changed parameters under the same item ID
dispatch_status	Separate ready, submitting, accepted, and ambiguous
remote_job_id	Resume an accepted generation
next_action_at	Schedule either dispatch or collection
attempt_budget	Bound replacement work

Use a unique constraint for the item identity. A queue’s delivery guarantee may permit the same message to arrive more than once, so receiving a message cannot itself authorize another generation request. Claim the item through a conditional database update or a queue lease before dispatching.

Separate dispatch from collection

batch coordinator creates individual ready items
dispatcher checks shared rate budget and active-job permits
dispatcher claims one item and submits it once
dispatcher saves job_id and enqueues a collection message
collector reads that job and persists its latest snapshot
collector reschedules active work or starts artifact delivery
batch summary counts item outcomes from durable records

This is an application architecture outline, not a new Genace API. It keeps submission work short and lets collection proceed even when another item fails. A batch should expose partial progress rather than hide all successful results behind its slowest item.

Control throughput using completion

Request-rate limits and active-job limits both matter. Sending five requests rapidly is not useful if only one active render is admitted for the account. Release local render permits after terminal reconciliation, then admit the next queued item. Polling existing identifiers should have its own request budget so collection does not starve behind creation traffic.

If submission times out, mark that item ambiguous. Do not automatically return it to ready when its worker lease expires: remote work may already exist. Resolve the uncertainty before allowing another submission for that business item.

Handle failure without losing the batch

Keep explicit counts for queued items, active jobs, succeeded renders, failed renders, canceled items, and available artifacts. A successful render whose storage copy failed belongs in a delivery-recovery category. Do not regenerate the entire batch because one transfer failed.

Common mistakes include unbounded Promise.all over every item, one API key per worker without shared coordination, and deleting item records once the submission POST returns. Those designs erase precisely the information needed to resume safely after a crash.

Verification checklist

Replay an item message, stop a worker after acceptance, and fail one file copy. Confirm that the batch retains per-item progress, never submits the same accepted item again, and continues independent work within its shared capacity and credit budgets.

Continue with concurrency, duplicate requests, and resuming jobs.

Continue with production operations

• AI video API webhook vs polling: which one to use and when
• How to call a video generation API without blocking your agent
• generation operation unique key: deduplicate local intent without inventing API idempotency
• Browse all production operations guides