# Recommended pattern for API-only host users: per-instructor users vs. a shared pool of hosts? **URL:** \ **Category:** API and Webhooks\ **Created:** [August 4, 2026, 1:53am UTC](https://devforum.zoom.us/t/recommended-pattern-for-api-only-host-users-per-instructor-users-vs-a-shared-pool-of-hosts/145263 "2026-08-04T01:53:42Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Buket](https://avatars.discourse-cdn.com/v4/letter/b/f4b2a3/32.png) [@Buket](https://devforum.zoom.us/u/Buket)\ **Post date:** [August 4, 2026, 1:53am UTC](https://devforum.zoom.us/t/recommended-pattern-for-api-only-host-users-per-instructor-users-vs-a-shared-pool-of-hosts/145263/1 "2026-08-04T01:53:42Z")
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+@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. ---
**Author:** ![chunsiong.zoom](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/chunsiong.zoom/32/35488_2.png) [@chunsiong.zoom](https://devforum.zoom.us/u/chunsiong.zoom)\ **Post date:** [August 4, 2026, 2:40am UTC](https://devforum.zoom.us/t/recommended-pattern-for-api-only-host-users-per-instructor-users-vs-a-shared-pool-of-hosts/145263/2 "2026-08-04T02:40:37Z")
@Buket sign up for an ISV account for custCreate users usage > **[Zoom ISV Partner Program](https://www.zoom.com/en/isv/)** > > The Zoom ISV Partner Program is designed to help developers embed, integrate, and take to market their application with Zoom Meetings and Video.