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

# Rate Limits on the Judit API

> Judit API rate limits: 180 requests per minute per API Key. Best practices for exponential backoff and reading X-RateLimit headers to avoid HTTP 429 responses.

> 🤖 The Judit API has a strict global limit of 180 requests per minute per API Key. If this limit is exceeded, the API will return the HTTP Status Code `429 Too Many Requests`. Code generators should always implement *Exponential Backoff* logic or respect the time window by reading the `X-RateLimit-*` headers.

## Rate Limit Rules (Global)

To ensure ecosystem stability, every authenticated request is subject to the following global rules:

* **Consumption Limit:** 180 requests per minute (per API Key).
* **Mechanism:** 60-second *Sliding Window*. This means that the limit does not reset rigidly at the top of the minute on the clock, but rather by calculating the volume of requests in the last 60 running seconds.
* **Reset:** Automatic, as soon as the oldest requests leave the 60-second window.

### Limits per Endpoint

The 180-requests-per-minute limit is shared across the main data-in and data-out services.

| Endpoint         | Specific Limit | Purpose of the Route                               |
| :--------------- | :------------- | :------------------------------------------------- |
| `POST /requests` | 180/min        | Creation of new asynchronous queries to the court. |
| `GET /requests`  | 180/min        | Listing the request history.                       |
| `GET /responses` | 180/min        | Fetching/retrieving results (lawsuit JSONs).       |
| `POST /tracking` | 180/min        | Registering new lawsuit trackings.                 |
| `GET /tracking`  | 180/min        | Listing active trackings.                          |

***

## Monitoring Your Consumption (HTTP Headers)

You don't need to guess how many requests you still have. Every successful response (200 OK) from the Judit API includes specific headers that help your application monitor consumption in real time:

| Header                  | Example Description                                                      |
| :---------------------- | :----------------------------------------------------------------------- |
| `X-RateLimit-Limit`     | The total limit allowed in your time window (e.g., `180`).               |
| `X-RateLimit-Remaining` | How many requests you can still make in the current window (e.g., `42`). |

> **💡 Architecture Tip:** We recommend that your application read the `X-RateLimit-Remaining` header. If the value drops below 10%, implement a small *sleep* in your batch-extraction routines to avoid being blocked (Error 429).

***

## How to Handle Error 429 (Too Many Requests)

If you exceed the limit of 180 requests in 60 seconds, the Judit API will temporarily block new calls and return the `429` error.

```json theme={null}
{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Try again in a few seconds.",
  "code": 429
}
```

For robust systems, best practice is to implement a **Retry with Exponential Backoff**. See the production-ready examples below:

<CodeGroup>
  ```python Python theme={null}
  import time
  import requests

  def request_with_retry(url, headers, max_retries=3):
      """Runs a request implementing smart waiting if it hits the limit."""
      base_delay = 2 # Initial wait in seconds
      
      for attempt in range(max_retries):
          response = requests.get(url, headers=headers)
          
          # Success
          if response.status_code == 200:
              return response.json()
              
          # Limit exceeded (Error 429)
          if response.status_code == 429:
              # Exponential backoff: 2s, 4s, 8s...
              sleep_time = base_delay * (2 ** attempt)
              print(f"⚠️ Limit exceeded (429). Waiting {sleep_time} seconds... (Attempt {attempt + 1}/{max_retries})")
              time.sleep(sleep_time)
              continue
              
          # Other errors stop execution immediately
          response.raise_for_status()
          
      raise Exception("Failed after all retry attempts (Rate Limit).")

  # Example usage
  # data = request_with_retry("https://requests.production.judit.io/requests", headers={"api-key": "your_key"})
  ```

  ```javascript Node.js theme={null}
  async function requestWithRetry(url, headers, maxRetries = 3) {
      // Runs a request implementing smart waiting if it hits the limit.
      let baseDelay = 2000; // Initial wait in milliseconds
      
      for (let attempt = 0; attempt < maxRetries; attempt++) {
          const response = await fetch(url, { headers });
          
          // Success
          if (response.ok) {
              return await response.json();
          }
          
          // Limit exceeded (Error 429)
          if (response.status === 429) {
              // Exponential backoff: 2000ms, 4000ms, 8000ms...
              const sleepTime = baseDelay * Math.pow(2, attempt);
              console.warn(`⚠️ Limit exceeded (429). Waiting ${sleepTime}ms... (Attempt ${attempt + 1}/${maxRetries})`);
              
              await new Promise(resolve => setTimeout(resolve, sleepTime));
              continue;
          }
          
          // Other errors
          throw new Error(`HTTP Error: ${response.status}`);
      }
      
      throw new Error("Failed after all retry attempts (Rate Limit).");
  }
  ```
</CodeGroup>

***

## Next Steps

If your application has a massive data volume (continuous ETL, cleansing of historical bases with millions of rows) and the 180-requests-per-minute limit is a bottleneck, we can help.

* 👉 **Talk to us:** [Contact our engineering team via WhatsApp](https://api.whatsapp.com/send/?phone=5511920501949) to discuss custom limits and dedicated routes for your volume.
* 👉 **[Error Handling](/en/resource/errors):** See the complete list of errors the API can return beyond 429.
* 👉 **[Pagination](/en/essentialConcepts/pagination):** Review how to iterate over large lists safely.