Add idempotency keys to prevent duplicate generations
Johnathan Lightfoot
In automation workflows, retries happen. A workflow can timeout, fail, or be manually re-run. Without an idempotency key, the same request can accidentally create duplicate decks and use extra credits.
It would help if Gamma supported a clientRequestId or idempotencyKey on generation requests. If the same key is submitted again, Gamma could return the existing generation instead of creating a new one.
This would make the API safer for production use.
Nik Payne (Gamma design)
Hey Johnathan Lightfoot, this is a really solid callout, and yeah retries in automation are basically guaranteed. I’ll pass this along to the team as a request for an idempotency key (clientRequestId) on generation requests so replays return the original result instead of burning credits on duplicates.
Quick question so we scope it right: would you want the key to dedupe only identical payloads, or dedupe any request with the same key regardless of payload changes (and if so, what should happen on a mismatch)?
Johnathan Lightfoot
Nik Payne (Gamma design) Great question! I'd tie the key to the original request payload.
First request with a clientRequestId creates the generation and stores a payload hash. Same key + same payload again → return the original result, no extra credits burned.
Same key + different payload → please don't silently make a new deck or quietly hand back the old one. Just give a clear conflict error (409 idempotency_key_payload_mismatch or similar) saying that key was already used for a different request.
That covers the two failure modes: accidental duplicate generations, and workflows that change the prompt/theme/export settings but forget to rotate the key.
So in short:
- Same key + same payload = original result
- Same key + different payload = 409 conflict
- Scope the key to the workspace/API key
- Some retention window would help — 7–30 days feels right, since retries can come late after a failure