Rate limits

Overview

📘

Heads up

We will be introducing rate limits with 18.44 release which is scheduled to 3rd of June 2025. You should review this document to ensure that you will not be affected by them.

Rate limits are essential safeguards that ensure fair and stable API access for all clients. By implementing these limits, we help to prevent service disruptions caused by excessive requests and ensure consistent performance across our platform. This approach helps protect our infrastructure and your experience with the API.

Request classification

These limits apply per IP address, with separate rate limit pools for each API endpoint path group. An endpoint path group is determined by the API prefix, for example:

• /api/apps/*
• /api/analytics/*
• /api/cdp/*

Exceeding the limit for /api/analytics/* endpoints won't affect your rate limit quota for /api/apps/*. Each endpoint group maintains its own limits. This granular approach allows for more flexible API usage while still protecting individual endpoints from overload.

The rate limiting implementation uses a leaky bucket algorithm. It means the request quota is gradually replenished throughout the rate limit time window, rather than resetting all at once. For instance, if your limit is 600 requests per minute for GET operations, you'll receive approximately 10 new requests per second, rather than all 600 being refreshed at the start of each minute.

Current limits are defined as follows:

GET (Read) requests - 600 requests per minute

• Retrieving data (e.g., fetching user lists, getting app details)
• Uses HTTP GET verb exclusively

Non-GET (Write) requests - 60 requests per minute

• POST: Creating new records
• PUT/PATCH: Updating existing records
• DELETE: Removing records
• Complex queries using POST method (even if they only retrieve data)

Note: Classification is strictly based on the HTTP verb used, not on the purpose of the operation. That's why POST requests used for complex queries count against the non-GET limit, even if they're only retrieving data.

Rate limit response

When you exceed the rate limit, the API will respond with:

• HTTP Status Code: 429 Too Many Requests
• Response Header: X-Retry-After: <seconds>

The X-Retry-After header indicates the number of seconds to wait before making another request.

Best practices for rate limit management

1. Optimize request patterns

   • Avoid unnecessary polling
   • Implement efficient data fetching strategies

2. Implement caching

   • Store frequently accessed data locally
   • Reduce repetitive API calls

3. Handle rate limits gracefully

   • Implement exponential backoff for retries
   • Respect the X-Retry-After header values