Get email or ID data about consenting non-organization users in participant joined webhook?

API Endpoint(s) and/or Zoom API Event(s)
meeting.participant_joined webhook

Description
Our app is a virtual space for a private educational community. Our organization has several paid Zoom accounts, each of which corresponds to a location in the virtual space rather than a human user. When users (whose Zoom accounts are not part of our organization) join the personal Zoom meeting of any of our paid “location” accounts, we detect this using the meeting.participant_joined webhook, and move their avatars near the location they joined, so the virtual space visually reflects what’s happening on Zoom.

When we first built this in 2021, we could match the data in the webhook to a user in our database using the participant ID and email. However, two changes since then (removal of id and participant_user_id from the webhook data and new email address display rules) mean that these fields are almost always an empty string in our webhook payloads, even though we require users to be logged in to join our meetings, and "zoom_authentication_type" is always "account". Other posts about this issue suggest using registrant_id instead, which won’t work for us, because we don’t require users to register for our meetings in advance.

I totally understand the need to hide ID and email for privacy reasons as they are PII. However, in our case, the users are a small number of consenting participants, who would be happy for us to receive this data. They just aren’t members of our organization, because it would be too much of a hassle to require people to set up a new Zoom account to participate in a 6 to 12 week program rather than just using the one they already have.

Is there anything we can do to get persistent ID or email data for these users? E.g. by uploading a list of their emails somewhere to inform Zoom that they’ve consented to having their email shared with us?

Thanks for any help,
James

@porterjamesj , unfortunately having meeting with registration required and getting the registrant_id is the best way to move forward in current scenario.
Here is another but a more non conventional way (which I do not recommend) :
a. Create an app (with user:read) scopes and publish it in the marketplace
b. Have your users who will be attending the meeting install the app first, in this way, you can capture their user_id
c. Since your meetings require authentication, the participant_user_id will be similar to their user_id

@ojus.zoom thank you! That’s an interesting idea. It still might be too clunky, but we’ll think about it. Cheers.