> ## Documentation Index
> Fetch the complete documentation index at: https://docs.landedfees.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits

> 60 requests per minute per key, 429 response shape, retry semantics, and tier upgrade paths.

## The limit

Every API key gets a sliding-window rate limit of **60 requests per
minute**. The counter resets one request at a time as older requests
fall out of the trailing 60-second window. Bursts up to 60 in the
same second are allowed; the 61st in the same 60-second window is
rejected.

The per-minute cap is a burst shaper. Your monthly quota (see
[Authentication](/authentication)) is the primary volume control.

## Rate-limit response

When the limit trips, the API returns HTTP `429` with the standard
error envelope and a `Retry-After` header in seconds:

```http theme={null}
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 42
X-Request-Id: req_9c1d2e...

{
  "error": "Too many requests. Limit 60 per minute.",
  "code": "RATE_LIMIT_EXCEEDED",
  "request_id": "req_9c1d2e...",
  "retry_after": 42
}
```

The value in `Retry-After` and `retry_after` is the number of seconds
until the oldest in-window request expires and a fresh slot opens.

## Rate-limit headers on every response

Every successful response also carries usage telemetry:

| Header                  | Meaning                                           |
| ----------------------- | ------------------------------------------------- |
| `X-RateLimit-Limit`     | Requests allowed in the current 60-second window. |
| `X-RateLimit-Remaining` | Requests remaining in the current window.         |
| `X-RateLimit-Reset`     | Unix epoch seconds when the oldest slot frees up. |

Cache the last-seen `X-RateLimit-Remaining` in your client and pace
outbound calls when it drops below your safety threshold.

## Recommended retry pattern

The official SDKs already implement this. If you are building your
own client:

1. On `429`, sleep for `Retry-After` seconds plus a small jitter
   (100 to 500 ms).
2. Retry once. If the second attempt also returns `429`, back off
   exponentially (2, 4, 8 seconds capped at 60).
3. Never retry `4xx` responses other than `429` or `408`.
4. Retry `5xx` at most twice.

## Bulk instead of loops

If you find yourself firing dozens of `/v1/calc` requests in a tight
loop, switch to `/v1/calc/bulk`. One bulk call with 500 rows counts
as one request against the rate limit and consumes one entry against
the monthly quota, versus 500 rows sent one at a time (500 requests,
500 quota entries, guaranteed rate-limit trips).

`/v1/compare` fans out up to 6 origins in parallel server-side and
counts as one call. Prefer it over 6 sequential `/v1/rates` lookups.

## Higher limits

The 60 rpm cap is per key, not per organization. Mint a second key
for a second workload before asking for a higher ceiling. If you have
a genuine sustained throughput requirement above 60 rpm per key,
Enterprise contracts include custom rate ceilings. Contact sales.