Participants Report Discrepancies

API and Webhooks
1

Description
When a person accesses a live Zoom Meeting, for example from 9am to 10am, we are expecting a single participant record of a Join Time of 9am and a Leave Time of 10am based on user attending the meeting for full duration of an hour and not leaving and returning during that period.
However, when we call the Participant Report API, the results sometime return several records for the user as if they joined and left the meeting on several occasions, sometimes rejoining seconds after leaving, when that’s not the case. We would like to understand what would cause the results to be returned like this?

Error
N/A

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

Which Endpoint/s?

https://api.zoom.us/v2/report/meetings/96982194915/participants?page_size=30

How To Reproduce (If applicable)
Please reference the response above

Screenshots (If applicable)

Incorrect multiple instances are indicated in bold

Example

{“LmsLiveSessionId”: 916677,“ZoomMeetingId”: “96982194915”,“ZoomMeetingInstanceUUID”: “EUBxUszQQoy0tcvuMjEeUg==”,“MeetingStatusId”: 4,“MeetingDurationSeconds”: 4500,“ParticipantList”:

[{“ParticipantEmail”: “qadonotreply01_api@careered.com”,“MinutesAttended”: 20,“JoinTime”: “11/5/2020 9:41:47 AM”,“LeaveTime”: “11/5/2020 10:01:47 AM”},

{“ParticipantEmail”: “amandalanser-ak_student@perdoceoed.com”,“MinutesAttended”: 1,“JoinTime”: “11/5/2020 9:44:04 AM”,“LeaveTime”: “11/5/2020 9:44:11 AM”},

{“ParticipantEmail”: “amandalanser-ak_student@perdoceoed.com”,“MinutesAttended”: 13,“JoinTime”: “11/5/2020 9:44:12 AM”,“LeaveTime”: “11/5/2020 9:56:58 AM”},

{“ParticipantEmail”: “amandalanser-ak_student@perdoceoed.com”,“MinutesAttended”: 1,“JoinTime”: “11/5/2020 9:57:42 AM”,“LeaveTime”: “11/5/2020 9:57:49 AM”},

{“ParticipantEmail”: “amandalanser-ak_student@perdoceoed.com”,“MinutesAttended”: 3,“JoinTime”: “11/5/2020 9:57:49 AM”,“LeaveTime”: “11/5/2020 10:00:28 AM”}],“EventStartDate”: “11/5/2020 9:41:47 AM”,“EventEndDate”: “11/5/2020 10:56:47 AM”}

Additional context
N/A

Let us know if any additional information is required.

1 Like
2

Hi @kupadhyaya,

Are you seeing this consistently? Sometimes this is a result of a temporary disconnect due to internet connection/low bandwidth, interpreted as joining/leaving. Do you know if these participants were in a low bandwidth environment during this meeting? If they were temporarily disconnected due to internet issues, it could be reflected as a momentary leave/rejoin.

Let me know—I’m happy to look further into it for you.
Will

Let me know,
Will

3

Hey Will,

Thanks for getting back to me. I’ll share your response with the team. We are seen this in other instances as well. I’m not aware of these individuals having any network/internet connectivity issues. The accuracy of this data is imperative to a critical process on our end. Is there any way we can get around this issue or is there a criteria to be able to detect and somehow filter out these records?

Thanks,
Kedar

4

Hi @kupadhyaya,

Thanks for looking into that on your end. I’ve raised this with our team and we are looking into it on our end as well (ZOOM-210546).

I’ll be in touch,
Will

5

Thanks Will! Let me know what you guys find out.

Regards,
Kedar

6

Can you provide an ETA on when we expect a response as well?

7

Hi @kupadhyaya,

I heard back from my team, and this is a result of the waiting room being enabled for this meeting.

By design, if the meeting has a waiting room enabled, there is a join event for when an attendee enters the waiting room. When the host then admits the attendee to the meeting, the attendee will join the meeting and there is also an event for this. In checking our logs, we can see that this attendee joined the meeting two times—once for the waiting room, once for the meeting—so there are 4 meeting joined records.

I realize this can be a bit confusing—note that our team is working on distinguishing the attendee in the waiting room from the meeting attendee in these reports, in an effort to improve the experience here.

I hope this information is helpful,
Will

8

Hi Will,

Thanks for the update, it makes more sense now. Do you have an idea on a potential timeline on when you guys are planning to rollout a change that you described? Note, our solution hinges on what we can get in the response to help make this distinction. If your team has any other suggestions in the interim period, I’m all ears :slight_smile:

Regards,
Kedar

9

Are you guys planning to enhance the API to provide information for both attendees in the waiting room and ones present in the meeting?

10

Hi @kupadhyaya,

I don’t have a specific timeline, but it’s on our roadmap to help provide a field to distinguish waiting room vs meeting admittances.

Thanks,
Will

11

Hi Will,

Thanks for the update, not the news we were expecting to hear. We will need this change as it drives a critical process on our end, it states that this topic will close a month after last reply. How can we get updates on this issue (timeline, potential rollout date, etc…) once it’s closed?

Regards,
Kedar

12

Hi @kupadhyaya,

I recommend subscribing to our Changelog here, where we provide updates on each release:

Thanks,
Will

13

Thanks Will, I subscribed to the Changelog.

14

Thanks, @kupadhyaya — stay tuned :slight_smile:

15

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