One bad item in a 100-variant bulk run: 400 and nothing runs

When one item in a Sume bulk request is malformed, the whole create fails with 400 invalid_request and details.index names the bad item. No queue exists and nothing is dispatched, so no variant from that request starts. Fix the row at that index and send the batch again. Items that are valid but later fail to start are different: those become failed items inside an accepted queue.

This is from Sume's Bulk runs docs. A bulk create takes concurrency (an integer 1 to 16) and items (1 to 100 entries), and each item is the same body as a single Format run.

What counts as a bad item?

A spreadsheet row with an empty script is the usual cause for a UGC batch: the item then has nothing to name, and the whole request is refused.

How is that different from an item that fails later?

The create has two phases. Before the queue exists, the request is checked for the problems above, plus attachment resolution: the invalid_attachment, attachment_not_found, attachment_too_large and attachment_fetch_failed codes fire before the queue is created too. After 202, each child goes through ordinary Format-run admission (wallet, workspace generation concurrency, spend caps). A child that cannot start becomes one failed item with run_id: null, and the rest of the queue continues.

How do I avoid it?

Four habits keep a batch from failing at create:

• Check each row on your side before you build the request: drop any row with no instruction or input, as the docs' own production-batch example does for rows with no finished draft.
• Keep the batch within 100 items; split larger lists across requests, each with its own Idempotency-Key.
• Treat a 400 as a clean failure: nothing ran, so resending after the fix repeats nothing.
• Log details.index and map it back to your sheet row.