Genesys is pleased to announce a much needed operational enhancement to rate limit visibility. In order to improve self-service and triage capabilities, the HTTP 429 error response body will now additionally include limit details. Example:
Note: the limit object is not guaranteed to be included in 429 responses and is discretionary based on the specific limit and area of the API. As internal rollout of this feature continues, additional API limits will begin to appear. If limit details are not included, please reach out to Care for additional triage support.
This is a nice feature to open up the rate limiting black box. Do you have a what developers should do now that we have that information? One I can see is that if I know a smaller rate limit that I'm hitting, I might be able to weave those request in with other requests that go against a different rate limiter
@TheRealKevinGlinski I don't think the general guidance has changed: if you get rate limited, follow the retry-after header if it exists and follow exponential backoff if not. The main purpose is simply to open up the black box so the app can log information about why it got rate limited without you opening a case with Care. This will shorten development cycles since you don't have to wait on an investigation; the answer is in the API payload immediately.
This additional information will potentially allow you to squeeze a little more throughput out of your apps by being intelligent about which limiter was hit, but you have to plan ahead and code for specific limits that you might hit from specific endpoints.
For example, if you hit the main API limiter of 300 RPM that means a full stop for the app since that limit applies to all requests. But if you hit a known analytics-specific rate limit, your app could still allow API requests to be made to endpoints it knows are not impacted by that limiter, like looking up a user.
I know you personally know this part but just a word to the wise for other readers, if you do fine-tune your rate limit behavior be sure to test it well so it doesn't become abusive by continuing to make rate limited requests when it should be waiting. Repeated spikes or continually retrying 429 responses can trigger alarms that could result in your OAuth client being disabled. Care will attempt to contact the org's owner if this happens to discuss remediation before taking any action, but action may be taken first if it's impacting platform stability.