Identifying past instances of reoccuring meetings

API and Webhooks
1

Hi,

I’m trying to pull a list of registrants for a past occurrence of a reoccurring meeting. I am using “https://api.zoom.us/v2/meetings/”+meetingID to retrieve occurrences and get their IDs, but this is only showing me occurrences in the future. How do I retrieve occurrence ids for past events?

Many thanks

2

Hey @john3,

You will need to call the GET /past_meetings/{meetingId}/instances endpoint to get MeetingUUIDs, and then call any of the following participant endpoints:

Thanks,
Tommy

3

Hi @tommy
I’ve just gone through this and it looks like this gets me details of the participants, not the registrants. I see how to get the UUID for a meeting instance in the past, but the List Registrants end point requires an occurenceID. I still can’t figure out how to find this for a past meeting.
Many thanks.

4

Ah - I’ve just figured it out by… reading the documentation properly :rofl:

I’d missed the show-previous-occurrences parameter on Get /meetings/{meetingID}

Many thanks,

1 Like
5

Glad it’s figured out @john3, let us know if you need any help :slight_smile:

1 Like
6

Hi, @john3 / @tommy

I am fighting with the same thing for the last couple hours, and I still can’t see how you can match meeting participants with the meeting registrants.

Ok, /meetings/:meetingId returns occurrence_id with the parameter (thanks to @tommy in my own thread about this), but there is no relation with (meetingID & occurrence_id) pair with the participant data returned by using meetingUuid.

This meeting has 6 occurrences and occurrence record has only the following fields - nothing related with meetingUuid:

