The Developer API rate-limits requests using a moving-window strategy backed by
Redis. Limits are applied per authenticated tenant + endpoint.
Limits
| Endpoint type | Methods | Limit |
|---|
| Read | GET | 300 requests/min |
| Write | POST, PATCH | 60 requests/min |
| Endpoint | Limit |
|---|
GET /developer/vouchers | 300/min |
GET /developer/vouchers/{code} | 300/min |
POST /developer/vouchers | 60/min |
POST /developer/vouchers/{code}/redeem | 60/min |
GET /developer/products | 300/min |
GET /developer/products/{product_id} | 300/min |
GET /developer/customers | 300/min |
GET /developer/customers/{customer_id} | 300/min |
POST /developer/customers | 60/min |
PATCH /developer/customers/{customer_id} | 60/min |
When you exceed a limit
A request that exceeds its limit returns 429 Too Many Requests with this
body:
{
"detail": "Rate limit exceeded. Too many requests."
}
| Header | Meaning |
|---|
X-RateLimit-Limit | The configured request limit for the window |
X-RateLimit-Remaining | Always 0 on a 429 |
X-RateLimit-Reset | Unix timestamp (seconds) at which the window resets |
Retry-After | Seconds to wait before retrying |
These rate limit headers are only returned on 429 responses. Successful
2xx responses currently do not carry X-RateLimit-* headers – clients should
pace themselves based on their own counters or back off when they see a 429.
Retry strategy
On 429, wait for Retry-After seconds (or fall back to a few seconds of
exponential backoff if the header is missing) and retry the same request.
Voucher creation and customer creation are not automatically idempotent – if you retry a POST after a network timeout, use the
Idempotency page to understand what is and isn’t
deduplicated. 
