Rate limiting

Our API implements rate limiting to ensure fair usage and protect the system from abuse. This page details our rate limiting policies and how to handle them effectively.

​

Rate Limits

​

Rate Limit Headers

API responses include the following rate limit headers:

• 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: The date and time when the rate limit window resets
• Retry-After: The minimum number of seconds to wait before retrying (only when the limit has been reached)

​

Handling Rate Limits

When you exceed the rate limit, the API will return a 429 Too Many Requests HTTP status code. The response body will be:

Too many requests

​

Best Practices

1. Monitor Rate Limits: Track the X-RateLimit-Remaining header to anticipate when you’re approaching the limit
2. Implement Backoff: When you receive a 429 response:
   • Wait until the date specified in the X-RateLimit-Reset header
   • Consider implementing exponential backoff for retries
3. Batch Requests: When possible, combine multiple operations into a single request
4. Caching: Cache responses when appropriate to reduce the number of API calls

​

Example Response Headers

Rate limit not exceeded:

HTTP/1.1 200 OK
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 150
X-RateLimit-Reset: 2025-04-15T10:18:08.107Z

Rate limit exceeded:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 200
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 2025-04-15T10:18:08.107Z
Retry-After: 5

​

Custom Rate Limits

If your application requires higher rate limits, please contact our support team. We’ll work with you to establish appropriate limits based on your use case.