API Rate Limiting
Reflectfy's API implements rate limiting to ensure fair usage and maintain system stability across all workspaces. This guide provides details on how rate limiting works, how to handle rate limit responses, and best practices for developers integrating with our API.
Rate Limit Overview
Reflectfy enforces a unified rate limit for all workspaces using our API. The current rate limit is set at 50 requests per minute per workspace. This limit is designed to balance fair access for all workspaces while maintaining optimal performance of our services.
How Rate Limiting Works
Each API request is tracked based on the workspace making the request. Reflectfy uses a Redis-based rate limiter to enforce these limits. If a workspace exceeds the allowed number of requests within the one-minute window, subsequent requests will be denied until the rate limit resets.
Rate Limiting Headers
When making requests to the Reflectfy API, you’ll receive several rate limit-related headers in the response. These headers help you understand your current usage and when the rate limit will reset:
X-RateLimit-Limit: The maximum number of requests allowed per minute (50 RPM).X-RateLimit-Limit-Period: The period over which the rate limit applies (1 minute).X-RateLimit-Remaining: The number of requests remaining in the current time window.X-RateLimit-Reset: The time (in seconds) until the rate limit resets.X-RateLimit-RetryAfter: If the rate limit is exceeded, this header indicates how long to wait before retrying the request.
Handling Rate Limit Responses
If a request exceeds the rate limit, the API will respond with a 429 Too Many Requests status code. The response will include the X-RateLimit-RetryAfter header, which tells you how long to wait before making another request.
Example of a rate limit exceeded response:
{
"error": "rate_limit_exceeded",
"message": "rate limit exceeded"
}
Note: It's important to implement logic in your application to handle
429responses gracefully. Consider implementing exponential backoff or queueing requests to retry after theRetry-Afterperiod.
Example Request Flow Below is an example of how the rate limiting process works for a workspace:
Initial Request: A workspace makes a request to the API. If the workspace has not exceeded their limit, the request is processed normally, and rate limit headers are returned.
Rate Limit Reached: After the 50th request in a minute, any further requests will trigger a 429 Too Many Requests response. The response includes a Retry-After header indicating when the workspace can safely make another request.
Rate Limit Reset: After the one-minute window passes, the rate limit counter resets, and the workspace can resume making requests.
Best Practices Monitor Rate Limit Headers: Always check the rate limit headers to monitor your usage and avoid hitting the limit. Implement Backoff Strategies: Use exponential backoff strategies to handle 429 responses. This helps in gracefully managing retries without overwhelming the API. Optimize API Usage: Consider batching requests or optimizing how and when you make API calls to stay within the rate limit. Conclusion Rate limiting is crucial for maintaining the reliability and performance of Reflectfy's API. By understanding and respecting these limits, you can ensure a smooth integration experience and avoid disruptions to your service.
For any questions or issues related to rate limiting, feel free to reach out to our support team at support@reflectfy.com.