Retries and idempotency
GuideDevelopersSince version 0.2.0
On this page
What the gateway retries for you, and what you can retry safely.
Product side: Traffic control and quotas; operations side: Resilience.
What the gateway retries
| Rule | Detail |
|---|---|
| Methods | Idempotent ones (GET, HEAD, PUT, DELETE), or any request carrying Idempotency-Key |
| Causes | Connection refused or cut, the API's 502, 503 - never a 4xx, never a response timeout |
| Limits | At most two attempts, under a retry budget, and never after the first byte was sent |
What you can retry
| Response | Read | Write |
|---|---|---|
429, 503 |
After Retry-After |
After Retry-After |
502, 504 |
Yes | Only with the same Idempotency-Key, which the API (or the broker) deduplicates |
Other 4xx |
No: fix the request | No |
Send a unique Idempotency-Key (a UUID) on every write; it is relayed to the API. On a publishing door
it may be required (428) and becomes the event's id.