Retry two scenes in one Format run: scene_ids with previous_run_id

To redo two clips of a finished Format run in one go, continue the same thread with previous_run_id and put both scene ids in input.scene_ids, for example ["sc_7", "sc_9"]. The voice track, the other clips and the script do not change, and the API returns the full scene list again, re-assembled into a new cut.

The scene_id and scene_ids keys are the cookbook's convention for its live-commerce recipe, not a field of the platform. Your Format's instructions must tell the agent to read them.

The request

A run is one turn of a conversation, so a retry is a new run on the same thread. Say in instruction which scenes are wrong and how they should change, and keep the ids in input as the machine-readable pointer. Send the same output_schema as the first run, and always send a cap.

curl -sS -X POST "https://api.sume.com/v1/formats/acme/live-commerce/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: sheet-45-v1-retry-sc7-sc9" \
  -d '{
    "previous_run_id": "'"$PREV_RUN_ID"'",
    "instruction": "Retry scenes sc_7 and sc_9 only. Keep every other scene and the voice track unchanged.",
    "input": { "scene_ids": ["sc_7", "sc_9"] },
    "primary_output_key": "full_video",
    "generation_spend_cap_usd": 12
  }'

What comes back

The API returns a new run with its own receipt and its own webhook on the same thread_id. output.scenes[] is the full list again. The retried scenes have new URLs, the others keep theirs, and full_video is assembled at a new URL.

The cookbook says measured single-scene retries cost about one twentieth of the first run. Treat that as a planning figure for one scene, not as a price, and size the two-scene cap from your own receipts.

One run or two

Use one run when both scenes need the same kind of fix, because the re-assembly happens once. Use two sequential runs when the fixes differ, so each instruction stays plain and you can accept one result before spending on the other. If you continue from a run that is still in progress, the API answers previous_run_not_terminal, so wait for the earlier run to end first.

Check before you accept

Read output.scenes[] from the new run and compare each scene's status against the schema's enum. In the cookbook's schema the values are succeeded, stand-in and failed. A scene still marked stand-in or failed after the retry needs another pass or a changed instruction.

Also confirm that the scenes you did not name kept their URLs. If one changed, the agent did more than you asked, and the instruction needs to be firmer about leaving other scenes alone. Keep the cap low for the first attempt: a retry that overspends is a signal that the agent re-planned the whole cut.

Limits

A retry is a new take, not a re-encode. If the words, the host or the product change, start a new production instead. The ids are only as stable as your schema: the cookbook's schema gives each scene a stable id, so keep that in yours.