Live-commerce clip retry: looks yes, words no
A scene retry re-renders named scene ids on the same thread. New words, host or product need a new production, because the voice track sets the limit.

A live-commerce clip retry changes how a scene looks, not what it says. Continue the same thread with previous_run_id, name the scene ids, and Sume re-renders those clips and re-assembles the cut. A different line, price read, host or product needs a new production, because the voice track sets the limit and the scene ids change with it.
What a retry can and cannot change
The docs give a plain table. A different take, framing, lighting or B-roll for named scenes works. Finalizing a scene that came back as stand-in or failed works. Different words, a new price read, a longer or shorter line, another host, a new script or another product all mean a new full production.
| Ask | Answer |
|---|---|
| New take, framing, lighting or B-roll for named scene ids | Yes, re-render those clips and re-assemble |
| Finalize a stand-in or failed scene | Yes |
| Different words, price read or line length | No, new full production |
| Different host, script or product | No, new full production |
The request
Send the same Format slug, previous_run_id, a short fixed instruction, and the scene id. Use scene_ids for two or more. Send the same output_schema as the first turn, because the schema applies to one run only. Never send thread_id, which the API rejects with unknown_parameter.
curl -sS -X POST "$SUME_API/v1/formats/acme/live-commerce/runs" \
-H "Authorization: Bearer $SUME_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: sheet-45-v1-retry-sc_7" \
-d '{
"previous_run_id": "RUN_ID_FROM_THE_FIRST_TURN",
"instruction": "Retry the selected scene only. Keep every other scene and the voice track unchanged. Do not change the script.",
"input": { "scene_id": "sc_7" },
"primary_output_key": "full_video",
"generation_spend_cap_usd": 8
}'What comes back
The retry is a new run with its own id, its own spend and one terminal webhook, on the same thread. The receipt is the full scene list again, not a patch. Retried scenes get new URLs. The others keep theirs. The cut is re-assembled at a new URL. The old run stays completed, so a receipt you stored stays valid and you can keep both takes.
A retry is another take
A retry is a new generation, not a re-encode. The generative parts of that scene are rolled again. Structured overlay facts such as price and discount label stay fixed, but decorative copy inside generated art can change its words between takes. Tell the operator who clicks the retry button that they get another take, not the same frame with one detail fixed.
Treat scene ids as opaque
Store the scene.id from the receipt and send that value back. Do not build ids from a pattern or from the array index, because earlier productions returned other shapes than sc_0, sc_1. Keep a cap on every retry. The docs say to budget a single-scene retry as a fraction of the create spend and to learn your own ratio from your first runs.
Sources
Related posts
More in Formats
- Live-commerce Format: instruction past 4,000 characters is cut
A Format run rejects input above 2 MiB with a 400, but silently keeps only the first 4,000 characters of instruction. Put the broadcast script in input.
- Logo animation with sume-logo-motion-design: one call, a cap, a retry
Animate a logo with the sume-logo-motion-design Format: attach the PNG, set a spend cap, keep a stable idempotency key, and continue a run to fix one detail.
- Lost the bulk-run queue id? There is no list endpoint; replay the key
Sume has no list-queues or cancel-queue endpoint. If you lost the frq_ id, replay the create with the same key and body to get the queue back.
- MAI-Voice-2.1 and Format runs: get the voiceover as its own file
A Format run cannot be told to use MAI-Voice-2.1, since its tools pick the audio model. Bind an audio field to get the voiceover track as a file.
Written by Sume