Rate limiting
Last updated
Last updated
The Didomi platform limits the number of requests sent to the API () when authenticated via API keys.
Requests from Didomi SDKs are not subject to rate limiting and the limits documented in this section do not apply to the Didomi SDKs (CMP and PMP SDKs on all platforms -Web, Mobile, CTV, AMP-).
Rate limiting is used to protect the platform and to ensure the availability and performance of the Didomi API for all customers.
This page presents the current rate limits that are enforced by the Didomi API.
Those limits are subject to change at any time without prior communication to ensure the availability and performance of the Didomi API.
Rate limiting is not a commitment to honor any number of requests under any specific response time constraints and is not a service level agreement.
Rate limits are defined globally and cannot be adjusted for specific organizations.
The following limits are currently enforced:
/consents/*
No limit
All other routes
100 requests every 15 seconds per organization
Didomi does not enforce any rate limit for routes under the path /consents/* and will not actively throttle API requests sent to those routes.
This is not a commitment to honor an unlimited number of requests or to enforce a specific response time. Please refer to our Service Level Agreement for more information if you need specific availability and response time commitments.
For all routes other than /consents/*, the following rate limit is enforced: 100 requests every 15 seconds per organization.
Rate limiting is applied at the organization level. If an organization uses multiple API keys to send HTTP requests to the Didomi API, all API keys are subject to the same shared rate limit.
Examples:
50 requests to GET /widgets/notices and 5 requests to GET /widgets/notices/configs in a 15-second period
No throttling
200 requests to GET /widgets/notices in a 15-second period
Throttling after the first 100 requests in the time window
100 requests to GET /widgets/notices and 200 requests to POST /widgets/notices in a 15-second period
Throttling after the first 100 requests in the time window
The following elements are added to HTTP responses from the Didomi API to help you manage rate limiting.
Rate limit header fields convey hints from the server to the clients in order to help them avoid being throttled out.
Clients MUST NOT consider the units returned in headers as a service level agreement.
In case of resource saturation, the server MAY artificially lower the returned values or not serve the request regardless of the advertised quotas.
When a request cannot be processed because an organization has exceeded its allocated limit, the HTTP response will be sent with the status code 429.
This is an indication that the organization requests are being throttled and should be retried at a later time.
Example: Retry-After: 15 indicates that the organization is throttled for 15 seconds and no request to the same route will be accepted for the next 15 seconds.
The following headers are added to HTTP responses:
RateLimit
Format: limit={limit}, remaining={remaining}, reset={reset}
This header provides the following information:
- limit: Maximum number of requests allowed for the route and the organization in the current time window.
- remaining: Remaining number of requests in the current time window.
- reset: Number of seconds until the remaining number of requests resets.
RateLimit: limit=100, remaining=60, reset=7
Indicates that the organization can send a total of 100 requests in the current time window, has 60 requests left in the current time window, and that the number of remaining requests will be set back to 100 in 7 seconds.
RateLimit-Policy
Format: {limit};w={window}
This header provides the following information:
- limit: Maximum number of requests allowed for the route and the organization in the current time window.
- window: Time interval in seconds on which the limit is applied.
RateLimit-Policy: 100;w=15
Indicates that the organization can send a total of 100 requests in every window of 15 seconds.
When a response is sent with the status code 429, a header will be added to the HTTP response with the number of seconds that the organization should wait before sending more HTTP requests to the same route.
All routes that are subject to rate limiting will return headers respecting the , even when the request and organization are not being actively throttled.