Recommended pattern for API-only host users: per-instructor users vs. a shared pool of hosts?

API and Webhooks
1

Hi all — I’m after architectural guidance, not a fix for a specific error.

We run a class-booking platform. Instructors deliver scheduled live classes. One Zoom org account, all access via Server-to-Server OAuth. We create meetings with POST /users/{userId}/meetings, the instructor joins as host from our mobile app via the Meeting SDK using a ZAK, attendance comes from meeting.participant_joined/left webhooks, and recordings from GET /meetings/{meetingId}/recordings. Concurrent classes are far fewer than the number of instructors. Instructors are not Zoom customers — they’re users of our platform, and we don’t want their personal Zoom accounts involved at all.

Approach A — one Zoom user per instructor, with licenses rotated between them around class times via PATCH /users/{userId} (type 1 ↔ 2). We wanted these hosts on application-owned addresses on our own domain (e.g. zoom+<id>@ourdomain.com) rather than instructors’ personal emails, because personal emails cause 1005 when the instructor already has a Zoom account, and consolidation means license rotation then affects that person’s own meetings. Plus-addressed emails are accepted, but we can’t create a host that’s usable without email activation, since these aren’t real mailboxes:

  • action: "custCreate" → 400 / 2016 No permission, please contact Zoom customer support.
  • action: "autoCreate" → 400 / 1116 Domain name doesn't match... set managed domains for your account.
  • action: "create" → user created but stays status: pending, after which both POST /users/{email}/meetings and GET /users/{email}/token?type=zak return 404 / 1001 User does not exist.

Approach B — a small pool of shared host users (host01@ourdomain.com, host02@…) sized to peak concurrency, allocating a free one per class. Instructors never become Zoom users; no API provisioning, no license rotation. This needs no special account privileges, which is partly why I’m asking — it works today, while A is blocked.

Questions:

  1. Which of these is the intended pattern for hosting meetings on behalf of people who aren’t Zoom users? Is a shared pool of hosts a supported design, or does the platform expect per-user provisioning?
  2. Is custCreate the sanctioned mechanism for API-only hosts (no password, can’t sign in)? What determines whether an account may use it — plan type, ISV status, something else?
  3. Is there a meeting-scoped alternative to ZAK for the Meeting SDK? This is my main concern with B: ZAK is per user, so an instructor holding a ZAK for host01 could also start other meetings owned by host01. start_url from the create-meeting response looks meeting-scoped — is there a supported way to use a meeting-scoped host credential with the Meeting SDK, or is ZAK the only option?
  4. When a host joins via ZAK, participant_joined reports the host user’s email. Since the real human differs from the host user in both approaches, is there a supported way to attribute a host participant to a specific person — e.g. an external identifier passed through the SDK and echoed back in the webhook?

Happy to share account ID or full request/response details privately.

2

@Buket sign up for an ISV account for custCreate users usage