Docs

Guides

Idempotency

Retry POST requests safely with the Idempotency-Key header.

Networks fail. When a POST times out you cannot know whether the server processed it. Send an Idempotency-Key header so that retrying is safe: the request runs once and every retry gets the same answer.

curl -X POST "https://sdk.tilt-pay.com/v1/users" \
  -H "Authorization: Bearer $TILT_PAY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 7b1c0d36-5f0e-4d2a-9a43-0b8c6e2f1a90" \
  -d '{"phone": "+33612345678"}'

Rules#

  • The header is accepted on every POST. It is optional but recommended. Without it there is no guarantee: the request is not replayed.
  • The key is 1 to 255 printable characters. A UUID v4 is recommended. An invalid key returns 400 idempotency_key_invalid.
  • The scope is (project, environment, key): the same key can be used in sandbox and live without clashing.
  • The first request runs and its response is remembered for 24 hours. Server errors (5xx) are not remembered, so a retry runs again.
  • Replaying the same method, route and body with the same key returns the same status and body, with the header Idempotent-Replayed: true.
  • The same key with a different body or route returns 422 idempotency_key_reuse.
  • If the original request is still running, the retry returns 409 idempotency_in_progress: wait a moment and try again.

Which operations need it#

GET requests are naturally safe to retry. The suspend and unsuspend operations are idempotent by nature. Use the header for operations that create something: Create a user, Simulate a scenario and Evaluate Automation Policies.