Request rate limits

Request flow limiting is used to control abnormal traffic and protect quotas and service stability. Geelab decentralizes traffic control to the endpoint, allowing you to set rules for different platforms and business entrances.

endpoint minute/hour rate limits

The endpoint rate limits is set for a single Web, iOS or Android endpoint and usually includes:

• Maximum number of requests per minute.
• Maximum number of requests per hour.

When setting, a margin should be reserved based on normal peak values. The per-minute limit multiplied by 60 should not be higher than the hourly limit.

For example, if the normal peak value is 100 times per minute, you can first set a higher test threshold based on business fluctuations, and then gradually adjust it through monitoring data, instead of directly using a too low limit.

Organization status and endpoints rate limiting

endpoint rate limiting only affects the current endpoint. When the organization is deactivated, the package expires, or the total quota is exhausted, multiple applications and endpoints in the organization may be affected at the same time.

Performance after exceeding the limit

When the request exceeds the access limit:

• Geelab rejects requests that exceed the limit.
• The client may receive error codes related to rate limiting.
• Limits usually resume automatically after passing the normal time window.
• Application and access configurations are not automatically changed.

rate limiting is not a permanent ban. Please confirm whether the business is at an abnormal peak before deciding whether to adjust the threshold.

Illustration: endpoint rate-limit configuration

rate limiting troubleshooting

If the request has been rejected, please continue to check whether the request is flow-limited or the quota is exhausted, and distinguish between access-end flow-limiting and organizational quota issues.

If the request is throttled:

1. Record the time the error occurred and the Request ID (if generated).
2. Confirm whether only one endpoint is affected, or whether multiple endpoints are affected at the same time due to organizational status or package quota.
3. Check the endpoint usage per minute and hour.
4. View the organization's package quota and current usage.
5. Check if there are any abnormal retries, loop calls or batch tasks.
6. Wait for the next time window to confirm whether automatic recovery occurs.
7. Adjust the threshold based on long-term traffic and retain abnormal traffic protection.

Don't permanently turn off all throttling just to pass one test. For applications whose Public API Key is exposed to the client, maintain at least a reasonable layer of traffic protection.