Tracking Zoom Meeting Participants

Zoom developers often need to track meeting participants – for example, to record attendance or maintain state for each user. This article will covers how Zoom designs for privacy and permission control. In this blog, we’ll explore how participant identification works across different Zoom developer products (Meeting SDK, Zoom Apps SDK, and Zoom REST APIs/Webhooks), the limitations of each, and best practices to respect user privacy and personally identifiable information (PII).

Zoom Meeting SDK: Track participants

The Zoom Meeting SDK (used in custom apps or bots) provides basic participant info, but by default it does not expose persistent personal identifiers. Each participant is assigned a numeric user ID within the meeting, but this can change if they leave and rejoin. In fact, the SDK’s persistentID for a user is only persistent for the duration of a single session – if a user disconnects and reconnects, a new ID is generated. This means you cannot rely on the SDK’s user IDs alone to recognize a returning participant across different sessions.

Zoom intentionally avoids providing fixed personal info (like email or account GUID) via the Meeting SDK due to privacy constraints. All participants (even logged-in Zoom users) appear with meeting-specific identifiers unless you take additional steps. Here are some strategies to consistently track participants with the Meeting SDK:

Leverage a Customer Tracking ID:

The Meeting SDK allows specifying a custom Customer ID (sometimes called customerKey) when a user joins a meeting. This is an ID you provide (e.g. an internal user UUID from your system) that Zoom will associate with that participant for that meeting. By setting a unique customer ID for each join, you can later map participants across re-joins or even across meetings in your own database. For example, in the Web Meeting SDK, you can pass a in the join parameters:

Zoom Meeting SDK: Client view

Zoom Meeting SDK: Component view

In this case, “internalUser123” is an identifier from your system. After the meeting, Zoom’s reports or webhooks will include this customer_key for that participant, allowing you to correlate the user. Keep in mind this requires controlling how users join (e.g. using the SDK or generated unique Join Link for each participant via Registration link). In a public meeting where attendees simply click a link without pre-association, you may not have the opportunity to inject a customer ID.

Key takeaway for Zoom Meeting SDK :

1. Persistent IDs vs. Rejoins:

   The Meeting SDK’s generated link persistentID is helpful within a single meeting context – for instance, it remains the same when a user switches between the main session and breakout rooms. (Breakout rooms are technically separate meeting instances, so the regular user ID might change when moving in/out of a breakout. The persistent ID stays consistent in that scenario.) However, if the user fully leaves the meeting and returns later, even the persistent ID will reset with a new session. There is currently no built-in permanent user GUID exposed in the SDK that spans multiple meetings or sessions.

2. Backend Tracking via Registration or Unique Join Links:
   To track users across sessions, you often need to move logic to your backend using Zoom’s REST APIs or webhooks. One effective approach is to require meeting registration for attendees. When scheduling a meeting via the API, enable registration and generate unique join URLs for each participant. For example, create a meeting with registration requirements and no guest logins allowed:

    POST /users/{userId}/meetings 
    {
      "topic": "Participant Tracking Demo",
      "type": 2,
      "start_time": "2025-09-20T14:00:00Z",
      "settings": {
        "approval_type": 1,          // manual or automatic approval
        "registration_type": 2,      // each attendee needs to register
        "allow_multiple_devices": false,
        "join_before_host": true,
        "waiting_room": false
      }
    }
   

---

Zoom Apps SDK: Participant Info and Privacy Limitations

Zoom Apps (the apps that run within the Zoom client) have their own SDK, which also provides access to meeting participant data with strict limitations. If you are developing a Zoom App to interact with meeting participants, you should be aware of what data is available and under what conditions:

Retrieving Participant List:

Zoom Apps can call a function like zoomSdk.getMeetingParticipants() to get the current participants. However, this returns very minimal info – typically just a list of participant IDs (which are unique to that meeting) and maybe display names. It does not include emails or persistent user IDs of the participants by design. In fact, a participant’s Zoom account ID is not exposed to the Zoom App for others in the meeting. This means you cannot directly map a participant to their Zoom profile or track them outside the context of that meeting using the Zoom Apps client-side data.

Host-Only Permissions:

