Same Idempotency-Key on two Formats starts two runs: holiday A/B
A Sume Idempotency-Key is scoped to one Format. Reusing a key across two holiday Formats starts two runs, so make the key carry the variant.

A Sume Idempotency-Key is scoped to one Format. If you send the same key to two Formats, you start two runs and pay for both. That is useful when you A/B two holiday Formats on one SKU, and a trap when you expected the second call to be treated as a replay.
How the key behaves
On a single Format, the same key with the same body returns 200 with the original receipt and idempotency_hit: true, and no second run or charge. The same key with a different body (a different instruction or attachment list counts) returns 409 idempotency_conflict. Two simultaneous requests with one key get 409 idempotency_key_in_use, which is retryable after about a second. Keys can be up to 255 characters.
| Situation | Outcome |
|---|---|
| Same key, same Format, same body | 200, original receipt, idempotency_hit true |
| Same key, same Format, different body | 409 idempotency_conflict |
| Same key, same Format, concurrent | 409 idempotency_key_in_use, retry |
| Same key, two different Formats | Two runs, two charges |
| Key after a failed create (402, 503) | Released; retry with the same key |
A key scheme for two seasonal Formats
Say holiday-a and holiday-b are two Formats of yours and you run both on SKU 8823. Because the scope is one Format, sku-8823-v1 on each is legal and makes two runs. That is easy to misread in a log, so put the variant in the key anyway.
- Use
sku-8823-holiday-a-v1andsku-8823-holiday-b-v1: item, variant, and a version you bump only when you want a re-run. - Never derive the key from the clock or from
uuidgen; a fresh key per request disables the protection. - A bulk queue is different: replaying a spent key returns
202with the old queue, so mint a new key per batch.
Reading the receipt after a replay
A replay on one Format is easy to spot: the response is 200 and carries idempotency_hit: true, while a fresh create is 202. Log both fields with the key so a duplicate send shows up in your own records instead of in the bill.
Across two Formats there is no such signal, because each create is fresh on its own Format. If a retry loop might send the same body to the wrong Format, add a guard in your code that records which Format each key was sent to, and check it before you resend.
Tradeoff
Reusing one key across Formats gives you no cross-Format dedupe. If a retry could hit the wrong Format, your own code has to guard it. The key only protects against repeats on the same Format.
Sources
Related posts
More in Formats
- Which JSON Schema keywords a Sume Format output_schema accepts
Sume Format schemas use an allowlist: unknown keywords fail with unsupported_keyword. Number bounds are allowed; oneOf and allOf are not. Table inside.
- Which video model does a Sume Format use? Not the model field
The model field on a Sume Format run picks the orchestrating LLM, default gpt-6-sol. The Format's tools choose the image, video and audio models.
- Why did my Format run do that? Read the first message of its thread
A Format run's first thread message is the text the agent received: Format pointer, your instruction, unattended note and input file path. Read it first.
- Ready-made Formats for product video: the Sume Format catalog
Sume ships ready-made Formats for product and UGC-style video and images, each callable from your backend with one HTTP request at the reserved sume handle.
Written by Sume