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.

5 min readSume
All posts

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.

From the Sume live-commerce docs, read 2026-10-05
AskAnswer
New take, framing, lighting or B-roll for named scene idsYes, re-render those clips and re-assemble
Finalize a stand-in or failed sceneYes
Different words, price read or line lengthNo, new full production
Different host, script or productNo, 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

All Formats posts

Written by Sume