I am trying to build a dashboard that lets me know all Zoom Rooms that are in meetings (I don’t care about users’ personal meetings)
I don’t see a better webhook than “meeting.started”. There is no “zoom_room.meeting.started” webhook, for example
Here is a meeting.started webhook payload - {“event”:“meeting.started”,“payload”:{“account_id”:“”,“object”:{“duration”:60,“start_time”:“2025-02-07T20:20:49Z”,“timezone”:“”,“topic”:“SFO-7 729-Dining Room’s Zoom Meeting”,“id”:“94611288871”,“type”:1,“uuid”:“iatC4/2xQuyElYO6ex8jjg==”,“host_id”:“W3GNVZSfQBaWcSr73zT23w”}},“event_ts”:1738959649990}
It doesn’t have any data that declares its a Zoom Room, and not a normal user. I know that every ZR has an enderlying psuedo ‘user’, but there is not easyway to get that data here. The only way I can do this is if I reverse engineer from the users list, out of our entire org (7,000+ users), and parse out the host_id field, and then cross reference. Not very performant, when it would be much easier so many other ways.
Does not look like we have something like this (big surprise - the entire Rooms product is critically underserved). Would be looking for a room-specific Rooms webhook (Rooms Webhooks - Zoom Developers) for meeting started/ended.
These triggers are already being issued for ZR Native Room controls:
So exposing this field via API (not even included in QSS summary here - QSS APIs - Zoom Developers) would be extremely helpful for identifying ZRs in ongoing meetings as well.
Hi @patrickgilsf , unfortunately for your purposes, you are correct that the payload of meeting.started doesn’t offer detailed host data beyond the host_id. You could take a few steps to make your lookup more performant, e.g. build a “cache” of room user IDs that you pull en masse on a periodic basis (e.g. daily? Zoom Rooms tend not to be added/removed frequently). Your webhook receiver that handles the incoming payload can then consult the local cache, instead of pulling down the entire user list over a series of API calls for every single payload. Even if the cache is a simple textfile, you should be able to match very quickly, and it’s not going to take much memory or storage to store a bunch of strings.
If true “realtime” status is not as important to you, you could also consider simply polling the Dashboard API for List Zoom Rooms at maximum page size (to conserve your resource intensive queries).
Thank you @nicholas.mueller for confirming. I like your workarounds, but in terms of all things feature requests, this is a pretty easy one to implement, so I’m going to push for that through our channels. ‘isRoom=true’, feels like an easy one.
Since rooms have an underlying, pseudo ‘user’, it would be nice to have a few more methods for knowing which users across an entire enterprise are actually rooms.
