To ensure reliable performance and availability for all customers, the Secure Privacy API enforces rate limits on requests that reach our origin servers. These limits apply universally across all pricing tiers on a per-domain, per-mobile app, and per-TV app basis.
Most common requests are cached and not rate-limited. Web banners, mobile banners, TV banners, and preference center endpoints are all served from cache for returning users. Only uncached requests that go directly to our origin servers count toward rate limits. For the majority of your traffic, rate limits will not apply.
We apply caching wherever possible to reduce the load on our origin servers and provide the fastest speeds for our customers. API integrations that do not use the Secure Privacy script or SDKs (e.g. direct API calls) are not cached and will count toward rate limits.
| Time Window | Limit | Description |
|---|---|---|
| Per Second | 20 requests/sec | Maximum requests per second per domain/app |
| Per Minute | 600 requests/min | Maximum requests per minute per domain/app |
When a new user visits your website or opens your mobile/TV app for the first time, their initial consent request bypasses the cache and goes directly to our origin servers. This is necessary to fetch and store their consent preferences. These requests do count toward your rate limits.
After this first request, the data is cached and subsequent requests for that user will not count toward your limits. Keep this in mind when planning high-traffic events like push notification campaigns, where many new users may arrive simultaneously.
Why this matters
Returning users are served from the cache and don’t count toward these stricter limits. However, if you send a push notification to a large audience and many new users click through or open your app simultaneously, all of their first-hit requests go directly to our servers. This is the most common cause of rate limit issues.
For web banners, the cache is keyed by three parameters:
en, de, fr)US, GB, DE)This means requests with different language/location combinations are cached separately.
When you exceed a rate limit, the API returns a 429 Too Many Requests response with the following headers:
| Header | Description |
|---|---|
Retry-After | Number of seconds to wait before retrying |
Example Response:
HTTP/1.1 429 Too Many RequestsRetry-After: 60Content-Type: application/json{ "error": { "code": "RATE_LIMIT_EXCEEDED", "message": "Rate limit exceeded. Please retry after 60 seconds.", "retryAfter": 60 }}For customers with legitimate high-traffic requirements, we offer rate limit increases on a case-by-case basis.
To request a rate limit increase:
Enterprise customers may also inquire about dedicated endpoints with custom rate limits.
Planning a high-traffic event?
See the High-Traffic Best Practices guide for detailed preparation steps, including cache pre-warming, notification staggering, and code examples for handling rate limits gracefully.
Q: Do rate limits apply to cached requests?
No. Requests served from cache do not count against your rate limits. Only requests that reach our origin servers are rate-limited.
Q: Are rate limits per domain/app or per account?
Rate limits apply per domain, mobile app, and TV app. If you have multiple domains or apps configured, each has its own separate rate limit allowance.
Q: What happens if I consistently exceed rate limits?
Persistent rate limit violations may result in temporary suspension of API access. Please contact support at [email protected] if you need higher limits.
Q: Do mobile SDK requests count against the same limits?
No, each mobile app and TV app has its own separate rate limit counter. Web domains, mobile apps, and TV apps are rate-limited independently.
Q: Why are the per-minute limits not 60x the per-second limits?
The per-second limit (20/sec) prevents instantaneous spikes, while the per-minute limit (600/min) prevents sustained high throughput. This combination ensures your average stays around ~10 requests/sec over a minute.