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.
HTTP/1.1 429 Too Many Requests
Retry-After: 60
The Retry-After header is included in the response when a rate limit is triggered. It provides guidance on how long the client should wait before making a subsequent request. The Retry-After value can be expressed either as a value in seconds or as a specific date/time. At StackOne we will return the value in seconds.

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)
This means you don’t need to implement provider-specific retry logic in your application - StackOne handles this complexity for you while respecting provider rate limits.

Best Practices for Rate Limiting

If you consistently hit the rate limit, consider optimizing your API usage, such as by caching responses or batching requests, to reduce the number of calls made. For more information on handling rate limits or troubleshooting specific issues, feel free to reach out to StackOne support.