Overview

📘
Heads up
We introduced rate limits on 4 June 2025. Please review this document to ensure your integration isn’t affected.

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 for a client instance, 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

Optimize request patterns
- Avoid unnecessary polling
- Implement efficient data fetching strategies
Implement caching
- Store frequently accessed data locally
- Reduce repetitive API calls
Handle rate limits gracefully
- Implement exponential backoff for retries
- Respect the X-Retry-After header values

FAQ

Tracking endpoints and rate limits

Tracking endpoints are not rate limited. They are the core of our analytics platform and designed to handle high volumes of traffic. These endpoints are used for sending all tracking data such as pageviews, events and so on.