"occurrences": [
    {
        "occurrence_id": "1595185200000",
        "start_time": "2020-07-19T19:00:00Z",
        "duration": 60,
        "status": "available"
    },

I use this occurrence_id to get the registrants for this occurrence. However, there is no occurrence_id parameter to be used with the list meeting participants endpoint. /metrics/meetings/:meetingId/participants.

How can we find the corresponding meeting instance (meetingUuid) for an occurrence? I simply want to compare Occurrence 1’s registrant data with the corresponding meeting instance’s participants.

@john3 - from you message, I can see that we are looking for the same thing, except you figured it out. Could you please help me to figure it out as well?

Thank you very much.

7

Hey @smozgur,

The way you connect a meeting occurrence (before it happens), with a meetingUUID (after it happens), is with the List Ended Meeting Instances endpoint.

Since the meetingID is the same between the two, you pass in the meetingID, and out comes the list of occurrences with the meetingUUID, which you can use to call the Participants Metrics and Reports endpoints.

Does that make sense?

(FYI the occurrence_id is not present in the List Ended Meeting Instances endpoint, but you can infer the occurrence with the start_time. A great improvement to this endpoint would be including the occurrence_id, do you agree?)

Thanks,
Tommy

8

Thanks for the reply, @tommy.

Unfortunately no. I have no problem with getting the meeting instances for a meeting. However, the only way retrieving registrants for a recurring meeting is first getting the occurrence_ids (/meetings/:meetingId?show_previous_occurrences=true) and then calling the same endpoint with occurrence_id (/meetings/:meetingId?occurrence_id=1595185200000) - which is the timestamp of the occurrence’s original start_time. Then we are back at the disconnection between participants that could be retrieved through Metric / Reports.

Inferring wouldn’t work for database management in a database system which is supposed to be highly relational. I have sample meetings that occurrence start_time is saved as 17:00 but actually occurred 17:25 or later.

That’s what I was hoping there is one already! It is definitely a requirement, so I cannot be more agree on anything else.

Thanks again for your reply. I feel better now knowing that it was not my fault but it simply doesn’t exist.

9

Hey @smozgur,

I have added this as a feature request. (ZOOM-183303) I will keep you updated on its development!

Thanks,
Tommy

10

Wanted to follow up on this. Has this been implemented yet? I am trying to do the same thing: map instances and occurrences together, and as smozgur mentioned doing it via timestamp does not work if a meeting started late.

If it hasn’t is there another suggested workaround to this problem?

Thank you,
Ben

11

Hi @tommy,
Any updates regarding feature request - ZOOM-183303?
Missing mapping info between occurence id and instance uuid is causing some real trouble in our implementation and leading us to some unreliable workarounds (e.g. timestamp).

12

Hey @MelisaB and @bensw,

Thank you for reaching out to the Zoom Developer Forum. Our internal team indicated that there isn’t a relationship between Occurrence ID and Meeting UUID so this isn’t a feature they would be able to add.

This is because, as you’ve seen, if a meeting is started at the wrong time, early or late, then it’s impossible to say if this was an occurrence of a previous meeting or a future meeting.

When a meeting occurrence ends, the occurrence gets its own Meeting instance UUID and that is what should be used to reference a specific occurrence.

image

I hope that helps! Let me know if you have any questions.

Thanks,
Max

13

Hi @MaxM ,

Let me provide more details about our case.

Currently, on our side we are storing Zoom meeting number and occurrence id. This works fine for updating/removing future occurrences using Zoom API.

Occurrence gets meeting UUID once the meeting is ended (I’m familiar with relevant webhook). However, my question is: how can we associate this meeting UUID to appropriate occurrence in our system if there is no mapping between occurrence id and meeting UUID?

Your colleagues suggested that the recommended approach is to base it on timestamp (more precisely it can only be based on date). However, endpoint for getting past meeting details retrieves only actual start datetime, but not the scheduled date time. Actual start datetime and scheduled datetime can differ (e.g. if meeting starts around midnight, which can result in having different dates and therefore being unreliable).

So, to summarize, if it not possible to provide mapping between occurrence id and meeting uuid, would it be possible to have Meeting Ended Webhook send Scheduled DateTime as well, or at least extend endpoint https://marketplace.zoom.us/docs/api-reference/zoom-api/meetings/pastmeetingdetails to include scheduled datetime as well?

14

Hey @MelisaB,

Thank you for providing additional information. I tested using the List Ended Meeting Instances API and saw that this returns the actual start_time of the meeting along with the uuid.

Let me know if using that API to map occurrence timestamps to UUIDs works for you.

Thanks,
Max

15

Hey @MaxM,
This endpoint returns actual start time, while we need scheduled start time of ended meeting instance for comparison. That’s the only reliable alternative to this occurence id → meeting uuid mapping.

16

Hey @MelisaB,

Thank you for clarifying. Have you tried calling the Get a Meeting API with the occurrence_id to get the scheduled start time of the meeting? Then, you can compare that UUID and start_time with what is returned by the List Ended Meeting Instances API.

Let me know if that helps.

Thanks,
Max

17

Hi @MaxM,

I’m not sure that we are on the same page here, so I will try to provide more details. Let’s consider the following example:

  1. We have recurring meeting (daily recurrence, repeat every day, total of 3 occurrences, start time is midnight 00:00h.)
  2. When meeting is created, Zoom is generating meeting number and occurrence id for each occurrence, example below:
    Meeting number: 92872115949
    1st Occurrence - [Feb 9, 2021] 12:00 AM - OccurrenceId: 1612991600000
    2nd Occurrence - [Feb 10, 2021] 12:00 AM - OccurrenceId: 1612911600000
    3rd Occurrence - [Feb 11, 2021] 12:00 AM - OccurenceId: 1612998000000
    This info has been stored in our database.

As it is a common scenario with all meetings, they can be started earlier/later than scheduled, so let’s have our host starts the meeting 10 minutes earlier for the 1st occurrence, so that would be at → Feb 8, 2021 11:50 PM.
After 1st occurrence is ended, Zoom is generating meeting UUID for this occurrence and Webhook Meeting Ended is sending the following info (only relevant info is specified below):

  • Id → Meeting Number - > 92872115949
  • Uuid → Unique identifier of past meeting instance → e.g. RtbEFAnaTNaS4r3SolGe0Q==
  • Start_Time → Actual Start DateTime Of the Meeting → Feb 8, 2021 11:50 PM

As you can see, based on the info sent by webhook, we can try to filter occurrences based on the combination of Meeting number and Start Date, however for this case there will not be a match, as scheduled and actual dates are different in this case.
Additionally, there would be issue if meeting was scheduled at 11:50 PM and host starts meeting 15 minutes later. In that case there would be a match, however it would incorrectly associate it to next occurrence.

https://marketplace.zoom.us/docs/api-reference/zoom-api/meetings/meeting - There is no mapping between occurrence id and meeting uuid and start datetime logic is faulty, so it can’t be used.

https://marketplace.zoom.us/docs/api-reference/zoom-api/meetings/pastmeetings - This endpoint also returns actual start datetime of occurrences, so it can’t be used.

To summarize, if I’m not missing something, this presents significant omission, since we need to associate meeting uuid with occurrence because of recordings and for retrieving reporting details of past meeting instance from Zoom side, while currently there is no way to achieve it without notable mistakes.

I understand the background why Zoom architecture was designed this way, however this is something that should be prioritized in near future.

18

Hey @MelisaB,

Thank you for providing those details, that’s very helpful. My understanding is that you are looking to map Occurrence IDs to Meeting UUIDs. Currently, the best method that we have is by comparing the occurrence Actual Start Time with the former and upcoming meetings Scheduled Start Times.

This means that in order to accomplish this, you will need the Actual Start Time of the occurrence and the Scheduled Start Time of the meeting occurrences before and after that time. Using custom logic, you can then determine what meeting UUID the occurrence belongs to.

Is that correct?

As you mentioned earlier, it seems the final piece of this puzzle is obtaining the Scheduled Start Time. While we don’t have a webhook that returns this, you can use the Get a Meeting API to obtain the scheduled start time per occurrence_id.

image

If you would like the Scheduled Start Time to be returned by the webhook in a future release, I recommend posting in the #feature-requests category.

Is there any reason that you requested this endpoint specifically? Do you need to pull this information after a meeting has expired? I’m having trouble understanding why this API would work where the Get a Meeting API would not.

As you can see, based on the info sent by webhook, we can try to filter occurrences based on the combination of Meeting number and Start Date, however for this case there will not be a match, as scheduled and actual dates are different in this case.
Additionally, there would be issue if meeting was scheduled at 11:50 PM and host starts meeting 15 minutes later. In that case there would be a match, however it would incorrectly associate it to next occurrence.

I definitely understand that. This is the same reason that our engineering team reported that there isn’t a relationship between occurrence_id and meeting UUID. I realize that using the timestamp poses issues when trying to relate occurrences to meeting IDs.

While we may not use the occurrence_id itself, I think that having the ability to map a specific occurrence to a meeting UUID is a needed feature. At this risk of sounding like a broken record, this seems like another good candidate to post in our #feature-requests category.

In the meantime, using the timestamp method really is the best bet. Let me know if my understanding of what you are looking to accomplish and what is needed is correct.

Thanks,
Max