How to correctly support use case of multiple simultaneous meetings created via API?

API and Webhooks
1

Description
For context: I work on a mobile app for a dating app startup that is working on productizing a virtual date event series.

To do this, we are running various processes to pair up users in our mobile app, and then we want to send them to Zoom to have their virtual date. (At some future point, we would like to also use the Zoom native SDK in our app, but for now we’re just using the API and redirecting users to the Zoom app). We’re currently on a Zoom Pro (Named Host) account type.

The idea is there would be multiple of these virtual dates happening at the same time, neither of these users would be a member of “our” organization (that is they’re not part of our Zoom account, they’re just users of our app), and we only want the 2 users in the meeting, not anyone from “our” organization (i.e. no host present). Ideally, we would also want our users to not have to have / login to a Zoom account, and be able to join the meeting in Zoom right away.

How we thought we would do this is:

  1. use the /users/me/meetings endpoint (via JWT / Account Level App) to create a new meeting with a unique meeting URL on our backend, with settings.join_before_host set to true, and settings.waiting_room set to false.
  2. Receive the join_url from the Zoom API and redirect both users from our app to Zoom via deep link. Either the user has Zoom installed and it will open the meeting right away for them in Zoom or it will go to the browser which will tell them they need to download Zoom and then come back and press the button to join the meeting.

Error
The problem we seem to be running into now is that as soon as one meeting that was created using the above endpoint is active (which seems to mean at least one person is in the meeting), additional meetings created by it will yield a “This host is already running another meeting” message when trying to enter them.

Therefore, how should we then best support this use case? Do we need to create a bunch of additional Zoom users and instead of putting me into the endpoint, pass their userId so that it creates meetings with “different” hosts? Or do we need a different account type? Or is there another way to do this so that we can have multiple simultaneous meetings running?

2

Since you can only host one meeting at a time with a single user, this sounds like the best approach would be similar to what Telehealth or other service providers have to do - use the Create User API with the “custCreate” type. This is only accessible by going through the ISV Partner Program though: https://sites.google.com/zoom.us/isv/partners

You can find out more/direct information by contacting the ISV team: isv@zoom.us

Otherwise, you would need to create normal users (free/basic, if the 40 mins meets your requirements) in your account on-demand or create a pool of them ahead of time and use them to host meetings.

1 Like
3

Thanks @samiy, appreciate the quick response.

Our “virtual dates” are generally for 7 minutes, so the 40 minute limit should not be an issue. However, if I want to create these free/basic users “on-demand”, do I use the create value for action in POST /users? Using create makes it seem like I have to manually activate each one then? Or can I then use their userId as the host for a new meeting without activating them?

4

Yes, POST to /users with action: create in the JSON body.

You should then be able to use their ID to create new meetings. You might not need to activate them… would suggest just trying it :man_shrugging:. I’ve had success with creating on-demand accounts like this but my organization uses SSO, so not sure if other stipulations applied with activation.

2 Likes
5

Update for anyone interested: you either have to be on a Pro plan with > 10 paid hosts to enable ssoCreate, or on a Business Plan to autoCreate, so if you’re on a Pro plan with less than 10 paid hosts like my team, your only option is to use action: create, but this requires that the accounts get manually activated. Therefore, you have to “stockpile” accounts ahead of time for my use case.

6

Hey @ilya,

You could also use OAuth to allow users to use their own Zoom accounts so you don’t have to do any account management.

Appreciate your suggestions @samly!

Thanks,
Tommy