Hi, i have a small piece of python code which generates couple of intervals and sequentially sends them to the v2/analytics/users/details/jobs endpoint to process and download results. What happens though is that i recieve a 429 with a retry-after header which i observe and hold off sending any more requests until the elapsed time in the retry-after header.
What doesnt appear to be correct though is the recommended time in the retry-after header....even when the header states to delay by 2 seconds and i delay the request by 60 seconds, i still get a 429. Is there something specific about the jobs endpoint that i need to consider?
This doesnt seem right as logging from my side shows that i run the job one at a time. What would be nice is:
If the 429 contains bit more details in terms of what caused the 429 to happen
Have access to an API so we can check at a point in time, where we sit in terms of rate limits. If we have a number of integrations, and they are all contributing to the rate limit then it becomes difficult to determine how much throttling we need to do. The only info i have is the retry-after header but that does not seem to be an accurate representation as it does not factor all the variables in its calculations.
Only thing i can think of is that if i run a job (which includes posting the jobs, checking its status and then pulling the results) which all contribute to the rate limit, it takes some time for the limit to reset hence when i run another job, it adds to the rate limit even if the first job has finished. How long does it take for the rate limit to reset? I would have thought it is 60 seconds but even if i wait 60 seconds before executing my second job, i get the 429 almost instantly.
Hi @Anish
Is it possible that you're cacheing the 429 response, and the cached response is being returned after the 60 seconds instead of a fresh response? Also, are you waiting for each job to complete and be in the "FULFILLED" state before starting the next job?
There are some API resources for limits which you can find by searching "limits" in the API Explorer, but not sure if there is a resource for what you're describing.
Please continue to work with Care on the issue; we do not have access to your org's data and cannot troubleshoot this further here in a public setting.
As general guidance, be aware that 429 responses can be returned at any time due to documented and undocumented rate limits and to follow the rate limit best practices. There are some limits that pool all tokens for a user, all users in an org, or other groupings that are larger than you/your app. This can cause you to be rate limited seemingly unexpectedly, but only Care can investigate to explain the cause of the rate limit if it's not apparent from the error response.
This is specifically not possible currently, but Jacob is correct that the ideas portal is the correct place to submit your feature requests. The guidance from Genesys is that well-behaved apps will gracefully handle 429 responses and apply retry and backoff logic per the best practices linked above. This is due to the number of different limiters that exist across all of the different resources and the fact that there are undocumented limits that you will not be able to account for no matter how much effort you put into counting requests in your app; the only reliable approach is to handle 429s reactively.