Possible to receive edit a meeting webhook based on meeting uuid rather than meeting id

API and Webhooks
1

A colleague pointed out that meeting id is not unique (when using Personal Meeting ID). Thus we are going to have to use meeting uuid rather than meeting id everywhere in the code. Are there equivalent API calls and webhooks? My particular concern right now is with webhook edits. Currently we use “meeting.updated”.

2

Hi @chrismurrph,

Thanks for raising this, and you’re correct about this within the context of meetings scheduled using a PMI. Our webhooks will return the PMI ID in their payload, which is currently expected behavior. More details on this here as well.

If you need to keep track of unique occurrences of meetings based on PMI, you can also query our List Ended Meeting Instances API based on PMI as well—this will return UUIDs for ended meeting instances:

Let me know if this is helpful. :slight_smile:
Will

3

Yes I’m pretty sure I understand what you are saying - to get the meeting we need to update (only available by meeting uuid) we will need to make an API call when the “meeting.updated” webhook is received. This API will return meetings and each one will have an attribute ‘last updated time’ (as well as id and uuid of course). There will be more than one meetings when filtered by the id that is coming through on the WebHook. But the meeting that the update is actually for is the most recently updated one, as long as it is within the last say 2 minutes. Does that sound like the logic that needs to be applied here?

4

Hi @chrismurrph,

This is mostly correct! However, the List Ended Meeting Instances will return the Meeting UUID and the start_time. You can use the start_time to determine which Meeting (instance) UUID corresponds to the one you’re looking for.

Let me know if this helps :slight_smile:
Will

5

I can see how that would ‘work’ for most common situations where the user is making a change to a recently created meeting. But it is not full proof. I could create meeting A then create meeting B then decide to change the duration of meeting A. By using start_time the edit would be made to the most recent meeting, meeting B.

We wouldn’t need to be even thinking about this if “meeting.updated” web-hook came with a uuid. Is this fix coming up anytime soon?

6

Hi @chrismurrph,

I appreciate the reply and this feedback—I can certainly understand where you’re coming from. I’ve gone ahead and reached out to our Engineering team to better understand why UUID doesn’t appear to be returned for PMI meetings when they’re updated, and I’ll follow up with you here shortly (ZOOM-274921).

Thanks,
Will

7

Hi @chrismurrph,

I have some good news to share! Our team has confirmed that the UUID should be returned by this webhook, and we’re treating this as a bug. We will be addressing this in an upcoming release.

Thanks again for raising this with us, and I’ll be happy to follow up here once released. :slight_smile:

Best,
Will

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.