Skip to main content

​
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

API keys are limited to 1000 requests per minute. If you exceed this, you’ll get a rate limit response.
The 1000 requests/minute limit may change in the future.

​
What Happens When You Hit the Rate Limit?

When you hit the limit, you’ll get a 429 Too Many Requests response: 
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 providers, StackOne automatically handles retries for you:
  • Automatic Retries: When a 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.

​
How StackOne Uses Caching to Optimize Requests

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 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 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.
Typically < 2 minutes - This is the standard caching approach for most data
Purpose: Optimize data access during active list operations or related requestsExamples:
  • 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 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.
For more information on handling rate limits or troubleshooting specific issues, contact StackOne support.