Idempotency
For create operations that have side effects (e.g. creating a call or an agent), you can send an idempotency key so that duplicate requests are detected and the same response is returned instead of creating a second resource.Header
Send the header on the request:- Key format: Any unique string. We recommend a UUID (e.g.
550e8400-e29b-41d4-a716-446655440000) or a string that is unique per logical operation in your system. - Scope: Keys are scoped per organization (per API key). The same key can be used for only one create operation per endpoint; duplicate requests with the same key and same endpoint/body return the cached response.
Supported endpoints
| Method | Endpoint | Idempotency |
|---|---|---|
| POST | /agents | Yes |
| POST | /calls | Yes |
| POST | /batch-calls | Yes |
| POST | /tools | Yes |
/knowledge-bases, POST /voices) do not currently support X-Idempotency-Key. Send the header only on the endpoints listed above.
Behavior
- First request with a given key: The request is processed normally. The response (status code and body) is stored and associated with that key. You receive 201 Created and the new resource in
data. - Duplicate request (same key, same endpoint, same request body): The server returns the same response as the first request (201 and the same
data), without creating a second resource. Use this to safely retry after timeouts or network errors. - Same key, different body: Treated as a new request; if the key was already used, behavior may vary. Always use a new key for each distinct create operation.
TTL and cleanup
Stored idempotency responses are cleaned up periodically. Do not rely on a key being valid indefinitely. For retries, use the same key within a short window (e.g. minutes to hours).Example
Best practices
- Generate a new idempotency key for each distinct create (e.g. one per call, one per agent).
- Use the same key when retrying the same logical request (e.g. after a timeout).
- Do not reuse keys across different request bodies or endpoints.