Description
If a user is created on our corporate account using the API with the “custCreate” action on the /users endpoint, Zoom gets confused as to which user the meeting belongs to.
Error
You cannot start the meeting xxxxxxxxx* because it is hosted by another user
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT
Which Endpoint/s?
/users
How To Reproduce (If applicable)
Steps to reproduce the behavior:
Create new Zoom user outside of the API or the corporate account (simulating someone who already has a personal Zoom account). xxx.yyyy@gmail.com
Log into Zoom with this basic user. No issues, everything is fine. Works like any basic user.
Use API to create user using /user endpoint with action: “custCreate” and same email in the user_info section xxx.yyyy@gmail.com. That new user is now associated with our corporate account.
Use API to create meeting with the user UUID (or email address, doesn’t matter) from step 3.
Obtain start_url from response in step 4.
Try to start meeting while logged in as user in step 1.
Result:
Message indicating meeting is hosted by another user.
Additional context
If this is the expected behavior, then it is imperative that any new user created using custCreate under our corporate account can NOT have the exact same email as a possibly existing Zoom user.
We are trying to create meetings for our users regardless of whether they have Zoom accounts but do not want to affect any user that might have an existing personal Zoom account.
From the behavior above, it appears the email address string is unique across all Zoom users and corporate accounts. Need verification.
Can I ask how you are starting the meeting with the custCreate user? The custCreate API user cannot log in to zoom client, so they should start the meeting with the start_url.
I’m not starting the meeting as the custCreate user. I’m logging in with a “normal” user that I had created over a year ago. Then, I’ve obtained the start_url from step 4 and launched there. So, a different user created the meeting.
Except, in our case, its really the same physical person. We generated a custCreate user because we did not know their true Zoom user/password and that user was not part of our account anyway.
How we’ve gotten around the problem is by generating a unique user email in step 3. The physical user is never aware of this generated zoom user.
If the user logs in with their original zoom user id, they will not see any meetings we’ve created for them, but that’s a compromise we decided to live with.