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

# Rate limits

> How the Nuvia API handles request limits today

This page factually describes the request limits the Nuvia API applies **today**.
To authenticate your calls, see [Authentication](/en/autenticacao).

## REST API (calls with an API key)

There's currently **no per-route request limit** applied to calls authenticated by API key.
We don't publish a requests-per-second or requests-per-minute number for the main REST API because
no limit of that kind is in effect.

<Note>
  Even without a per-route limit today, design your integration to be resilient: handle
  `429 Too Many Requests` responses with **retry and exponential backoff**. That way, if limits are
  applied in the future, your code already handles them without changes.
</Note>

## Limits that exist today

Some specific flows have a limit applied. They respond `429 Too Many Requests` with the body:

```json theme={null}
{
  "statusCode": 429,
  "message": "..."
}
```

| Flow                                  | Limit       | Window     | Counted by |
| ------------------------------------- | ----------- | ---------- | ---------- |
| OAuth / MCP (`/token`, `/register`)   | 60 requests | 60 seconds | IP address |
| Password recovery (`forgot-password`) | 3 requests  | 1 hour     | Email      |

<Warning>
  These `429` responses **don't** include rate limit headers: there's no `X-RateLimit-Limit`,
  `X-RateLimit-Remaining`, or `Retry-After`. Don't rely on these headers to decide when to retry
  the request; use your own backoff strategy.
</Warning>

## Recommendation

<Steps>
  <Step title="Implement retry with backoff">
    When you get a `429`, wait before retrying and increase the interval with each new attempt
    (exponential backoff), with a cap on attempts.
  </Step>

  <Step title="Don't rely on limit headers">
    Since `429` responses don't carry rate limit headers, base your backoff on your own timing
    logic, not on values returned by the API.
  </Step>
</Steps>