Zoom API Endpoints to get Participant's Camera On/Off Information

Hi Everyone

I’m very new to the Zoom API, and I want to create something that should be simple, but I can’t find the relevant information in the zoom API endpoints.

Essentially, I want to see how long, as part of a whole meeting, a participant had their camera on or off. That’s it. If a meeting took 60 minutes, and a user had their cam open for 45 mins, I want to get 75%.

For that, I need to know at least if a participant’s camera was on or off, and/or for how long (in minutes if possible). A simple boolean (true/false) would not be enough for that (and I couldn’t even find a suitable endpoint for that).

It seems like a simple enough thing to retrieve, since there’s a lot of user information available, but I couldn’t find relevant responses in any of the API endpoints.

Could anyone help, point me to a relevant API endpoint?

Thank you for posting in the Zoom Developer Forum ! Currently, there is no User’s Camera Status Updated API or Webhook event. However, we do have participant joins and or is admitted to meeting events you can consider. See the below forum post for more details:

Additionally, based on your use case, it seems Webbooks would be more aligned with what you are looking to achieve. The links below provides a overview of the available Zoom meeting Webhooks and how to get started with Webhooks. Take a look and let us know if you have any questions or comments:

Zoom API Events - Meeting

https://marketplace.zoom.us/docs/api-reference/zoom-api/events/#tag/meeting

Using webhooks

https://marketplace.zoom.us/docs/api-reference/webhook-reference/

If this above does not work, I’d recommend submitting your use case as a feature request. Here is the link where you can submit feedback : Sending feedback to Zoom - Zoom Support

Happy to continue discussing available options for your use case as well. If interested, please kindly share more details about your use case and what you are looking to accomplish. Sharing more information about your use case will help us provide more personalized support.

Thanks @donte.zoom for the reply. I submitted a feature request to zoom, I hope they pick up on it.

I’m familiar with the “joined” information, but sadly that 's not enough to really see if a student was present during a lesson (they could simply log in to the meeting, turn off their camera, and go do something else).

Re webhooks - I am not familiar with them. I will read about them a bit for future reference.

Thanks!

Hello Idan,

I was looking for the same as you, and submitted a feature request as well.

meanwhile until Zoom would provide a dedicated reasonable solution,
I could share the workaround I am using to tackle this issue -

The " List meeting participants QoS" endpoint (/metrics/meetings/{meetingId}/participants/qos)
contains some metrics regarding quality of service for a meeting, it could be analyzed to figure out if a user turned on his camera via the video_output object, which contains some video metrics such as bitrate and resolution, so if the camera used durning the meeting, these values should be populated, and otherwise they would be null or empty…

Full documentation:
https://marketplace.zoom.us/docs/api-reference/zoom-api/methods/#operation/dashboardMeetingParticipantsQOS

With that said, since this a workaround and a NOT dedicated solution to determine if participant turned on his camera or not and when, there are some drawbacks I found myself having to handle with:

(1) The output is given divided into time spans of one minute, so perhaps Zoom are polling the meeting metrics data once in a minute so, so it potentially possible that a participant opened his camera for just a few seconds, and zoom have not yet made a record of it, and the API would return blank values for that minutes, even though it actually was used. However for your use case, I imagine it world work most of the time, you just need to iterate for each participant over all his video_output records minute by minute and and distinguish between records with values and empty records.

(2) On live meeting (if the API is called with meeting type live, during the meeting itself), only the last hour is returned, so if it is needed for the entire meeting, perhaps one should wait until it’s over and use the “past” in the meeting type query parameter.

(3) The endpoint returns maximum of 10 participants per page, so it might become a bit extensive by means of API calls.

You should also take notice on the join time of each participant, because maybe they joined only at the end of the meeting, and still the QOS mertic API would return empty records for this participant for the minutes the meeting was in progress before he joined.

So you should also probably would find this useful to correlate participant data:
https://marketplace.zoom.us/docs/api-reference/zoom-api/methods/#operation/dashboardMeetingParticipants

P.S.
Im ata tzarich od masheu daber iti

1 Like

@zoom.chananw001,
Thank you for sharing your work around along with edge cases one should consider.

@idanlib ,
Below I’ve linked the video_output object from the " List meeting participants QoS" endpoint for your reference :

List meeting participants QoS example response:

@idanlib, Another option to determine when a participant joined is to listen to Webhook events such as participant_joined. Zoom also has Websockets which provide events in near real time. Here is the help documentation on that for your reference:

https://marketplace.zoom.us/docs/api-reference/websockets/

@donte.zoom Thanks !

