Throttling
Sitecore Content Hub backend services apply throttling to provide consistent performance across all services. When the backend is receiving too many requests, it returns responses with the Status code 429 (Too Many Requests).
Throttling is not a license-related limitation.
To optimize your queries to Content Hub:
- Make sure that a rate limit of 15 calls per second (per API integration user) is respected.
- Use the WebSDK, which has embedded throttling, over the REST API (for which you have to code the retry mechanism yourself).
- If required, modify the Content Hub WebSDK built-in retry policy. By default, any call returning an HTTP 429 response is retried nine times. You can modify the
RetryCountproperty of the retry policy as required. - Establish a retry after logic when you use the API. Group your requests into batches and take action when you receive an HTTP 429 response.
- Create dedicated API users for each integration to detect which one is overloading your platform or generating errors. If you have a sizeable integration (with multiple components), divide it into blocks and create a dedicated API user per block.
- When receiving a 429 response (Too Many Requests), use the
Retry-Afterheader to determine how long to wait before retrying. If the header is missing, implement a default wait time, for example 30 seconds, to avoid overwhelming the server with instant retries.
To ensure optimal performance, the following default timeout values define how long connections and requests can remain open. They apply to all REST APIs:
-
API keep-alive timeout - 60 seconds
-
API timeout - 140 seconds
These values define how long connections and individual requests can remain open before they are terminated. They do not represent throttling rate limits.
Dev tenant limitations
Content Hub Dev tenants run on shared, right-sized infrastructure to support development and testing use cases at a lower cost than QA and PRD tenants. Because Dev tenants share reduced resources, the following limitations apply to Dev tenants only. QA and PRD tenants are not subject to these limits.
| Limitation | Default value | Enforcement |
|---|---|---|
| Audit data retention | 2 weeks | Hard limit. Data older than the retention window is not queryable |
| Custom entities per tenant | 10,500 (excluding system-owned entities) | Hard limit. API returns HTTP 403 when reached |
| Taxonomy entities per tenant | 10,500 | Hard limit. API returns HTTP 403 when reached |
| API invocations | 100 per minute | Hard limit |
| Integration executions (scripts, triggers, and actions combined) | 300 per minute | Soft limit. Throttled, not blocked |
These limits reflect the reduced infrastructure capacity of Dev tenants and are not intended for production workloads. If your Dev workload legitimately requires a higher cap for a specific limit, contact your Sitecore account team to discuss options.
Recognizing the entity limit in API responses
When a Dev tenant reaches its entity cap, the Content Hub API returns an HTTP 403 response with an error message similar to:
This response indicates you have reached the entity cap for your Dev tenant. To resolve:
- Remove unused entities from the Dev tenant, or
- Contact your Sitecore account team if your development workload legitimately requires a higher cap.
Planning Dev tenant workloads
Because Dev tenants have a shorter audit retention window and stricter throughput limits than QA and PRD tenants, workloads developed against a Dev tenant should be re-tested against a QA tenant before promotion to production. Behavior that succeeds within Dev limits might exhibit different characteristics under QA or PRD throughput and retention configurations.