Timed-out Seedance 2.5 POST: retry with the same key, pay $8.09 once

If a POST for a 14-second Seedance 2.5 job at 720p times out, resend the identical request with the same Idempotency-Key. Sume returns the original job rather than creating a second one. The job holds 14 x $0.5778 = $8.0892, so a retry with a new key could hold that amount a second time: 2 x $8.0892 = $16.1784.

What the docs say about retries

The Sume jobs page says not to submit a new paid job for the same intent, and that you can retry the submit itself with the same Idempotency-Key so the retry returns the original job and does not bill a second job. The Video Router page uses Idempotency-Key on its example, and the Video generation page says a replay returns the original job.

A retry you can run

The example below uses a key you generate once per intent. Reuse it on every attempt for that clip, and store it with the job record. Seedance 2.5 accepts 4 to 30 s, so 14 is valid.

KEY="clip-014-20261009-a"
for try in 1 2 3; do
  curl -sS --max-time 20 -X POST https://api.sume.com/v1/video-router/generate \
    -H "Authorization: Bearer $SUME_API_KEY" \
    -H "Content-Type: application/json" \
    -H "Idempotency-Key: $KEY" \
    -d '{"model":"seedance-2.5","prompt":"Slow dolly over a ceramic mug","resolution":"720p","duration":14,"aspect_ratio":"16:9","mode":"async"}' \
    && break
  sleep $((try * 5))
done

Choosing and storing the key

Derive the key from the intent, not from the attempt. A good key names the clip, such as a shot id plus a date, so every retry of that clip sends the same string. A random key generated inside the retry loop defeats the purpose, because each attempt then looks like a new request.

Store the key with the job record the moment you create the intent, before the first network call. After a crash, your process can read the key back and resend. Once you receive a job id, store that too and switch from resubmitting to polling. Then compare the job's usage.cost, which should be $8.0892 for this clip at default options, with your own estimate.

Also set a client timeout shorter than your patience for the job, since the POST returns a job id quickly and the generation itself runs asynchronously. A timeout on the submit says nothing about whether the job was created, which is exactly the situation the key is for. Never read a timeout as a failure and move on to a new key.

Checking your ledger

To confirm you paid once, look at the usage entries for the job id. The usage page lists reservation, capture and refund entries, and says to correlate rows with job ids. One job id with one reservation is the right outcome.