POST request that creates a resource accepts an Idempotency-Key header. Retry with the same key and Deck returns the original response instead of creating a duplicate.
How it works
Include anIdempotency-Key header on any POST request that creates a resource.
- Same parameters: Deck returns the stored response. No new resource is created.
- Different parameters: Deck returns a
409 Conflictwith anidempotency_errorto prevent accidental misuse. - After 24 hours: the key expires and can be reused.
When to use them
Use idempotency keys on any create operation where a duplicate would cause problems:| Operation | Why |
|---|---|
| Opening a connection | Prevents duplicate sessions for the same user |
| Running a task | Prevents the same task from executing twice |
| Running a workflow | Prevents duplicate workflow executions |
| Creating agents, sources, tasks | Prevents duplicate resources |
GET, PATCH, or DELETE requests. Reads are naturally idempotent, updates apply the same change regardless of repetition, and deleting an already-deleted resource returns the same confirmation.
Key format
Keys can be any string up to 256 characters. UUIDs are recommended because they’re unique by design and easy to generate in any language.Generating keys
Retry pattern
A typical retry flow with idempotency:Error handling
If you reuse a key with different parameters, Deck rejects the request:409. If you see this error, generate a new key for the new request.