Category: Infrastructure, API, Informational
Summary: The Platform API will begin returning strongly consistent 429 responses with Retry-After headers.
Context: Today 429 responses can be supplied by a few different layers inside the Genesys Cloud Platform which results in some inconsistencies for API consumers. In an effort to provide a better experience, all 429 response bodies will be normalized and contain retry-after headers.
Today, the 429 response body is partially consistent, but has room for improvement. For example, the "code" property can vary between areas of the API, "errors", "details", or "contextId" may be missing, and the retry-after header is only supplied in some scenarios.
Following this change, all 429 responses will resemble:
curl -I -X GET -H "Content-Type: application/json" -H "Authorization: bearer <token>" "https://api.mypurecloud.com/api/v2/<path>"
HTTP/1.1 429 Too Many Requests
ININ-Correlation-Id: <correlationId>
Retry-After: 42
Strict-Transport-Security: max-age=600; includeSubDomains
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: application/json
Content-Length: 208
{
"message": "Rate limit exceeded the maximum. Retry the request in [42] seconds",
"code": "too.many.requests.retry.after",
"status": 429,
"contextId": "<correlationId>",
"details": [],
"errors": []
}
Impact: To avoid any impact, ensure that 429s and the too.many.requests.retry.after error code (if inspecting the response body) are being handled by your application This is a common error code already documented on all resources. If any conditional handling is being applied by inspecting the "errors" or "details" properties, note these will no longer be furnished. Finally, confirm any HTTP client retry-after header handling (some clients ignore it by default, others don't). An application may appear to become latent if not handled appropriately.
Date of Change: November 10, 2021
Impacted APIs: All
References: API-5464