# Retries and idempotency

> What the gateway retries for you, and what you can retry safely. Product side: Traffic control and quotas; operations side: Resilience.

Guide - Since version 0.2.0 - Flexway v1.6.3 - https://flexway.io/en/docs/developer-retries/

> What the gateway retries for you, and what you can retry safely.
>
> Product side: [Traffic control and quotas](https://flexway.io/en/docs/product-traffic-quotas/); operations side: [Resilience](https://flexway.io/en/docs/operations-examples-rest/#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`.