- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Labels:
-
Webex API

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
