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.

5 min readSume
All posts

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 plan for 250 SKUs (read 2026-10-04, limits from the bulk-runs docs)
QueueItemsRow rangeKey
11000-99bf26-batch-1
2100100-199bf26-batch-2
350200-249bf26-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.

Failure handling (read 2026-10-04)
SignalMeaningAction
counts.failed > 0Some items terminal with failureCollect failing index values
run_id null, error setItem never startedFix the row and re-queue
status completedAll items terminalNot 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

All Formats posts

Written by Sume