We have the Zoom Create a Meeting API built into an Internal Tool but it appears we are running into an issue.
We are populating the Alternative Host field in the configuration of the API with a list of users that have specific access to an Internal Site. It appears when a user is added with permissions to the site prior to being enabled for Zoom the API is failing to create a meeting. Same would happen for a user leaving the company and their account in Zoom is disabled prior to having their access removed from the Site in question.
I find it very surprising that the API would not just ignore the user that has not been licensed and proceed to create the meeting with the users on the list that have a Zoom License. Is this expected behaviour or a bug?
Thank you for reaching out to the Zoom Developer Forum. When adding a user as an alternative host, one of the prerequisites is that they are a licensed user on the same account as the host. We cover this in our Alternative Host documentation. It sounds like the behavior you’re encountering is expected. In the future, you’ll want to make sure that the user has been assigned a license before adding them as an alternative host.
We have been able to added error handling to this for ourselves which was relatively simple and easy to do. Do you know if this will be made a future enhancement of the API, checking that all alternative hosts are valid but not crashing the API if there not? It would be really beneficial to have this!
Thank you for the update. I tested this on my end and I saw the following error was returned:
{
"code": 1115,
"message": "basic-user@test.com is not a paid user."
}
It looks like the API handles this scenario well. Are you able to provide the endpoint and request body that you’re using when you see that no error is returned?
Yes, we get this error on our side as well however it completely stops the API and doesn’t run the create meting API.
We have error handling created that will loop through the co hosts and come back if any are not a paid user, but will still run with the remaining users and create the meeting. Is this something zoom might do in the future?
I don’t think this is something we have planned for the future as part of our REST API design is to have explicit error messages. If we allowed basic users to be ignored, this could be a source of confusion for people as to why they include specific users in the request but they don’t see them added as a host. Instead, we document the reason they can’t be added as part of the API response.
One thing you can do in order to avoid this is to make an API call to confirm a user is licensed prior to making the create meeting call. This can be done by checking the type field returned from the Get a User API
