I’ve encountered an unexpected issue with the meeting.ended event in a user-managed application configured to listen for this event. The webhook has been reliably triggering the configured backend endpoint until a specific user scenario related to co-hosting occurred.
Issue description:
Our user-managed app is designed to enhance user interaction within meetings and it relies on the meeting.ended event. Up until recently this event triggered without a fail. However, no webhook is received when the meeting initiator appoints a co-host and then leaves the meeting, transferring full control to the co-host.
Steps to reproduce:
Install the app from the Zoom Marketplace
Add User A from your Zoom account to the app but do not add User B
Have User B start a Zoom meeting and appoint User A as a co-host, then User B leaves the meeting.
User A now actively uses the app and eventually ends the meeting.
Unexpected outcome:
The meeting.ended webhook does not trigger for the app. User A was actively using the app functionality, but since the user was not the original meeting host, the meeting.ended event did not trigger.
Test for confirmation:
Add User B to the app.
Repeat the previous scenario, where User B initiates a meeting and hands it over to the co-host (User A).
This time the webhook triggers correctly upon the meeting’s end, even if User A is overseeing the meeting as a co-host when it ends. User B never uses the actual app, they only start the meeting and hand it over to User A.
Concern:
I’m trying to understand why the webhook requires the meeting initator (User B in this scenario) to be registered with the app for successful triggering? This setup is especially problematic as the host often delegates meeting management to co-hosts after starting the session.
Could anyone shed some light on whether this is the expected behavior of webhooks involving co-hosts, or if there’s a potential oversight in webhook configuration for such scenarios? Any insights or recommendations for ensuring the webhook can trigger regardless of the host’s or co-host’s app association would be immensely helpful.
Hi @zezulatomas , my initial assumption is that it has to with the privacy and user data management framework for published apps. Since the original creator of the meeting (User B) in the first example did not provide consent for the app to access their data, the webhook will not trigger.
Co-host =/= host and they do not assume full permissions available to original host so I am not surprised the app does not receive meeting event info if user b did not approve the app for their meetings.
I am moving this post to App Marketplace . @kwaku.nyante , can you offer some insight to confirm or clarify my response from the security perspective?
Thank you @gianni.zoom for the clarification. I presume you’re saying that delegating a meeting to the co-host doesn’t change the meeting ownership.
What I noticed is that adding the host user (or the respective user group) to the installed Zoom app resolves the issue. While the user still didn’t provide their explicit consent, I assume it’s now the responsibility of the admin user who intentionally makes the connection between the app and the user. Am I right?
What do you mean by adding them to the app? You mean installing the app for the host user? If that is what you mean, then installing the app is providing consent.
What I mean, Gianni, is that you can install the app from the Zoom Marketplace as an admin. In this case, you can also add other users and approve on their behalf.
admins can also add apps for users, essentially installing and authenticating these apps on their behalf. This allows admins to provide their users with pre-chosen and pre-installed apps, making their users’ workflows more connected and efficient.