Skip to main content

Idempotency

Use Idempotency-Key on supported non-GET write requests when a network timeout could leave you unsure whether the request succeeded. Public routes enable idempotency by default unless they explicitly opt out, and the request must resolve to an organization.

When to use it

Send an idempotency key for create, update, and delete jobs that your system may retry automatically:

Replay behavior

TPC keeps an idempotency reservation for 24 hours and caches successful (2xx) JSON responses within that window. Error responses and non-JSON responses are not cached. Keys are scoped to the organization, URL pathname, and method. The raw request body is hashed and compared on reuse, so changing JSON whitespace or property order can cause a conflict. Query parameters are not part of the key: use a different key for a different operation, even if only its query string changes. Use a non-empty key of at most 255 characters after trimming. Keep the same key and exact body for retries of one operation; choose a new key for each new operation.

Retry example

Generate and persist a unique key for the operation before calling this helper. Reuse it if your job restarts. This example retries network failures; handle HTTP errors such as 429 separately using the rate-limit guidance.