# Rate limits

> Gomry Cloud rate limits per API key, not per IP: the default budget, the headers to read, and how to back off correctly.

Source: https://cloud.gomry.com/docs/rate-limits

Rate limits are applied **per API key**, using a sliding window.

## Per key, never per IP

An IP-based limit is wrong in both directions: several customers behind one NAT throttle each other, and a caller distributed across many addresses evades it entirely. A key is the unit you control, so it is the unit we limit. Running two workers? Give them a key each and they get a budget each.

## Headers

Every rate-limited response carries your remaining budget. Read these rather than counting requests yourself — the window slides, so your count and ours will not agree.

- `x-ratelimit-remaining` — Requests left in the current window for this key.
- `x-ratelimit-reset` — Unix timestamp in milliseconds at which the window resets.

Exceeding the limit returns `429 rate_limited`. Back off until `x-ratelimit-reset`, with jitter — retrying the instant the window opens is how a fleet of workers synchronises itself into a thundering herd.

## Limits

The default is 120 requests per minute per key. If your workload needs more, ask — the limit exists to protect shared upstream capacity, not to sell you a tier.

> **Note:** A rate limit is not a spend control. It caps the rate of requests, not their cost. To bound what a project can spend, set a monthly budget — see [Billing](https://cloud.gomry.com/docs/billing).