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.

4 min readSume
All posts

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.

Idempotency-Key outcomes on a Format run create (read 2026-10-06)
SituationOutcome
Same key, same Format, same body200, original receipt, idempotency_hit true
Same key, same Format, different body409 idempotency_conflict
Same key, same Format, concurrent409 idempotency_key_in_use, retry
Same key, two different FormatsTwo 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-v1 and sku-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 202 with 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

All Formats posts

Written by Sume