According to my understanding, if a user is logged into Zoom, we should be able to receive this field in the webhook payload but the current behaviour is that we are not receiving this field even though the user joining the meeting is logged into Zoom.
Hi @mubashira.salman , you are correct and thank you for flagging this. We need to update the json response for this event. In the interim, you can use participant.id as this is the same value as participant.partcipant_user_id even though it is set to be deprecated. I am following up with our docs and API team about this (ZOOM-295044, DEVELOPERS-1916).
Since this is considered personal data, it’s been removed for external participants. This should be reflected in the docs and am following up for full update.
Hi @gianni.zoom adding to this thread, our app had been using participant.id as you had mentioned in a comment above to map external participants in meetings but based on your last comment it seems like that information has been deprecated.
Can you provide any information about when it was deprecated and if there was any announcement about it as it is a breaking change for our app’s flows. And as of now is there an alternative for this available?
We are planning to utilize the participant_uuid to map Zoom participants with our internal call participants. Before proceeding, we would like to clarify two things:
Will this property value be present in the webhook payload, irrespective of whether the user is an external user or a group user?
Are there any potential changes expected in this particular field in the near future? Do you have any plans to modify its behavior or add new features?
Yes it should still be present and at this time I am not aware of plans to change in the near future.
Participant UUID: This is an id that represent the user for a specific meeting and persist through the meeting (different from the others mentioned), in the case where user drops in and out of the meeting, as long as we can identify that is the same user through other means, this participant UUID will remains the same. This id in some webhook is called participant_uuid, or persistentId in SDK or participantUUID in JS SDK
I trust this message finds you well. I wanted to discuss with you the date you became aware that the IDs for external users were no longer included in the payload. My inquiry stems from the fact that I conducted testing on the flow for external users following the announcement mentioned in this link: Announcements. During this testing, everything appeared to be functioning correctly. This leads me to suspect that the removal of IDs from the webhook payload occurred more recently rather than in late March.
I’d like to address a query. Imagine if someone happened to miss your announcements regarding the discontinuation of IDs in the payload for external users, and they’ve been repeatedly visiting the user documentation page for implementation. However, there’s no indication on that page that these IDs will no longer be included in the payload. In such a scenario, whose responsibility would this be?
It’s worth noting that it has been four months since the announcement about the changes to the IDs, yet the documentation still hasn’t been updated to reflect this.