Skip to main content

​
Rate Limits

The RouteMCP API uses a sliding window rate limiting model to ensure fair usage and platform stability.

​
Limits by Plan

PlanRequests per Minute
Individual100
Team500
Organization2,000
Rate limits are applied per API key. Each key has its own counter.

​
Rate Limit Headers

Every API response includes rate limit headers:
HeaderDescription
X-RateLimit-LimitMaximum requests allowed per window
X-RateLimit-RemainingRequests remaining in the current window
X-RateLimit-ResetUnix timestamp when the window resets
HTTP/1.1 200 OK
X-RateLimit-Limit: 500
X-RateLimit-Remaining: 498
X-RateLimit-Reset: 1709913600

​
Handling 429 Responses

When you exceed the rate limit: 
{
  "success": false,
  "statusCode": 429,
  "message": "Rate limit exceeded. Try again in 45 seconds."
}
The response includes a Retry-After header with the number of seconds to wait.

​
Retry with Backoff

async function requestWithRetry(url, headers, maxRetries = 3) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, { headers });

    if (response.status !== 429) return response;

    const retryAfter = parseInt(response.headers.get("Retry-After") || "60");
    const delay = retryAfter * 1000 * Math.pow(2, attempt);

    await new Promise(resolve => setTimeout(resolve, delay));
  }
  throw new Error("Max retries exceeded");
}

import time
import requests

def request_with_retry(url, headers, max_retries=3):
    for attempt in range(max_retries + 1):
        response = requests.get(url, headers=headers)
        if response.status_code != 429:
            return response

        retry_after = int(response.headers.get("Retry-After", 60))
        time.sleep(retry_after * (2 ** attempt))

    raise Exception("Max retries exceeded")

​
Provider Rate Limits

Connected CRM providers have their own rate limits. When a provider limit is hit: 
{
  "success": false,
  "statusCode": 429,
  "code": "PROVIDER_RATE_LIMITED",
  "message": "Provider rate limit exceeded"
}
This is separate from the RouteMCP API’s own rate limit. The Retry-After value reflects the provider’s reset time.

​
Best Practices

  1. Use cursor pagination — fetch pages of data instead of individual records
  2. Cache responses where appropriate
  3. Monitor X-RateLimit-Remaining — slow down before hitting the limit
  4. Respect Retry-After — always wait the indicated time before retrying
  5. Use sk_test_ keys during development — same limits, no production impact