API Documentation

Rate Limiting

That Is A Q APIs implement rate limiting to ensure fair usage, system stability, and consistent performance for all clients. Understanding these limits helps you build resilient integrations.

ℹ️

Proactive Monitoring Always check rate limit headers in every response. They provide real-time information about your quota and help prevent unexpected 429 errors.

Rate Limits by Plan

Rate limits are enforced per API key and vary based on your subscription tier. Limits are calculated on a rolling window basis.

Plan	Requests / Minute	Requests / Hour	Burst Limit	Max Payload
Free	60	1,000	10 req/s	1 MB
Growth	300	10,000	25 req/s	5 MB
Scale	1,000	50,000	50 req/s	10 MB
Enterprise	Custom	Unlimited	Custom	50 MB

⚠️

Burst Limits The burst limit prevents sudden spikes in traffic. Even if you have remaining hourly quota, exceeding the per-second burst limit will trigger a 429 response.

Response Headers

Every API response includes headers that indicate your current rate limit status. These headers are essential for implementing retry logic and quota management.

                        HTTP Headers
                        
                    
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 245
X-RateLimit-Reset: 1735689600
X-RateLimit-Window: 60

Header	Description
X-RateLimit-Limit	The maximum number of requests allowed in the current window.
X-RateLimit-Remaining	The number of requests remaining in the current window.
X-RateLimit-Reset	Unix timestamp when the rate limit window resets.
X-RateLimit-Window	Duration of the rate limit window in seconds.

Handling 429 Too Many Requests

When you exceed the rate limit, the API returns a 429 Too Many Requests status code along with a JSON body containing error details and a retry-after duration.

                        JSON Response
                        
                    
{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "You have exceeded the rate limit. Please retry after 12 seconds.",
    "status": 429,
    "retry_after": 12,
    "limit": 300,
    "window": "1 minute"
  }
}

Retry Strategy

We recommend implementing exponential backoff with jitter when handling rate limit errors. This approach minimizes the chance of thundering herd problems when multiple clients retry simultaneously.

                        Python Example
                        
                    
import time
import random
import requests

def api_call_with_retry(url, max_retries=5):
    for attempt in range(max_retries):
        response = requests.get(url)
        
        if response.status_code != 429:
            return response
        
        # Exponential backoff with jitter
        base_delay = 2 ** attempt
        jitter = random.uniform(0, 1)
        delay = base_delay + jitter
        
        # Use Retry-After header if available
        retry_after = response.headers.get('Retry-After')
        if retry_after:
            delay = float(retry_after)
            
        print(f"Rate limited. Retrying in {delay:.2f}s...")
        time.sleep(delay)
        
    raise Exception("Max retries exceeded")

✅

Best Practice Always respect the Retry-After header value when provided. It indicates the exact time you should wait before making another request.

Increasing Your Limits

If your application requires higher throughput than your current plan allows, you have several options:

→ Upgrade your plan to access higher rate limits built into Growth, Scale, or Enterprise tiers.
→ Request a temporary increase for special campaigns or events by contacting our support team.
→ Optimize your integration by using webhooks, batching requests, and caching responses where possible.

                        Contact
                    
📧 Email: api-support@thatisaq.com
💬 Slack: #api-support in our customer workspace
🎫 Ticket: Submit a request via your dashboard

Frequently Asked Questions

How is the rate limit window calculated?

We use a sliding window algorithm. This means the limit is calculated based on the requests made in the past N seconds, rather than resetting at fixed clock intervals.

Do different endpoints have different limits?

Generally, limits apply globally across all endpoints. However, certain intensive operations (like bulk exports) may have separate, lower limits. These are documented in the specific endpoint documentation.

What happens when I hit the limit?

Your request will fail with a 429 status code. The request is not queued or processed in the background. You should wait for the specified duration before retrying.