Spreadsheet rows to videos: Creatomate or Sume bulk runs?

Both can turn a list of rows into a list of videos. Creatomate does it by connecting a design template to a spreadsheet, so each row becomes one video or image. Sume does it with a bulk run: a queue of up to 100 Format runs, one per row, with 1 to 16 running at once. The difference is that Sume's rows are briefs for a recipe that generates media, not values poured into a fixed layout.

Creatomate's description is from its API introduction, read 2026-10-10. Sume's is from Bulk runs and Create a run.

How a row becomes a job

The Creatomate page says every spreadsheet row becomes its own video or image once a template is connected; the page I read does not describe limits, so none are claimed here. In Sume, POST /v1/formats/{handle}/{slug}/bulk-runs takes concurrency (1 to 16) and items (1 to 100). Each item is the same body as a single run: instruction, input, attachments, an optional output_schema and its own spend cap.

Planning 250 rows on Sume

One call takes at most 100 items, so 250 rows is three queues: 100, 100 and 50. At concurrency 16 the first 16 items start immediately and the rest wait in the window. A queue created with a spent Idempotency-Key returns the old queue with 202, so mint a fresh key for every batch. A bad item fails the whole create with 400 invalid_request and details.index before anything runs, which is worth catching with a dry pass over your sheet.

• The queue object has no webhook; use per-item webhooks or poll status_url.
• completed means every item is terminal, not that every item succeeded. Branch on counts.failed.
• There is no public list-queues or cancel-queue endpoint; cancel a child with POST /v1/format-runs/{run_id}/cancel.
• Service-account keys cannot create bulk queues and fail with 403 insufficient_scope.

When the spreadsheet tool is better

If a thousand rows are 'same video, new price', a template tool is the more direct, more predictable route, and a Format run's agent turn is a heavier unit of work than a text swap. Sume earns its place when each row needs a different generated shot or script. Whichever you use, do the dry pass first and set a per-item spend cap on the Sume side.

Reading the results back

A spreadsheet tool usually hands you the finished files in the same order. A Sume queue needs a little more bookkeeping, because items finish in any order and some fail on their own. Store the queue id and the Idempotency-Key you used next to the batch in your own database, then read counts from the queue until every item is terminal. For each failed item, look at its run, decide whether it is worth a retry, and submit those as a new, smaller batch with a new key.

Because a run can spend money, set generation_spend_cap_usd on each item rather than relying on the batch as a whole. The docs state that a cap above the Format's own limit is accepted, not clamped, so you should choose the number deliberately instead of copying a default. A sensible habit is to run five rows first, look at the cost and the output, and only then submit the remaining rows.