Retry a timed-out 30-second Wan job: Idempotency-Key vs paying twice

A 30-second Wan 3.0 1080p job reserves $7.50. Resubmit it without an Idempotency-Key after a timeout and you can hold $15.00; the same key does not.

4 min readSume
All posts

If your client times out while submitting a 30-second Wan 3.0 job at 1080p ($7.50), do not send a fresh request without the original Idempotency-Key. A second paid submit is a second job with its own reservation, so two jobs can hold $15.00 for one clip you wanted once. Resending with the same key is the supported way to retry.

What the docs say

Sume's generation admission page recommends an Idempotency-Key on every paid submit that a client can retry, and warns against submitting a paid request again only because a local worker timed out. Using the same key again for a different operation or payload returns 409 idempotency_conflict, so reuse a key only for an exact retry. On queue_full or provider_capacity_exceeded, the docs say to retry later with the same key.

Exposure from a duplicate submit of a 30-second Wan 3.0 job, Sume list prices as of 2026-10-09
ResolutionOne jobTwo jobs heldExtra exposure
480p$1.875$3.75$1.875
720p$3.75$7.50$3.75
1080p$7.50$15.00$7.50

A safe retry

Generate the key from your own record, for example a campaign and shot id, so the same logical request always carries the same key. Keep it stable across process restarts. Then a retry after a timeout returns the original job rather than starting another.

If the request itself looks invalid (400) or the balance is short (402), a retry will fail the same way. Fix the cause first.

  • Same key plus same payload: safe retry.
  • Same key plus different payload: 409 idempotency_conflict.
  • New key: a new job and a new reservation.
curl -X POST https://api.sume.com/v1/video-router/generate \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: campaign-42-shot-07" \
  -d @request.json

If you already double-submitted

If two copies of the same job are open, look at their status. A job that is still queued can be canceled before it starts, which releases its reservation; a job already processing cannot be canceled and will finish. Cancel the duplicate, keep the original, and note the job ids.

The docs also advise against tight retry loops. With 429 rate_limited, use retry-after when it is present; with queue_full, wait for a job to reach a terminal state. In both cases the same Idempotency-Key makes the retry safe, and a fresh key does not.

Sources

See generation admission and errors and rate limits. Prices are from the public catalog.

Sources

Related posts

More in Pricing

All Pricing posts

Written by Sume