Comparing past and upcoming meeting occurrences

Our application pulls in upcoming meeting occurrences to look at registered users so our staff can send out email reminders, etc.

Our application also pulls in previous meeting occurrences to compare attended and registered counts and users.

It would be great if Zoom made it possible to tie previous and upcoming meeting instances together so we could compare data. Unfortunately, after an occurrence happens, the uuid and occurrence_id change.

For example, at “/past_meetings/{meeting_id}/instances”, uuid and occurrence_id are structured like: “nYvNNxLRSEiTXaYTvOM5rA==”

But at “/meetings/{meeting_id}”, uuid and occurrence_id are structured like: “1624546800000”

Why do these change? Shouldn’t there be a field to identify meeting instances by that doesn’t arbitrarily change? Is there any way for an API consumer to compare previous and upcoming meeting occurrences?

Which Endpoint/s?

How To Reproduce (If applicable)

  1. Create a meeting with an occurrence in the future.
  2. Query the API that provides upcoming meeting instances. Get the uuid and occurrence_id
  3. Wait for meeting instance to happen.
  4. Query the API that provides previous meeting instances. Get the uuid and occurrence_id.
  5. You’ll see the same meeting instance has a different uuid and occurrence_id before and after it has taken place.

Hey @matthew.boman,

Thank you for reaching out to the Zoom Developer Forum. This is a topic that we’ve covered in a previous post, linked below. Essentially, there isn’t a good relationship between an occurrence_id and the UUID that is assigned to a meeting when it is scheduled. I understand there is a need for this, and we have reached out to our engineering team, but it seems the best option is to use timestamps if your use-case requires that you map occurrence_ids to UUIDS.

Let me know if you have any questions.


I’m noticing the timestamps aren’t the same either. Would this happen if a user started a meeting early?

Hey @matthew.boman,

Yes, the timestamps can vary based on if the API returns the Actual Start Time of the meeting or the Scheduled Start Time of the meeting.

When it comes to mapping occurrence_ids to UUIDs, the best option is to use custom logic to determine how close the Actual Start Time is to the Scheduled Start Time in order to figure out which occurrence_id a UUID belongs to.

Let me know if that makes sense.


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