250 SKUs for Black Friday: three Format queues of 100, 100 and 50
A Sume bulk queue holds 1 to 100 Format runs. For 250 SKUs, send three queues of 100, 100 and 50 with their own idempotency keys and concurrency window.

A Sume bulk queue takes between 1 and 100 items, so 250 product SKUs need three queues: 100 + 100 + 50 = 250. Each item is the same body as a single Format run, and concurrency is an integer from 1 to 16 that sets how many child runs stay in flight at once. Black Friday is 2026-11-27, 54 days from today, which leaves room to run the whole set, read the failures and re-run only those.
This page is the planning math and the request shape. It does not promise a finish time, because that depends on your Format and on workspace generation concurrency, which the docs say still applies to children.
Split the list
Sort the sheet by SKU so each batch is stable. Slice rows 0 to 99, 100 to 199 and 200 to 249. Give every queue its own Idempotency-Key, such as bf26-batch-1, bf26-batch-2 and bf26-batch-3. The docs warn that if you replay a spent key, the API returns 202 with the old queue, so a new batch must get a new key.
| Queue | Items | Row range | Key |
|---|---|---|---|
| 1 | 100 | 0-99 | bf26-batch-1 |
| 2 | 100 | 100-199 | bf26-batch-2 |
| 3 | 50 | 200-249 | bf26-batch-3 |
The request
Each item names at least one of instruction, input, previous_run_id or attachments. A bad item fails the whole create with 400 invalid_request and details.index, before any queue exists, so a typo in row 87 costs you nothing but a retry.
curl -sS -X POST "https://api.sume.com/v1/formats/chase/product-promo/bulk-runs" \
-H "Authorization: Bearer $SUME_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: bf26-batch-1" \
-d '{
"concurrency": 4,
"items": [
{ "instruction": "sku-0001", "input": { "url": "https://example.com/1.jpg" } },
{ "instruction": "sku-0002", "input": { "url": "https://example.com/2.jpg" } }
]
}'Read the result honestly
A queue answers 202 with a frq_ id and a status_url. Its status moves queued, running, completed, and the docs say completed means every item is terminal, not that every item succeeded. Read counts.failed, and for each failed index look at error and run_id. A failed item that never started has run_id: null. Re-run only those rows in a fourth, small queue with a new key.
The queue object has no webhook; each item can register its own communication.webhook_url. Otherwise poll the status_url. Cancel is per child run, not per queue, because the API has no public cancel-queue endpoint.
| Signal | Meaning | Action |
|---|---|---|
| counts.failed > 0 | Some items terminal with failure | Collect failing index values |
| run_id null, error set | Item never started | Fix the row and re-queue |
| status completed | All items terminal | Not proof of success |
Pick the concurrency window
A higher window drains sooner but loads your workspace limit sooner. Start at 4, watch counts.running, and raise toward 16 only if runs queue behind the workspace limit rather than behind your window. Keep a spend check as well: every Format has a generation spend cap, and a Format that never named one reports the platform default of $400 per run.
If a Black Friday sheet changes after launch, do not edit a queue. Make a new one with a new key for the changed SKUs only.
- Three keys, three queues, 250 items.
- Window 1 to 16, start small.
- Retry only failed indexes.
Related posts
More in Formats
- Selling on many channels: queue 100 product videos overnight
Amazon says over 95% of independent sellers sell on several channels. Queue up to 100 Sume Format runs with a concurrency window and wake up to a media set.
- Sume bulk queue has no webhook: poll status_url, read counts.failed
A Sume Format bulk queue gives no queue-level webhook and a completed status that is not all succeeded. Poll status_url and read counts.failed and each item.
- Cancel one SKU in a running Sume bulk queue: use the run endpoint
Sume has no public list-queues or cancel-queue endpoint. Stop one running child with POST /v1/format-runs/{run_id}/cancel and read cancel_effect.
- Compare orchestrator models in one Sume bulk queue with per-item model
A bulk item can carry its own model. Send the same input under several orchestrators, then compare debited spend and output across the receipts.
Written by Sume