Understanding Rate Limiting
In the context of APIs, rate limiting controls how many requests a client can make to a service in a specified period of time. It’s a way of ensuring that individual users or services don’t monopolize resources by making excessive or unnecessary requests. Rate limiting is especially important for shared services or public APIs where multiple users may be accessing the same resources. When a service reaches its rate limit, it will typically respond with a 429 Too Many Requests HTTP status code, indicating that the client needs to wait before retrying their request.StackOne’s Rate Limiting Policy
At StackOne, we impose rate limits on API keys to ensure fair access to the API and maintain the performance and reliability of our systems. Each API key is limited to a maximum of 1000 requests per minute. This means that any API key making more than 1000 requests in a 60-second window will receive a rate limit response.StackOne’s current rate limit is 1000 requests per minute. Please note that this rate limit may be adjusted in the future as needed.
What Happens When You Hit the Rate Limit?
If your API key exceeds the rate limit, StackOne will return a standard 429 Too Many Requests response. This response indicates that you have hit the rate limit and need to wait before sending more requests.Handling Rate Limiting in Your Application
To properly handle rate limiting, you need to read the 429 response code and the Retry-After header in your application, then implement backoff logic to pause and retry the request after the specified wait time.StackOne’s Automatic Retry Mechanism
When you encounter rate limits from integration providers, StackOne automatically handles retries for you:- Automatic Retries: When an integration provider returns a 429 response, StackOne automatically retries the request using the provider’s
Retry-After
header - Retry Attempts: Up to 5 consecutive retry attempts are made before returning the original 429 response
- Request Timeout: If retries exceed the 60-second request lifetime, a 408 Request Timeout is returned instead
- Retry-After Headers: Both 429 and 408 responses include appropriate
Retry-After
headers (either from the original provider response or a default 60 seconds)