Rate Limit
Rate limits are restrictions that our API imposes on the number of times a user or client can access our services within a specified period of time.
Why do we have rate limits?
Rate limits are a common practice for APIs, and they're put in place for a few different reasons:
- Protection Against Abuse: Rate limits help protect our API from misuse, whether intentional or unintentional. For instance, they mitigate the risk of malicious actors flooding the API with requests in an attempt to overload it, potentially causing service disruptions or denial-of-service (DoS) attacks. By setting rate limits, AccelByte can prevent this kind of harmful activity.
- Ensuring Fair Usage: Rate limits promote equitable access to the API. If one user or organization made an excessive number of requests, it could degrade performance for everyone else. By throttling requests, AccelByte ensures fair resource availability, promoting a consistent experience for every customer on our platform.
- Maintaining Infrastructure Stability. If requests to the API increase dramatically, it could tax the servers and cause performance issues. By setting rate limits, AccelByte can help maintain a smooth and consistent experience for all users.
This API rate limit governs the frequency of API requests as outlined in this document. It is separate and distinct from other types of limitations or quotas, such as those associated with a Shared Cloud free trial.
How do these rate limits work?
In Shared Cloud
Rate limits are measured in RPM (requests per minute). If the number of requests exceeds the defined limit within that minute, subsequent requests will be temporarily blocked (throttled) until the count drops below the limit in the next time window.
Shared Cloud utilizes a two-tiered rate limiting system to provide flexibility and control, by default, the following rate limits are in place:
- Studio-Level Rate Limit: 5000 requests per minute (default)
- Scope: This is a global limit applied to your studio. It counts the total number of requests made by all users associated with your studio combined.
- Purpose: Sets an overall ceiling on your studio's usage to ensure fair resource allocation across all customers.
- Example: If the limit is 5000 RPM, the sum of requests from all users associated with your studio cannot exceed 5000 in any given minute.
- User-Level Rate Limit: 500 requests per minute (default)
- Scope: This limit is applied individually to each user.
- Purpose: Prevents any single user from consuming an excessive portion of the studio's overall limit or impacting other users associated with the same studio.
- Constraint: The user-level limit is always less than or equal to the studio-level limit.
- Example: If the limit is 500 RPM, no single user can make more than 500 requests in any given minute, regardless of the remaining studio-level capacity.
Both the Studio-level and User-level limits must be respected simultaneously.
- A request will be throttled, if either:
- The individual user making the request has exceeded their User-level RPM limit.
- The total number of requests from all users associated with the studio has exceeded the studio-level RPM limit, even if the specific user making the request is still below their individual limit.
Per-API Rate Limits
Certain critical or resource-intensive API endpoints may have their own specific IP-based rate limits, independent of the organization and user limits.This protects specific, high-demand endpoints (like login) from being overwhelmed by traffic, even if the overall organization or user limits haven't been reached.
In Private Cloud
Rate limit can be discussed in multiple occasions throughout your title’s development lifecycle:
- As part of AccelByte’s General Architecture Review, we will assess your current usage of AccelByte APIs and provide recommendations to ensure there’s no misuse of endpoints that can increase the chances of rate limits being hit.
- As part of AccelByte Launch Readiness protocol for your game, we will do capacity planning to ensure that the current environment capacity can handle the traffic you are expecting, this includes consideration of rate limits.
Limit Standards
While default rate limits are in place, we may adjust these at our discretion to support your application's evolving needs. We strongly encourage all users to implement API best practices, such as minimizing unnecessary calls and utilizing batch endpoints where available. Adopting these practices can help optimize your usage and reduce the likelihood of unexpectedly reaching your rate limit.
If you have access to our support ticket system or an assigned account manager, you can discuss your rate limit needs further through these channels. This will help ensure a seamless experience for your players as your application scales.
Mitigating throttling issues
How can I know that I’ve hit the rate limit?
When you get throttled, you will receive 429 HTTP code with the following error
{
"error": {
"message": "You have exceeded the allowed request limit. Please try again later."
}
}
If throttling errors persist, consider adopting the following strategies:
- Review Request Rate
- Analyze why you're sending a high volume of requests.
- Evaluate ways to lower the request rate for specific player or title entities targeted by the API.
- Batching API Calls
- Reduce frequency by batching API calls.
- Example: Batch stat updates every 10 seconds instead of updating every second.
Follow Best Practice
Customers are responsible to follow AccelByte’s best practice guidance to help prevent issues from occurring, minimize the impact of issues that do occur, and provide your players with a better user experience.