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

# Rate Limits

> Understand FNLB's API rate limiting policies to avoid throttling and ensure smooth integration.

## Overview

Rate limits exist across FNLB's APIs to prevent spam, abuse, and service overload. The FNLB API uses **global rate limiting** as well as **per-endpoint rate limits** to ensure fair usage and protect system stability.

***

## Global Rate Limit

* **Limit**: `100 requests per 10 seconds`
* **Scope**: Per IP Address (globally across all endpoints)
* **Reset**: Every 10 seconds

This means you can make up to **100 requests total across all endpoints** within any rolling 10-second window. Exceeding this limit will result in a `429 Too Many Requests` error.

***

## Per-Endpoint Rate Limits

In addition to the global rate limit, some API endpoints may have **individual rate limits** based on their sensitivity or resource intensity. These limits help prevent misuse of specific endpoints and ensure availability for all users.

* Rate limits vary by endpoint.
* Limits are enforced **in addition to** the global rate limit.
* If a per-endpoint limit is exceeded, a `429` error will be returned.

You should design your client to **handle rate limiting dynamically**, regardless of whether it's global or endpoint-specific.

***

## Exceeding the Limit

When you exceed either a global or per-endpoint rate limit, the server responds with:

```http theme={null}
HTTP/1.1 429 Too Many Requests
Retry-After: 10
Content-Type: application/json
```

```json theme={null}
{
    "type": "error",
    "errors": [
      {
        "type": "general",
        "errorCode": "net.fnlb.errors.common.rate_limit_exceeded",
        "message": "You are being rate limited."
      }
    ]
  }
```

* `Retry-After` header indicates how many seconds to wait before retrying.

***

## Best Practices

* **Implement retry logic**: Automatically back off and retry after the time specified in the `Retry-After` header.
* **Avoid bursts**: Spread your requests evenly over time.
* **Queue your requests**: Use a task queue or request scheduler in your app to prevent accidental spikes.
* **Monitor usage**: Keep track of your request volume and avoid unnecessary calls.

***

## Example in JavaScript (with Retry)

```js theme={null}
async function fetchWithRetry(url, options, retries = 3) {
  for (let i = 0; i < retries; i++) {
    const res = await fetch(url, options);
    if (res.status !== 429) return res;

    const retryAfter = res.headers.get("Retry-After");
    const waitTime = (retryAfter ? parseInt(retryAfter) : 10) * 1000;
    await new Promise(resolve => setTimeout(resolve, waitTime));
  }
  throw new Error("Rate limit exceeded after multiple retries.");
}
```

***

## 💡 Need More Capacity?

If your application needs higher throughput, contact FNLB Support to request increased rate limits.

<Card title="Join Discord" icon="discord" href="https://fnlb.net/discord">
  Get help, support, or chat with other developers
</Card>