Description
What URI, endpoint, and/or parameters can I use to return all users on the account, excluding admin users?
Error
The full error message or issue you are running into.
When attempting to pull a list of all members in a given role, the number of total_records returned is less than expected.
Which App Type (OAuth / Chatbot / JWT / Webhook)?
Knowing the endpoint/s can help us to identify your issue faster. Please link the ones you need help/have a question with.
JWT
Which Endpoint/s?
Knowing the API endpoint/s can help us to identify your issue faster. Please link the ones you need help/have a question with.
How To Reproduce (If applicable)
Steps to reproduce the behavior:
Use code to pass the Bearer Token in a secure manor. I do not believe this section to be relevant to the issue with the number of returned records. If there was a problem with the code for passing the token, then the calls wouldn’t reach the endpoint at all.
Screenshots (If applicable)
If applicable, add screenshots to help explain your problem.
Screenshot attached detailing the results of the call made by my code.
Additional context
Add any other context about the problem here.
My goal is to send a call that will pull a list of all users in this members/roleID 2 role. If possible, I’m also wanting to limit the returned records to only list the licensed users, those with user type:2.
My understanding of the page_size parameter is that this call should return 1 page with 300 total_records. Currently, the call only returns 1 page with 128 total_records. I know the account in question has over 1,400 user accounts in the members/roleID 2 category.
Aside from the above concern regarding the number of total_records returned, I also have questions about how to send the call so that it returns as many pages as necessary to list all users on the account. I’ve been reading through the information at “https://marketplace.zoom.us/docs/api-reference/pagination” but am not seeing an example of how to craft a call to utilize either the next_page_token or the page_number parameter to pull all records.
The reason I suggest this is because when you are getting users based on a role, there could be other licensed users who are apart of a different role.
I adjusted the call to use the users API instead of the roles API, “https://api.zoom.us/v2/users”. This is still only returning 130 records, fed over 5 pages.
When adding parameters to the call “https://api.zoom.us/v2/users?role_id=2&page_size=300” this still returns only 129 records, now all in one page. This also does not count the owner user account in the returned results, which is what I would prefer.
Apologies for not originally indicating that I was only interested in returning the licensed users under the members role. The specific account in question is one that is setup for an integration with Zoom and the Epic Healthcare app from the App Marketplace. Unless something is going wrong, this account should only ever have the account owner, and then various user accounts under the members role. There shouldn’t be any other licensed users in any other roles.
My goal is to pull a list of all licensed users under this account (not counting the owner user), then use other code later on in the script to send calls to flush/clear the licensed users type from 2 to 1. Unfortunately, Epic isn’t making the needed call to do this cleanup on their end, and the Zoom reps we worked with when initially configuring the integration claimed that we would have to create a custom script to facilitate the cleanup we are looking to achieve. Without this cleanup, eventually our account would hit it’s licensed user limit and the Epic integration would stop functioning.
If the call you recommended would return all records, then I would agree that filtering by type or role would then be a good option, but currently this call to the users endpoint seems to yield the same results as my call to the roles endpoint. I’m only seeing a fraction of the records which I am expecting. I feel that I may be misunderstanding how the calls are intended to work, but my current understanding is that the call should return multiple pages with multiple records on each page, since the account in question has over 1,000 users.
The call going out is:
Invoke-WebRequest -Uri $URI -Method Get -Headers @{“Authorization” = “Bearer $token”}
Thanks sir! I would appreciate any information you are able to find.
Given the current issue with only receiving part of the user account list, then the only workaround that I can think of would be to adjust the script to outright delete the user accounts, instead of simply changing their licensing type. Deleting the user accounts would allow for looping through the call, in batches of 129, until no results were returned by the call… I would prefer to avoid outright deleting the user accounts if possible, as this is a much more extreme change than adjusting their licensing type.
Eventually, once the calls work as expected, our plan is to run this licensing type cleanup script on a nightly cadence. We would then also run a delete version of the script on an monthly/quarterly basis during planned downtime’s, to keep up with cleaning any old/stale provider/licensed user accounts.
After further review, I found the problem wasn’t with the records being returned by the call. I was misinformed, and there actually where only 129 user accounts.
After ensuring there are now actually 1,400 user accounts in the system, the call returns the expected number of records.
Now I’m running into a different problem. I’m not sure how to paginate through the resulting records. Currently I’m using
After further review, it seems as if the users and roles endpoints may not yet be setup to use the next_page_token parameter.
I was able to add some logic to my script, to fill a variable for the page_number parameter, then loop through the call to pull records from additional pages, until the value returned for the current page_number matched the value for page_count.
I’m now able to obtain the desired list of users in the members role. I believe this topic can be closed, unless there’s anything more that can be added that I’m not aware of.
Thanks for updating the post and letting us know! Our team is still double checking the total_records field to be safe (ZOOM-194691), though initial findings match up with your findings as well (that it is in fact accurate).
As for the next_page_token field, we’re in the process of rolling this out across batch APIs, so stay tuned!
Don’t hesitate to let me know if you have any other questions.
