/past_meetings/{meetingUUID}/participants not working? Or I am missing some valuable info

I created, joined it with one user, completed and ended the meeting. I now need to use the OAuth API to gather information about the meeting participants. However, the one API endpoint I see that should do this is not working. I have a feeling it has to do with the “past_meeting” versus “meeting” concept.

First pic below shows me using the meeting UUID found through /meetings/{meetingID}

The second pic below shows me testing using the regular meetingID, just in case there was a small error in the documentation.

Which App Type (OAuth / Chatbot / JWT / Webhook)?

Which Endpoint/s?

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Create/Start a meeting
  2. Join with one user
  3. End the meeting
  4. Call /past_meetings/{meetingUUID}/participants

Screenshots (If applicable)
All above!

Additional context

So, to answer this and the reply in the other topic.

If you use the “meeting ID” (the 9 to 11 digit) in past_meetings endpoints (aside from /instances), it only returns information about the latest meeting instance.

The UUID (the much longer, base64-encode looking string) will give you information about a specific occurrence, which you can retrieve from /past_meetings/meetingId/instances.

If you use the UUID from a fresh /meetings/meetingID response in a /past_meetings call, it will not work as the meeting hasn’t passed yet. If you’re storing that UUID from BEFORE the meeting starts, and using it after the meeting ends, it should work as expected (in theory).

Every time you start a meeting of the same MeetingID, the UUID changes but the MeetingID stays the same. You would only be able use that UUID after the meeting ends.

Using a UUID of a meeting that has not ended yet, will return the error you’re seeing in screenshot #1.

Using a MeetingID of a meeting that has had no occurrences will return the error you’re seeing in screenshot #2.

Note that in either case, /past_meetings/{uuid_or_id}/participants will not return proper information until a non-host joins the meetings. You need at least one real participant. Otherwise, it’ll just be empty response like this:

    "page_count": 0,
    "page_size": 30,
    "total_records": 0,
    "next_page_token": "",
    "participants": []

I know this all sounds inconsistent, but I guess it’s what we’re stuck with until a Zoom employee notices the struggle. :grin:


Hello samly!

After a long and wonderful weekend, I’ve implemented all the feedback you gave on Friday. And all works spectacularly.

So a big thanks.

I can see why they’d split the api endpoints between past_meetings and meetings, especially given the volume they likely deal with. But for sure it is mighty confusing. It is good they have some decent documentation, and an awesome and active community.

1 Like

Thanks @samly for your solution! We do realize inefficiencies in some flows and will work on fixing them. :slight_smile:

Happy to hear you got it working @kmwill23! :slight_smile: