> ## Documentation Index > Fetch the complete documentation index at: https://docs.stackone.com/llms.txt > Use this file to discover all available pages before exploring further. # Rate Limiting > Understand StackOne's rate limits (1000 requests/minute) and how caching optimizes API performance ## 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 theme={null} 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. Cache exists only for the duration of a single request Data is immediately discarded after request completion 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 ```mermaid theme={null} sequenceDiagram participant Client as Your Application participant API as StackOne API participant Cache as Ephemeral Cache participant Provider as Integration Provider Note over Client,Provider: Single Request Lifecycle Client->>API: GET /unified/ats/applications API->>Cache: Check for job_123 details Cache->>API: Cache miss API->>Provider: Fetch job_123 details Provider->>API: Return job data API->>Cache: Store job_123 (TTL: request scope) loop Processing Applications API->>Cache: Get job_123 details Cache->>API: Return cached data Note over API,Cache: Reuse cached data end API->>Client: Return transformed applications Note over Cache: Cache cleared automatically ``` ### 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 requests **Examples**: * 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) **Up to 30 minutes** - This is extremely rare and only used for guaranteed static, non-PII data **Strict Requirements**: * Data must be guaranteed PII-free * Data must change very infrequently (e.g., system constants) * Clear business justification for extended caching **Limited Examples**: * Provider API capability flags (e.g., `"supports_custom_fields": true`) * System enumeration values (e.g., standard industry codes) * Static schema definitions that never contain user data The vast majority of data falls into the short-lived cache category. Extended caching is an exceptional case. ### Benefits of StackOne's Caching Strategy Fewer requests to providers means less chance of hitting their rate limits Cached data returns instantly, improving your application's performance Fewer API calls can reduce usage-based costs with some providers Cache serves as a buffer during temporary provider outages 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.