API Reference

Rate Limits

Understand request limits, rate limit headers, and best practices for staying within your quota.

Overview

The ReadyRaider API enforces rate limits per API key to ensure fair usage and platform stability. Rate limits use a sliding window algorithm — requests are counted over a rolling 60-second window.

Your rate limit depends on your subscription plan. Premium subscribers get significantly higher limits to support more demanding integrations.

Limits by Plan

Rate limits vary based on your subscription tier and the type of endpoint:

FreePlan

Endpoint Type	Limit	Window	Applies To
Standard	60 requests	60 seconds	GET (read) endpoints
Strict	20 requests	60 seconds	POST, PUT, DELETE (write) endpoints

PremiumPlan

Endpoint Type	Limit	Window	Applies To
Standard	300 requests	60 seconds	GET (read) endpoints
Strict	100 requests	60 seconds	POST, PUT, DELETE (write) endpoints

Note

Rate limits are tracked per API key, not per IP address. Different API keys have independent rate limit counters. Your limit is determined by your squad's subscription tier. Upgrade to Premium for 5x higher limits.

Rate Limit Headers

Every API response includes rate limit headers so you can monitor your usage:

Response Headershttp

X-RateLimit-Limit: 60
X-RateLimit-Remaining: 57
X-RateLimit-Reset: 1739443200

Header	Description
`X-RateLimit-Limit`	The maximum number of requests allowed in the current window
`X-RateLimit-Remaining`	The number of requests remaining before hitting the limit
`X-RateLimit-Reset`	Unix timestamp (seconds) when the rate limit window resets

Exceeding the Limit

When you exceed the rate limit, the API returns a 429 Too Many Requests response with a Retry-After header:

429 Response Headershttp

HTTP/1.1 429 Too Many Requests
Retry-After: 23
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1739443200

429 Response Bodyjson

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Rate limit exceeded. Try again in 23 seconds.",
    "details": []
  }
}

Best Practices

Monitor Rate Limit Headers

Check X-RateLimit-Remaining in your responses. When it reaches zero, wait until X-RateLimit-Reset before making more requests.

Implement Exponential Backoff

If you receive a 429, use exponential backoff with jitter. Start with the Retry-After value and increase the delay with each retry.

Cache Responses

Cache API responses on your end when data doesn't change frequently. Tournament brackets and standings don't need to be fetched every second.

Use Pagination Efficiently

Fetch only what you need. Use pagination parameters to limit the amount of data per request rather than fetching everything and filtering client-side.

Example: Rate-Aware Client

Here's a simple JavaScript example that respects rate limits:

Rate-Aware Fetchjavascript

async function fetchApi(path) {
  const res = await fetch(`https://readyraider.com/api/v1${path}`, {
    headers: { Authorization: `Bearer ${API_KEY}` },
  });

  // Check remaining requests
  const remaining = parseInt(res.headers.get("X-RateLimit-Remaining") ?? "0");
  if (remaining <= 5) {
    console.warn(`Rate limit warning: ${remaining} requests remaining`);
  }

  // Handle 429
  if (res.status === 429) {
    const retryAfter = parseInt(res.headers.get("Retry-After") ?? "60");
    console.log(`Rate limited. Retrying in ${retryAfter}s...`);
    await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000));
    return fetchApi(path); // Retry
  }

  return res.json();
}

PreviousAuthentication

NextError Handling