# RATE_LIMITED — 429 Too Many Requests

# 429 Too Many Requests

You have exceeded the rate limit for your partner organization.

## Category

`rate_limit`

## Retryable?

**Yes.** Wait the number of seconds given in the `Retry-After` header, then retry. If the header is absent, use exponential backoff starting at 1 second.

## Rate Limit

**1,000 requests per minute, per partner organization, shared across every endpoint.**

There are no per-endpoint tiers — reads, writes and store discovery all draw on the same counter. All
API keys belonging to the same organization share that quota, and sandbox draws on the same limit as
production; there is no sandbox multiplier.

## Headers

| Header | Description |
|---|---|
| `Retry-After` | Seconds to wait before retrying. Sent on `429` responses only |

There are no `X-RateLimit-*` headers. Nothing reports a running remaining-count, so pace your client
against the limit above rather than trying to read one off a response.

## Shape

:::warning[A 429 does not use the ProblemDetail envelope]
Rate limiting is enforced at the gateway, which answers before the request reaches the API. A `429`
is therefore generated by the gateway and does **not** carry the `errorCode`, `errorCategory`,
`retryable` or `retryAfter` fields the rest of the `/errors` namespace describes.

Branch on the **`429` status code** and the **`Retry-After` header**. Do not parse a `429` body
expecting `errorCode: "RATE_LIMITED"` — that name is this page's identifier, not a value we send.
:::

## Example

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/problem+json
```

```json
{
  "type": "https://httpproblems.com/http-status/429",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "Rate limit exceeded",
  "instance": "/v1/marketfront/stores/discover",
  "trace": {
    "requestId": "req_abc123",
    "timestamp": "2026-03-11T14:30:00.000Z"
  }
}
```
