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)
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.How StackOne Uses Caching to Optimize Requests
Caching Infrastructure for Performance Optimization
Caching Infrastructure for Performance Optimization
StackOne uses intelligent caching to optimize performance and minimize rate limits while maintaining strict privacy standards and data freshness.
1. Ephemeral Memory Cache During Request Lifecycle
During the processing of a single unified API request, StackOne uses ephemeral in-memory caching to avoid redundant calls to integration providers.Request-Scoped
Cache exists only for the duration of a single request
No Persistence
Data is immediately discarded after request completion
Automatic Cleanup
Memory is freed as soon as the request completes
Common Use Cases
- Ticketing Systems: When listing tickets with associated agents, projects, and categories, we cache agent profiles and project metadata to avoid repeated lookups for each ticket
- Account Hierarchies: Storing parent account information when processing related contacts, opportunities, or cases in CRM systems
- Category & Tag Mappings: Caching taxonomy data (categories, tags, labels) when processing multiple content items, learning objects, or documents that share classifications
- Permission & Role Definitions: Temporarily storing role-based access control data when evaluating permissions across multiple resources in a single request
- Currency & Locale Data: Caching exchange rates and regional settings when processing financial data across multiple entities
- Field Definitions: Caching custom field schemas and metadata when transforming records across different integration providers
2. Redis Cache for Cross-Request Optimization
For data that is frequently requested across multiple API calls, StackOne uses Redis with carefully managed TTLs.- Short-lived Cache
- Rare Extended Cache
Typically < 2 minutes - This is the standard caching approach for most data
- Pagination tokens for active dataset traversal
- Data relationships during a listing operation
- Temporary results while a user navigates through pages
If data potentially contains PII, it’s cached only for the lifecycle of a listing operation (typically seconds to a couple of minutes maximum)
Benefits of StackOne’s Caching Strategy
Reduced Provider Load
Fewer requests to integration providers means less chance of hitting their rate limits
Improved Response Times
Cached data returns instantly, improving your application’s performance
Cost Optimization
Fewer API calls can reduce usage-based costs with some providers
Reliability
Cache serves as a buffer during temporary provider outages
Privacy-First
Intelligent data classification ensures PII is never cached
For more information about customizing caching behavior for your use case, contact StackOne support.