09-01-2023 06:29 AM
I am making a tool to do some analysis on the user statuses of my organization. Problem is, I need this data very frequently for this analysis to be worth our time.
The posted API limit for /people is ~300 requests per minute, but in my testing there is no acceptable polling-rate to avoid 429 responses with lengthy retry-after periods. In my testing, I polled once every second, 3 seconds, 5 seconds, 10 seconds, all of which got these 429 codes. Anything higher than this and the status analysis becomes worthless.
I have tried bot accounts, but I have yet to find a way to give them admin access within an org, and thus I cannot use the parameter-less request to /people to get all users. I also cannot use the id array parameter request method, because status information is vital to this analysis.
I have noticed, that making a request after a 429 is usually successful, far sooner than the retry after period anyways. Am I supposed to just ignore this period? This seems disrespectful to the API, but I can't find another way. Help would be much appreciated.
Cheers.
Solved! Go to Solution.
09-01-2023 10:15 AM - edited 09-01-2023 10:16 AM
The backend service that is polled to retrieve a user's status is essentially already running at its limit. When that service is over loaded it sends back a 429 but the API gateway has to add the retry-after header which in this case is randomly generated rather than actually returned by the status service. There is a plan to rework it at some point in the future but unfortunately there is no timeline for when that may happen. Feel free to just retry ignoring the value in the retry-after header in this case.
As far as using a bot, there is no way to give a bot admin privileges.
09-01-2023 10:15 AM - edited 09-01-2023 10:16 AM
The backend service that is polled to retrieve a user's status is essentially already running at its limit. When that service is over loaded it sends back a 429 but the API gateway has to add the retry-after header which in this case is randomly generated rather than actually returned by the status service. There is a plan to rework it at some point in the future but unfortunately there is no timeline for when that may happen. Feel free to just retry ignoring the value in the retry-after header in this case.
As far as using a bot, there is no way to give a bot admin privileges.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide