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

# Rate Limits

> Learn about API rate limits and how to work with them

## Overview

The Tight API uses a number of safeguards against bursts of incoming traffic to help maximize its stability. If you send many requests in quick succession, you might see error responses with status code `429`.

<Warning>
  If you consistently exceed rate limits, your access may be temporarily blocked or degraded. Always monitor your usage and handle rate limiting gracefully to avoid service interruptions.
</Warning>

The limit is **1000 requests over a five minute window**, scoped to a Tight API `access_token`.

## Handling limits gracefully

A basic technique for integrations to gracefully handle limiting is to watch for `429` status codes and build in a retry mechanism. The retry mechanism should follow an exponential backoff schedule to reduce request volume when necessary.

Here is an example of exponential backoff in JavaScript:

```javascript theme={null}
async function fetchWithBackoff(url, options, maxRetries = 5) {
  let retries = 0;
  let delay = 1000; // Start with 1 second
  while (retries < maxRetries) {
    const response = await fetch(url, options);
    if (response.status !== 429) {
      return response;
    }
    await new Promise(res => setTimeout(res, delay));
    delay *= 2; // Exponential backoff
    retries++;
  }
  throw new Error('Max retries exceeded due to rate limiting.');
}
```

<Check>
  If your integration automatically retries with exponential backoff after receiving a 429, you are handling rate limits gracefully.
</Check>

<Tip>
  * Monitor the rate limit headers to proactively adjust your request volume.
  * Log all 429 responses for later analysis and troubleshooting.
  * Design your integration to queue or batch requests when possible to avoid bursts.
</Tip>