# Rate limits

> The per-principal request budget and 429 semantics.

## The budget

Requests are counted **per principal** (Service Account) in a fixed one-minute window.
**Rejected requests still count.** A `429` consumes budget, so exceeding the limit repeatedly
keeps requests rejected for the remainder of the window. Back off on a `429`; do not retry
immediately.

The rate limit is **60 requests per minute** per principal.

## Exceeding the limit

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 23

{ "error": { "code": "rate-limited", "message": "…" } }
```

Wait the `Retry-After` seconds (the remainder of the current window), then resume. The response
body is the standard [error envelope](/docs/reference/errors/).

## Staying under the limit

- **Use batches.** One `GET /creators?ids=…` with 100 identifiers is one request; 100 single reads
  are 100. Batch endpoints exist so list workloads do not spend the budget one item at a time.
- **Honour `Retry-After` on `202`s.** The polling interval is server-controlled; polling faster than
  instructed spends budget without returning data sooner.
- Windows are fixed, not sliding. A burst that straddles a window boundary can briefly exceed the
  per-minute figure; this behavior should not be relied upon.