Revise 20 finished videos in one Sume bulk queue with previous_run_id

Yes. A bulk item is the same body as a single run, and Sume's bulk docs list previous_run_id among the fields an item may name. So you can revise twenty finished videos by sending a queue of twenty items, each pointing at one earlier run and saying what to change. Each item becomes a continuation: a new run on the same conversation, with its own receipt, spend cap and webhook.

The risk is a queue where half the items are refused because the run they point to was not continuable. Check the old receipts first, then build the queue.

Why re-edit instead of regenerate?

A continued run is replayed what the agent produced before, so it can change one part and leave the rest. That is cheaper and more consistent than a fresh run per row. It also fits the direction creators are being pushed: Social Media Today reports that YouTube said it is updating Shorts recommendations to favor original content over re-uploads that add nothing. A human-directed revision pass on every clip, such as a new opening line or your own commentary, is a way to add something of your own at batch speed. The report gives no start date, so treat it as reported.

What must be true of each earlier run?

Because a queue is bound to one Format, runs from different Formats go in different queues. The docs do not say whether a refused continuation fails the whole create or only its own item, so do not rely on either: filter client-side with the preflight below and you never find out.

What does the preflight and submit look like?

This reads each receipt, keeps the continuable ones, and sends them as one queue. The schema is repeated on every item because it is per run and not inherited.

import os, requests

B = "https://api.sume.com/v1"
H = {"Authorization": "Bearer " + os.environ["SUME_API_KEY"]}

def continuable(run_id):
    r = requests.get(f"{B}/format-runs/{run_id}", headers=H, timeout=30)
    d = r.json().get("data", {}) if r.ok else {}
    return bool(d.get("thread_id")) and (
        d.get("status") == "completed" or d.get("artifacts"))

def revise(run_ids, note, schema, batch_key):
    ok = [i for i in run_ids if continuable(i)]
    items = [{"previous_run_id": i, "instruction": note,
              "output_schema": schema, "generation_spend_cap_usd": 8}
             for i in ok]
    r = requests.post(
        f"{B}/formats/myteam/product-promo/bulk-runs",
        json={"concurrency": 4, "items": items},
        headers={**H, "Idempotency-Key": batch_key}, timeout=30)
    r.raise_for_status()
    return r.json()["data"]["id"], set(run_ids) - set(ok)

What does it cost and return?

Plan for these points before you send the queue.

• Every item has its own generation_spend_cap_usd. Set a small one, since a revision of one part needs a fraction of the original run's cap.
• usage stays per run, while artifacts[] on a continued run lists everything the whole conversation generated, so do not sum artifact counts across the chain to count new files.
• The original run never changes. Keep both receipt ids so you can compare the old and new versions.
• Webhooks are per item. The queue has none, and a continuation that is canceled delivers nothing.
• Use a fresh Idempotency-Key for each batch. Replaying a spent key returns the old queue, and a changed payload under the same key is a 409.

What should the instruction say?

Name the part to change and say what must stay. The Format docs' own example for a one-scene retry reads: keep every other scene and the voice track unchanged. Put the row-specific detail, such as which line to replace, in input, which is treated as data, and keep the instruction identical across items so a bad batch is easy to diagnose. After the queue finishes, branch on counts.failed, because completed only means every item is terminal.