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

# Rate limits

> How many requests you can make, and how to stay within them.

Every API key can make **120 requests per minute**, on every plan. There is no monthly
request limit.

## Endpoint limits

Some endpoints have an additional limit on top of the per-key rate.

| Endpoints                                          | Limit                                             |
| -------------------------------------------------- | ------------------------------------------------- |
| Reading full answer text                           | 600 per hour                                      |
| Creating and deleting brands, prompts and topics   | 30 per minute, 300 per hour                       |
| Content, audits, optimizations and recommendations | 2 to 10 per minute, and at most 2 running at once |

These limits apply to API requests only. Your usage in the dashboard is not affected.

Requests made through the [MCP server](/docs/mcp/introduction) count against exactly these
limits, because each tool call is one API request made with your key.

## Rate limit headers

Every response reports your current limit status, so you can pace a job without waiting for a
rejection.

| Header                        | Description                                                 |
| ----------------------------- | ----------------------------------------------------------- |
| `X-RateLimit-Limit`           | Requests allowed per minute                                 |
| `X-RateLimit-Remaining`       | Requests left in the current minute                         |
| `X-RateLimit-Reset`           | Unix timestamp when the window resets                       |
| `X-Endpoint-Limit-Minute`     | The endpoint's own per-minute limit, where it has one       |
| `X-Endpoint-Remaining-Minute` | Requests left against that per-minute limit                 |
| `X-Endpoint-Reset-Minute`     | Unix timestamp when that per-minute limit frees a slot      |
| `X-Endpoint-Limit-Hour`       | The endpoint's own hourly limit, where it has one           |
| `X-Endpoint-Remaining-Hour`   | Requests left against that hourly limit                     |
| `X-Endpoint-Reset-Hour`       | Unix timestamp when that hourly limit frees a slot          |
| `Retry-After`                 | Seconds to wait, sent on `429` responses                    |
| `X-Request-Id`                | Identifier for this request, useful when contacting support |

Headers appear only for limits that apply to the request you made.

Limits are measured over a **rolling** window rather than a fixed clock hour, so a
slot frees exactly one window after the request that used it. The `*-Reset` headers
give you that moment, which is why you can pace a job without ever seeing a `429`.

## 429 responses

A `429` tells you which limit you reached:

| Code                    | Meaning                              | What to do                                                                                      |
| ----------------------- | ------------------------------------ | ----------------------------------------------------------------------------------------------- |
| `rate_limited`          | Your key's per-minute rate           | Wait until `X-RateLimit-Reset`                                                                  |
| `endpoint_rate_limited` | That endpoint's own limit            | Wait until `X-Endpoint-Reset-Minute` or `X-Endpoint-Reset-Hour`, whichever the response carries |
| `concurrency_limited`   | Too many generation requests at once | Wait for one to finish                                                                          |

`Retry-After` on any of these is the exact number of seconds until that moment, so
obeying it is enough.

## Best practices

* **Use the headers.** Retry at the time given in the matching `*-Reset` header, or after
  the seconds in `Retry-After`, rather than on a fixed interval. Both are computed from the
  rolling window, so a fixed guess will either retry too early or wait far longer than needed.
* **Spread scheduled jobs.** Pace exports and syncs across the window instead of firing
  everything at once.
* **Add jitter.** If several workers share one key, randomise retry timing slightly so they
  do not retry in lockstep.
* **Cache what rarely changes.** Brand and topic lists change far less often than metrics.

## Need a higher limit

Contact [support@geoptie.com](mailto:support@geoptie.com) with your use case.