To ensure system stability, prevent abuse, and maintain fair usage across all integrations, InterAction+™ Cloud API implements robust Rate Limiting and Complexity Analysis mechanisms. These measures help protect against Denial-of-Service (DoS) attacks, ensure that no single client can monopolize API resources, and maintain a consistent experience for all users.
Importance of Rate Limiting and Complexity Analysis
Without proper rate limiting, APIs are vulnerable to abuse, including excessive requests from malicious actors or misconfigured clients, leading to service degradation or unavailability. Complexity Analysis ensures that overly complex queries do not consume excessive system resources, impacting the InterAction+™ Cloud API’s performance. Together, these controls help:
- Protect against DoS attacks by limiting the requested volume from any single source.
- Ensure fair resource allocation so that one client does not degrade performance for others.
- Maintain system stability and reliability by preventing server overloads caused by excessive traffic or computationally expensive queries.
Rate Limiting Strategy
InterAction+™ Cloud API enforces Rate limits using two different approaches:
- Fixed Window Rate Limiting: This method divides time into fixed intervals (e.g., an hour or a day). Once the limit is reached within the window, all further requests are rejected until the next interval starts.
- Sliding Window Rate Limiting: This approach divides the timeframe into smaller segments (e.g., dividing a minute into six 10-second segments) and maintains a rolling count of requests. This method helps manage traffic bursts by maintaining a rolling count of requests rather than resetting at fixed intervals. This ensures that requests are distributed more evenly. For example, if a minute limit is divided into six 10-second segments, the system continuously evaluates the last 60 seconds rather than restarting every full minute. This approach smooths traffic spikes, allows sustained throughput, and reduces sudden load surges on the server
Rate Limits
- Rate limiting is enforced across multiple timeframes to balance performance and prevent excessive API usage. The applied limits are:
- 5 requests per second
- 100 requests per minute, divided into six equal segments using a Sliding Window algorithm to handle traffic bursts efficiently (~ 16 requests every 10 seconds).
- 6,000 requests per hour (Fixed limit)
- 18,000 requests per day (Fixed limit)
- If a request exceeds the rate limit for any timeframe, it will be rejected with an HTTP 429 (Too Many Requests) response.
- When applicable, the response will include the number of seconds until the client can retry.
- Rate limits are enforced independently for each unique connection, defined as a combination of Third-Party Client and Tenant.
Complexity Analysis
To prevent excessive server resource consumption due to complex GraphQL queries, the InterAction+™ Cloud API enforces complexity constraints by analyzing query depth and computational cost. This ensures that overly complex queries do not degrade performance.
- Query Depth: Limits the maximum depth of nested queries to prevent deeply recursive structures that could cause excessive processing time. The current limit is 25 levels deep.
- Complexity Score: The system calculates the total complexity score of a query and rejects any request exceeding the max allowed complexity.
- Handling Complexity Violations: If a request exceeds the defined MaxDepth or MaxComplexity, the API will reject it with an error message.
Best Practices
Third-Party Client should follow best practices to optimize API usage while staying within rate limits.
- They should design efficient queries by requesting only necessary fields and avoiding deeply nested structures to reduce processing time.
- Distribute requests over time instead of sending bursts in short intervals.
- Implement caching to help minimize redundant requests and reduce API load.\
- Handle rate limit responses gracefully by managing 429 Too Many Requests errors and using rate limit response headers to implement exponential backoff or retry mechanisms.