cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
559
Views
0
Helpful
1
Replies

Webex REST API getting org-level user status

RyanBoldy
Level 1
Level 1

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.

1 Accepted Solution

Jeff Marshall
Cisco Employee
Cisco Employee

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.

View solution in original post

1 Reply 1

Jeff Marshall
Cisco Employee
Cisco Employee

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.