Skip to main content
🤖 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.
EndpointSpecific LimitPurpose of the Route
POST /requests180/minCreation of new asynchronous queries to the court.
GET /requests180/minListing the request history.
GET /responses180/minFetching/retrieving results (lawsuit JSONs).
POST /tracking180/minRegistering new lawsuit trackings.
GET /tracking180/minListing 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:
HeaderExample Description
X-RateLimit-LimitThe total limit allowed in your time window (e.g., 180).
X-RateLimit-RemainingHow 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. 
{
  "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: 
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.prod.judit.io/requests", headers={"api-key": "your_key"})

​
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.