I forgot, but going over the documentation again of the participant QAS endpoint, it turns out its output already contains join and leave time values for each participant, so one could use these values to calculate the participants duration out of the meeting, and then iterate over the QAS records of the participant for each minutes to calculate the relative portion of the meeting/attendance that the participant camera was actually on, the other participant list endpoint ( /metrics/meetings/{meetingId}/participants) could be useful for data enrichment such as the participant’s email, role, platform, IP address, geo location, etc.

1 Like

Hi @zoom.chananw001 and @donte.zoom , thank you both for your replies and detailed information. Chanan, thank you in particular for diving into the documentation for all the gritty details. I had spent about two hours the other day doing just that (and consulting ChatGPT, who was apparently very confused and misguided about which objects contains what info).

I was aware of the QoS api, and thought about a similar workaround, but didn’t realize that the data is polled once per minute (I believe you, don’t get me wrong, but I can’t find it in the docs, so @donte.zoom if you could point me to that section, I’ll help me improve my doc-reading skills :sweat_smile:)

@zoom.chananw001, this workaround sounds like it could work, but be expensive and in terms of API calls? If I understand correctly, if my meeting has 23 attendees, I would have to retrieve the data 3 times for each minute, correct?

Also - toda raba! I would love to get in touch, it’s nice to meet a fellow dev who is working on similar challenges. This is my LinkedIn, I would love to connect.

Lastly, @donte.zoom , if I understand correctly, using the “List meeting participants QoS” endpoint requires a paid Business plan? (200$/ year/ user?)

Thanks!

Hey @idanlib ,

The 1 minutes time interval polling is my personal assumption after examining the API output, I could not find relevant docs for that matter either.

When sending a request for a list of participants’ QoS for a past meeting, for each participant we get a list of user_qos objects, each containing a “date_time” field, so there is no need to make call for each minute separately.

If we have a meeting with 23 attendees, 4 calls in total should suffice -
1 for getting the meeting ID (for example with GET /metrics/meetings: https://marketplace.zoom.us/docs/api-reference/zoom-api/methods/#operation/dashboardMeetings) , and another 3 for the attendees QoS (max of 10 participants for each call) , as far as I remember the output for a certain participant’s QoS data for a past meeting contains it’s QoS for the entire meeting.

However, if we query for a live meeting, on this case I experienced the QoS output contains data only from the last hour (max of 60 QoS records for each participant), so if our use case is to query live meetings in near real time, this is an issue which needs to be taken into account.

Another issue I just remembered with past meetings, is that Zoom NOT does support fine-grained filtering regarding the meeting timestamp. We are limited to narrow down the request by the date-level (and NOT by time), which means that if want to query on-going ended meeting during the day, we would keep getting duplicate results we have already polled earlier that day and would need to filter them out on the client side.
I tackled this issue by comparing the meeting end-time timestamp, another possibility is to collect new meetings from via web-hooks channel, and third option is to query just for live meetings, but then again we would need to deal with the fact that for meeting that last more than an hour, we would need to keep a track/data on the client side, or query them again once they are over with the “past” meeting type in-order to get the entire QoS data.

I have submitted a feature request for narrowing down the option to filter out the meeting by datetime and not just by date, hope it would be done eventually.
Personally I didn’t like to work with the web-hooks since their data model is totally different than the one in API (why didn’t Zoom keep it consistent?!!!)
and because allot of objects in the web-hooks are represented by an internal ID only with no human-meaningful description (Ex. “Group 423r583djzxZXZ Changed” - what is that group? who knows! Why didn’t Zoom include the group name in the payload as well !!!)
I submitted a feature request for that as well.

Good luck meanwhile!

Chanan

Sheihiyu brim hameftachim she avdu al ze.

Hey @zoom.chananw001, thanks again for the detailed response. It seems you’ve really made a deep-dive in to the API. Good for you! Though it does seem like the API doesn’t really make things easy, doesn’t it? Something that should be simple (times in minutes of camera on, per user), forces such huge workarounds, each with its own limitations. Not fun.

For my purposes, it doesn’t matter whether the data is for a live meeting or not (I don’t need real-time data), though I’m starting to wonder whether the whole thing is worth the hassle (it’s a personal project on my own time, not something work-related).

Anyway, got your Linkedin message - would love to keep in touch. Thank you for all your help!

Idan
p.s. legamrei

@zoom.chananw001, @idanlib ,

I just wanted to take a moment to appreciate the conversation here. You both are amazing and we appreciate your contribution to the Zoom Developer forum. As shared above, if this above does not work, I’d recommend submitting your use case as a feature request. Here is the link where you can submit feedback : Feedback - Zoom