Quick Reference for AI Agents & DevelopersRate Limits:
- Core Operations: 10,000 requests/minute (login, create/delete user, create/join group)
- Standard Operations: 20,000 requests/minute (all other operations)
- Status Code: 429 (Too Many Requests)
- Headers:
Retry-After,X-Rate-Limit-Reset,X-Rate-Limit,X-Rate-Limit-Remaining
X-Rate-Limit-Remaining header and implement exponential backoff when approaching limits.CometChat REST API Rate Limits
The rate limits below are for general applications. Rate limits can be adjusted on a per-need basis, depending on your use case and plan. The rate limits are cumulative. For example, if the rate limit for core operations is 100 requests per minute, then you can login a user, add a user to a group, remove a user from a group, etc., for a total of 100 requests per minute.
- Core Operations: Core operations are rate limited to
10,000requests per minute. Core operations include user login, create/delete user, and create/join group cumulatively. - Standard Operations: Standard operations are rate limited to
20,000requests per minute. Standard operations include all other operations cumulatively.
What Happens When the Rate Limit Is Reached?
The request isn’t processed and a response is sent containing a 429 response code. Along with the response code, a couple of headers are sent that specify the time in seconds you must wait before you can try the request again.Retry-After: 15
X-Rate-Limit-Reset: 1625143246
Is There an Endpoint That Returns Rate Limits for All Resources?
No, we don’t provide a rate-limit endpoint. However, we do provide the following response headers that you can use to confirm the app’s current rate limit and monitor the number of requests remaining in the current minute:X-Rate-Limit: 700
X-Rate-Limit-Remaining: 699
Best Practices
Monitor Rate Limit Headers
Monitor Rate Limit Headers
Always check the
X-Rate-Limit-Remaining header in API responses to track how many requests you have left in the current minute. Implement logic to slow down requests when approaching the limit.Implement Exponential Backoff
Implement Exponential Backoff
When you receive a 429 response, implement exponential backoff retry logic. Use the
Retry-After header value to determine when to retry the request.Batch Operations When Possible
Batch Operations When Possible
Group multiple operations into batch requests where the API supports it. This reduces the total number of API calls and helps stay within rate limits.
Cache Data Locally
Cache Data Locally
Cache user lists, group information, and other frequently accessed data locally to reduce the number of API calls. Only fetch fresh data when necessary.
Request Limit Increase for Production
Request Limit Increase for Production
If your application consistently hits rate limits, contact CometChat support to discuss increasing limits based on your use case and plan. Rate limits can be adjusted per-need basis.
Troubleshooting
Frequent 429 Errors
Frequent 429 Errors
Symptom: Application frequently receives 429 (Too Many Requests) responses.Cause: Your application is making too many API requests within the rate limit window (1 minute).Solution: Implement request throttling on the client side. Monitor
X-Rate-Limit-Remaining header and slow down requests when approaching the limit. Consider caching data locally to reduce API calls. If legitimate high volume, contact support for limit increase.Rate Limit Reset Time Confusion
Rate Limit Reset Time Confusion
Symptom: Unclear when rate limit will reset after hitting the limit.Cause: Misunderstanding the
X-Rate-Limit-Reset header format.Solution: The X-Rate-Limit-Reset header contains a Unix timestamp (seconds since epoch). Convert it to a readable date/time in your timezone. The Retry-After header provides seconds to wait, which is often simpler to use.Unexpected Rate Limit Hits
Unexpected Rate Limit Hits
Symptom: Rate limits are hit even though the app doesn’t seem to be making many requests.Cause: Multiple instances of your app (different users, devices, or servers) share the same rate limit pool. Background sync or polling may be consuming quota.Solution: Rate limits are per app, not per user or device. Audit all API calls including background operations. Implement efficient polling strategies (use WebSocket for real-time updates instead of polling). Consider request prioritization to ensure critical operations succeed.