Rate Limits

The AskEdgar API enforces rate limits using a sliding window counter. Limits are applied per 1-minute window and scoped to your organization.

Limits by plan

All API keys within the same organization share the same rate limit pool. If you have multiple keys, their usage counts together toward the limit.

📬

Need higher throughput? Contact us about Enterprise plans with up to 1,000 requests per minute.

Response headers

Every successful response includes rate limit headers so you can track your usage in real time:

Rate limit exceeded (HTTP 429)

When you exceed your limit, the API returns a 429 status with details on when you can retry:

{
  "status": "error",
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Rate limit exceeded.",
    "details": {
      "limit": 200,
      "window": "1m",
      "retry_after": 42
    }
  },
  "request_id": "a1b2c3d4-5678-90ab-cdef-1234567890ab"
}

The response also includes a Retry-After header with the number of seconds to wait, and an X-Request-ID header for tracing.

Trial ticker limit

Trial and free accounts have an additional restriction: 50 unique tickers per endpoint per day, resetting at midnight Central Time. This is separate from the per-minute rate limit — you can still make requests, but each endpoint will only return data for up to 50 distinct tickers in a given day.

When exceeded:

{
  "status": "error",
  "error": {
    "code": "trial_ticker_limit",
    "message": "Trial accounts are limited to 50 unique tickers per endpoint per day.",
    "details": {
      "endpoint": "/v1/data/offerings",
      "unique_tickers_today": 50,
      "limit": 50
    }
  },
  "request_id": "a1b2c3d4-5678-90ab-cdef-1234567890ab"
}

💡

The ticker limit counts unique tickers, not requests. Querying the same ticker multiple times on the same endpoint only counts as one toward the daily limit.

Handling rate limits in your code

The most reliable approach is to monitor the headers proactively and back off before you hit the wall. Here's a pattern that handles both normal throttling and retry logic:

import time
import requests

BASE_URL = "https://api.askedgar.com"
HEADERS = {"API-KEY": "your_api_key"}

def fetch(endpoint, params):
    for attempt in range(5):
        resp = requests.get(f"{BASE_URL}{endpoint}", params=params, headers=HEADERS)

        if resp.status_code == 200:
            remaining = int(resp.headers.get("X-RateLimit-Remaining", 1))
            if remaining < 10:
                reset_at = int(resp.headers.get("X-RateLimit-Reset", 0))
                wait = max(reset_at - time.time(), 0.5)
                time.sleep(wait)
            return resp.json()

        if resp.status_code == 429:
            wait = int(resp.headers.get("Retry-After", 2 ** attempt))
            time.sleep(wait)
            continue

        if resp.status_code == 503:
            time.sleep(5)
            continue

        resp.raise_for_status()

    raise Exception("Max retries exceeded")

Key takeaways

• Monitor X-RateLimit-Remaining to slow down before hitting the limit, rather than reacting to 429s.
• Use the Retry-After header on 429 responses — it tells you exactly how long to wait.
• Fall back to exponential backoff if Retry-After isn't available for any reason.
• Handle 503s with a short fixed delay. These are transient infrastructure issues and resolve quickly.

Service unavailable (HTTP 503)

In rare cases, the rate limiting infrastructure may be temporarily unavailable. The API returns a 503 with Retry-After: 5:

{
  "status": "error",
  "error": {
    "code": "service_unavailable",
    "message": "Service temporarily unavailable. Please retry."
  },
  "request_id": "a1b2c3d4-5678-90ab-cdef-1234567890ab"
}

This does not mean your API key or account has an issue — just retry after a few seconds.

Next steps