Product-drop videos: one bulk queue or a scheduled run per drop?

Use a bulk queue when the drops are known now: up to 100 items, window 1 to 16. Use a schedule when each drop starts on a date. Pick one per series.

4 min readSume
All posts

For a product-drop series, use a bulk Format queue when every drop's inputs exist today and you want them rendered now, and use a schedule when each video should start on a date. A queue takes 1 to 100 items with a window of 1 to 16 and starts immediately; a schedule fires on a 5-field cron expression with a time zone and keeps its instructions between runs.

The two shapes

A bulk queue is one POST with an items array. Each item is the same body as a single Format run, and the queue dispatches them in order within the concurrency window. A schedule is an Agents automation you create in the dashboard: its instructions persist, caller data arrives separately as input, and a cadence or an API call starts it.

Bulk queue versus schedule for a drop series, from the bulk and schedule docs (read 2026-10-05)
QuestionBulk queueSchedule
StartsRight away on POSTOn its cron time, or on an API call
How many1 to 100 items per queueOne run per firing
Where inputs liveIn each item's bodyIn input per call; instructions persist
OverlapItems ignore on_active_run; the window paces themSkips a firing while a run is active, by default
Completion signalPoll the queue; no queue-level webhookRun receipt; events_url is always null
CapPer item, send onePer schedule, default $1.00 per run

A rule of thumb

Ask when the drop date is known. If you have twelve drops with finished briefs and want twelve renders ready for review, a queue is the shape. If you want one render each Thursday from a feed that changes, a schedule is the shape, because it will exist next week with no work from you.

A mixed series works too: a schedule that, on each firing, reads the upcoming drop and renders it, plus a queue for the back catalogue.

import os, requests
items = [{"instruction": f"Drop {i}: {name}",
          "generation_spend_cap_usd": 8}
         for i, name in enumerate(["tote", "shirt", "cap"], 1)]
r = requests.post(
    "https://api.sume.com/v1/formats/acme/product-promo/bulk-runs",
    headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"],
             "Idempotency-Key": "drops-2026-10"},
    json={"concurrency": 3, "items": items}, timeout=30)
print(r.status_code, r.json()["data"]["status_url"])

Traps on each side

On the queue side, completed means every item is terminal, not that every item succeeded, so read counts.failed. On the schedule side, the default $1.00 cap will stop a video run early unless you set the cap, and the schedule's trigger type cannot be changed after you create it.

Neither shape has a queue-level or schedule-level total budget. Add up the caps yourself before you start.

Limits

A queue is capped at 100 items, so a longer series needs several queues with different idempotency keys. A schedule cannot be created or edited through the Developer API; that happens in the dashboard.

Sources

Related posts

More in Use cases

All Use cases posts

Written by Sume