Rate Limiting

Gameball API employs safeguards to protect against sudden bursts of traffic, ensuring platform stability. If you send too many requests in a short time, you may encounter error responses with status code 429 (Too Many Requests).

Rate Limits: Gameball uses two levels of rate limiting:

• Per-second limit: A maximum of 100 read operations and 30 write operations can be processed per second. This is the limit for concurrent requests handled at any given moment.

• Per-minute bucket: Over the course of one minute, the API allows up to 4800 read operations and 1440 write operations in total. This acts as an overall cap to ensure the system remains stable during sustained activity.

If the rate exceeds either the per-second or per-minute limit, a 429 Too Many Requests error will be returned.

To handle bulk operations and avoid hitting API rate limits, batch APIs will be released by the end of Q4 2024, allowing you to process multiple requests more efficiently.

Common Causes and Mitigations:

Rate limiting can occur for several reasons, with the most common scenarios being:

• High request volume in quick succession: Sending many closely-timed requests, such as during large data analysis or migration, can lead to rate limiting. To avoid this, control the request rate from your side (see Handling Rate Limiting Gracefully).

• Resource-intensive requests: Some requests, like retrieving large datasets or those requiring data expansions, use more resources and take longer to process. Such requests can trigger rate limiting due to higher resource demands. Profiling the duration of your Gameball API requests can help identify and mitigate slow requests.

• Sudden spikes in traffic (e.g., flash sales): A sudden influx of requests, like during a flash sale, can cause rate limiting. While the API limits are designed to accommodate typical traffic, you may want to prepare in advance for events expected to generate a surge in requests.