Rate limiting
Platform API rate limits by endpoint and how to handle rate limit responses with retry and backoff.
The Platform API enforces rate limits at the account and route level. Different endpoints have different limits.
| Endpoint | Description | Rate limit |
|---|---|---|
/platform/v2/process/{siteIdentifier} | Process endpoint | 1 request per site per 5 minutes |
/product/v2/site/{siteIdentifier}/stage/{stageName}/{stageId} | Product data read endpoint | 60 requests per minute |
/* | All other endpoints (limit applies per endpoint individually) | 5 requests per second |
Implement a retry and exponential backoff mechanism to handle rate limit responses correctly. See retry and backoff.
Rate limit HTTP headers
Every response from the Platform API includes rate limit headers:
HTTP/2 200
X-RateLimit-Limit: 5
X-Ratelimit-Remaining: 1
X-Ratelimit-Retry-After: 1651174223| Name | Description |
|---|---|
X-RateLimit-Limit | Maximum number of requests allowed per second |
X-Ratelimit-Remaining | Requests remaining in the current rate-limiting window |
X-Ratelimit-Retry-After | Unix timestamp when the current rate-limiting window resets |
When you exceed the rate limit, the API returns a 429 response:
HTTP/2 429
X-RateLimit-Limit: 5
X-Ratelimit-Remaining: 1
X-Ratelimit-Retry-After: 1651174223
{"success":false,"message":"Too many attempts."}Retry and backoff
Implement retries for the following response status codes:
5xxServer errors249Custom error408Request timeout429Too many requests — use the response headers to determine when to retry
Implementation guidelines
- Implement at least five retry attempts per failed request.
- Use an exponential backoff mechanism between retries.
Exponential backoff reduces load on the platform during error periods, increases the likelihood of successful retries, and outperforms fixed-delay mechanisms during error surges.
For a PHP reference implementation, see the exponentialDelay() method in the Guzzle RetryMiddleware class.
How is this guide?