Description
If I create a user through the API using the custCreate action. Then create a meeting under that user. Can you pass the start_url from that meeting just created to another user and let them host the meeting?
What if I create a second meeting with that custCreate user. Can you pass the start_url from the 2nd meeting to a third user and let them host it at the same time?
Can both meetings be running at the same time? (even though the meetings were created by the same custCreate user) (as long as the meetings are hosted by different people) Error
The full error message or issue you are running into.
Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT
Which Endpoint/s?
/users and /users/{userId}/meetings
How To Reproduce (If applicable)
Steps to reproduce the behavior:
Create user using /user endpoint. action: “custCreate”
Create meeting ONE using /users/:userId/meetings endpoint.
Create meeting TWO using /users/:userId/meetings endpoint.
Pass start_url from meeting ONE to an existing user - Person X. Have them start the meeting.
Pass start_url from meeting TWO to an existing user - Person Y. Have them start the meeting.
Is this allowable under licensing? Must Person X and Person Y exist as licenses under the corporate account that created the user in step 1? Will starting meeting TWO cause meeting ONE to end (since both meetings were created via the API under the same user from step 1)
Additional context
I’ve tried this out and it appears to work if both person X and Y are already licenses under the same account. But I’m wondering if we should not rely on this functionality and that it might change in the future.
Sorry, but What is the licensed user role in hosting meetings? does not really answer my question about a single custCreate user hosting multiple meetings at the same time by passing the start_url to different actual users.
Thanks for reaching out about this. To clarify, the start_url for a given meeting is intended for the host who was assigned to the meeting when it was created/scheduled.
If you wish to have another user under the same account be able to start the meeting, the recommended flow is to use the alternative_host field and specify any additional hosts that should have the ability to start the meeting in question.
If a user is added as an alternative host for a meeting, they will be able to start it by using the join_url.
We actually have a different use-case. We’d like to create meetings for our end users who are not part of our organization. Because of that, we can’t use the alternative_host functionality. I tried that earlier, and it requires the alternate to be created as a user under our account.
This is more like Facebook wanting to leverage Zoom to provide their end-users the ability to schedule and run meetings. They obviously wouldn’t want to add every user of their app to be a user within the Facebook account. So, I was trying to see if we could have several “generic” users within our organization schedule the meetings and just pass out the start_url to the end-user. (I realize Facebook already has their own way to have face-to-face meetings)
I see—thanks for clarifying! At the moment, I don’t believe your use case is supported under our JWT authentication type. If you’re using a JWT app for authenticating your requests, you can use the scheduled_for and alternative_host fields to accomplish this idea of creating meetings for users who are part of your organization, like you suspected.
However, if you wanted to create meetings on behalf of users who are from a different account, you would need to authenticate via OAuth and publish an app publicly on our Marketplace in order to get access to assign these users as hosts (if they’re outside of your account).
I hope this helps to clarify, but let me know if you have questions about this.