Originally, functions like getMeetingParticipants() were restricted to the meeting host/owner role. A regular participant’s instance of a Zoom App could not list everyone in the meeting unless that participant was the host (or co-host, if permitted). This is part of Zoom’s role-based permission framework – hosts have more ability to access meeting data than participants. The general rule is that an app cannot reveal info to a user that they wouldn’t normally have in the Zoom UI. If you attempt to call these APIs as a non-host, you might receive an error like “No Permission for this API. [code: 80003, reason: require_meeting_owner_role]”

Participant IDs in Zoom Apps:

The participant IDs you get in a Zoom App are ephemeral and context-specific, similar to the Meeting SDK. Even if two users in the meeting both have Zoom accounts, one Zoom App cannot determine the other’s actual Zoom user ID from the participant ID alone. A participant’s ID in this context is independent of their global user ID. For instance, if User A (on your account) and User B (external) are in the meeting, your Zoom App might see them as participants with IDs like “12345” and “67890” for that session. If those same people join another meeting, the IDs will be different.

Zoom App SDK

Key takeaway for Zoom Apps:

1. Sandbox of user privacy:

   Zoom Apps operate within a sandbox of user privacy. A Zoom App cannot circumvent Zoom’s rules to fetch personal data about other participants. You can design your app such that each user’s own app instance knows their information (with permission), and perhaps coordinate via the host if you need a roster (the host’s app could share participant list info with others in-app if appropriate).

   Always adhere to Zoom’s guidelines: if you need cross-user data, it must be done through explicit user consent and Zoom’s provided APIs. This protects participant PII and ensures users aren’t unknowingly exposing their identity to third-party apps.

2. No Undue Exposure of PII:

   Zoom treats things like email, full name, and account IDs as PII that should not be exposed to apps or integrations without user permission or necessity. The changes to hide participant IDs for guests in APIs and the fact that user_email comes back blank for external attendees are examples of protective design. As a developer, you should expect that any data which could identify a user (who has not explicitly shared it) will be restricted. If your integration suddenly finds an identifier field coming back null, it’s likely due to these privacy rules.

3. User Consent via OAuth:

   If you need to get a participant’s info who is not in your account or meeting, you must have them authorize your app. For instance, if you want to map external participants to some internal profile, one approach is to have those users sign up or log in through your Zoom OAuth app ahead of time. Once authorized, you might obtain their Zoom user ID or email and then use that knowledge when they join your meeting. Without this, Zoom’s platform keeps those users effectively anonymous to you. This aligns with Zoom’s OAuth permission model: only if a user or an admin grants your app scopes (like reading their profile or meeting info) can you access it

4. Role-Based Data Access:

   Zoom often ties what data you can get to your role in the meeting. A meeting host has the most access – they can retrieve reports, get webhook events for all participants, etc., because they “own” the meeting. Co-hosts and regular participants have much less access. Zoom Apps enforce this by restricting APIs like participant list to hosts only. The underlying principle is least privilege: an app should not retrieve more info than the user running it is entitled to see in the Zoom client. For example, a participant cannot see other participants’ emails in the Zoom UI, so neither can their instance of a Zoom App or Meeting SDK client.

5. Breakout Rooms:

   If your app tracks a user through breakouts, you don’t lose the reference because participant UUID that remains consistent across breakout rooms. Still, this ID would reset once the meeting ends; it’s not a permanent user identifier beyond that scope.

6. Accessing User Profile (with Consent):

   What if your Zoom App needs to know who the user is (for example, to greet them by name or save data per user)?

   For the user who installed/authorized the app (i.e., the app’s current user), you can request Zoom OAuth scopes to get their profile info. A Zoom App can include the scope**user:read** (“View your user information”) which, when the user grants it, allows the app to call Zoom’s REST API for that user.

   A common pattern is: the Zoom App obtains the current user’s Zoom user ID via the Zoom Apps context, then calls the /users/me endpoint on your backend (using the OAuth access token) to retrieve their email, name, etc.This gives the app the installing user’s identity, but not others’. For other participants, each of them would have to also authorize the app (and even then, one user’s app session cannot freely pull data on another user unless Zoom explicitly allows it via an event or permission).

---

Zoom REST APIs and Webhooks: Server-Side Participant Tracking

Outside the in-meeting SDKs, the Zoom REST API and webhook events are powerful tools to track participants – especially if you are the meeting organizer or have administrative access. Using these, you can gather details about meeting attendees, but it’s crucial to understand the permission boundaries Zoom enforces:

To create user-specific links, enable meeting registration, then call Add Meeting Registrant API—the response provides a unique join URL for each registrant.