Meeting & Recording Data Questions

Description
While processing Zoom callbacks and Get Meeting Participants API data, we are seeing some discrepancies in the response returned for some instances as far as the Recording duration and the Participant Records count.
Also, for the meeting event callbacks, does the duration value represent the scheduled meeting duration or the actual duration? For example, if someone scheduled an hour meeting at 10:00AM, but it was ended after forty-five minutes, would we get the values in Item 1 or 2? We are relying on the duration value, since the end time is not provided in the response.

  1. start time: 11/25/20 10:00 am duration: 60 (mins.)
  2. start time: 11/25/20 10:00 am duration: 45 (mins.)

Error
Here is an example with a duration value of 0 for the recording, even though there was a recording provided in the Recording Completed Event. Other Recording Instances for this meeting all had duration values greater than 0, but the one w/snippet below didn’t, why would it be different for this instance?

  • D14iSL0tRfWl2BT1l9Yl4w==

  • Uc2YkwbyTym8sWsaG1gpPg==

  • tkRRnDb7T2S51jEB+9EwLg==

  • Meeting Id: 98049412256

  • ZoomInstanceUUID: oqe93g6NSlqQ9SBcJXOjAw==

  • Response Snippet:

“account_id”: “O1GCLBV8QkinDPUaj4fNOw”,
“operator”: null,
“object”: {
“uuid”: “oqe93g6NSlqQ9SBcJXOjAw==”,
“id”: “98049412256”,
“host_id”: “USQZVAhGQ06og5IxNJkY1w”,
“topic”: “KedarGousiRam”,
“type”: “2”,
“start_time”: “2020-11-20T20:55:33Z”,
"duration": “0”,
“timezone”: “America/Chicago”,
“host_email”: “Ly************@***************.com”,
“total_size”: “1372859”,
“recording_count”: “3”,
“share_url”: “https://zoom.us/rec/share/pg3sHWnosU72e2vNrX7HGr6DO0BUwIG_hDJ8Zpv53iy10HgL23jOrOHdL2VL6Tx7.Uh2-knSAUrZAuXeF”,
“recording_files”: [
{
“recording_start”: “2020-11-20T20:57:32Z”,
“recording_end”: “2020-11-20T20:58:12Z”,
“id”: “c80a26b3-795c-4fcd-bb71-115aec9f800b”,
“meeting_id”: “oqe93g6NSlqQ9SBcJXOjAw==”,
“file_type”: “MP4”,
“file_size”: “735503”,
“play_url”: “https://zoom.us/rec/play/aTUQnvqfpM_4At2_TLJNEZuVtvOau9-1ObIzaibQlUtjVdOR4VX8ozVRZFAFL6fBEmPvSuvithDHCANA.qjatPA3zqEMooAYr”,
“download_url”: “https://zoom.us/rec/webhook_download/aTUQnvqfpM_4At2_TLJNEZuVtvOau9-1ObIzaibQlUtjVdOR4VX8ozVRZFAFL6fBEmPvSuvithDHCANA.qjatPA3zqEMooAYr/59Npa4_h2U1AYYqU1EiaQpYQMpXdd8jz03YCh5MJCwZ3gyq4_ncQ7tB22Lnpkg”,
“status”: “completed”,
“recording_type”: “shared_screen_with_speaker_view”
},


For the following instance, we recieved additional records, but the other three instances had the correct number of participant records. Can you please tell us why this is the case?

  • Uc2YkwbyTym8sWsaG1gpPg== - total records: 3

  • oqe93g6NSlqQ9SBcJXOjAw== - total records: 3

  • tkRRnDb7T2S51jEB+9EwLg== - total records: 3

  • D14iSL0tRfWl2BT1l9Yl4w== - total records: 7

{
“result”: {
“page_count”: “1”,
“page_size”: “30”,
"total_records": “7”,
“next_page_token”: “”,
“participants”: [
{
“id”: “USQZVAhGQ06og5IxNJkY1w”,
“user_id”: “16778240”,
“name”: “Ly Bolia”,
“user_email”: “ly***i@p.com”,
“join_time”: “2020-11-20T21:05:16Z”,
“leave_time”: “2020-11-20T21:13:19Z”,
“duration”: “483”,
“attentiveness_score”: “”
},

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

Which Endpoint/s?

How To Reproduce (If applicable)
N/A

Screenshots (If applicable)
N/A

Additional context
N/A

Let us know if any additional details are needed.

Thanks.

Hi @kupadhyaya,

Thank you for reaching out about this and for providing all these details.

Regarding the first instance (duration 0 on meeting 98049412256), this appears to be a bug and our team is looking into this (ZOOM-198833).

In terms of your question:

for the meeting event callbacks, does the duration value represent the scheduled meeting duration or the actual duration?

This should represent the actual duration

As for your other example:

For the following instance, we recieved additional records, but the other three instances had the correct number of participant records. Can you please tell us why this is the case?

Can I kindly ask for the request URL that generated the JSON response you provided? This will help to take a closer look.

Thanks!
Will

Hi Will,

Thanks for the follow-up. When a ticket/bug like “ZOOM-198833” is opened, when can we expect a resolution or how can we follow-up on it as far as a fix?
Per your request to the Participants question, we call the following URL with the Meeting Id

https://api.zoom.us/v2/report/meetings/{meetingId}/participants

Let me know if you need any additional details.

Thanks.

Hi @kupadhyaya,

Our team tries to prioritize bugs so that we can address them as soon as possible. We’re still looking into this and I hope to have an update for you shortly.

In regards to the Meeting UUIDs you provided for the concern over number of records returned by the API, I’m not seeing any issues with these records on my end. To clarify, for UUID D14iSL0tRfWl2BT1l9Yl4w== where you’re seeing 7 records returned via the API, is it possible that some attendees have more than 1 record? This can happen if they were admitted to a waiting room and then the meeting, or if they were temporarily disconnected.

Let me know—thanks!
Will

Hey Will,

Thanks for the update. “Our team tries to prioritize bugs so that we can address them as soon as possible. We’re still looking into this and I hope to have an update for you shortly.” - Sounds good, keep us posted!

To your second point, they should only have a single record like the other three instances. Your explanation seem plausible, these additional records are only four or five seconds in duration and the leave time on them almost coincides with the actual duration records join time. I don’t know if this is the result of them being in the waiting room (1st record creation) and then being admitted in the meeting (2nd record - actual w/realistic duration and join/leave time) or disconnect issue, but probably unlikely, that it happened to all three users? If you can offer any other details or input, it may help pinpoint the issue. That indicator would be helpful here! :slight_smile:

Thanks.

Hi @kupadhyaya,

Thanks for the update. “Our team tries to prioritize bugs so that we can address them as soon as possible. We’re still looking into this and I hope to have an update for you shortly.” - Sounds good, keep us posted

Of course!

To your second point, they should only have a single record like the other three instances. Your explanation seem plausible, these additional records are only four or five seconds in duration and the leave time on them almost coincides with the actual duration records join time. I don’t know if this is the result of them being in the waiting room (1st record creation) and then being admitted in the meeting (2nd record - actual w/realistic duration and join/leave time) or disconnect issue, but probably unlikely, that it happened to all three users? If you can offer any other details or input, it may help pinpoint the issue. That indicator would be helpful here!

Can you share the full API response JSON payload for this Meeting: D14iSL0tRfWl2BT1l9Yl4w== , with all of the records? I’m happy to take a closer look!

Thanks,
Will

Sounds good, here you go.

Meeting Instance: D14iSL0tRfWl2BT1l9Yl4w==

Payload:

{
“result”: {
“page_count”: “1”,
“page_size”: “30”,
“total_records”: “7”,
“next_page_token”: “”,
“participants”: [
{
“id”: “USQZVAhGQ06og5IxNJkY1w”,
“user_id”: “16778240”,
“name”: “Ly Bolia”,
“user_email”: “lybolia_rc_stf_api@perdoceoed.com”,
“join_time”: “2020-11-20T21:05:16Z”,
“leave_time”: “2020-11-20T21:13:19Z”,
“duration”: “483”,
“attentiveness_score”: “”
},
{
“id”: “JZbaN1VkTZqjuD_STptwkQ”,
“user_id”: “16779264”,
“name”: “Corey Bess”,
“user_email”: “coreybess-rc_std@perdoceoed.com”,
“join_time”: “2020-11-20T21:06:27Z”,
“leave_time”: “2020-11-20T21:06:31Z”,
“duration”: “4”,
“attentiveness_score”: “”
},
{
“id”: “JZbaN1VkTZqjuD_STptwkQ”,
“user_id”: “16780288”,
“name”: “Corey Bess”,
“user_email”: “coreybess-rc_std@perdoceoed.com”,
“join_time”: “2020-11-20T21:06:31Z”,
“leave_time”: “2020-11-20T21:13:19Z”,
“duration”: “408”,
“attentiveness_score”: “”
},
{
“id”: “Rje0gXxnSRGxaEknFumF2Q”,
“user_id”: “16781312”,
“name”: “ChungHeng Lim”,
“user_email”: “chunghenglim-rc_std@perdoceoed.com”,
“join_time”: “2020-11-20T21:07:24Z”,
“leave_time”: “2020-11-20T21:07:29Z”,
“duration”: “5”,
“attentiveness_score”: “”
},
{
“id”: “Rje0gXxnSRGxaEknFumF2Q”,
“user_id”: “16782336”,
“name”: “ChungHeng Lim”,
“user_email”: “chunghenglim-rc_std@perdoceoed.com”,
“join_time”: “2020-11-20T21:07:29Z”,
“leave_time”: “2020-11-20T21:13:19Z”,
“duration”: “350”,
“attentiveness_score”: “”
},
{
“id”: “62V67MCOS0CmMtcmn50PLw”,
“user_id”: “16787456”,
“name”: “reddy ipad”,
“user_email”: “ipadreddy@atlanta.com”,
“join_time”: “2020-11-20T21:09:40Z”,
“leave_time”: “2020-11-20T21:09:44Z”,
“duration”: “4”,
“attentiveness_score”: “”
},
{
“id”: “62V67MCOS0CmMtcmn50PLw”,
“user_id”: “16788480”,
“name”: “reddy ipad”,
“user_email”: “ipadreddy@atlanta.com”,
“join_time”: “2020-11-20T21:09:45Z”,
“leave_time”: “2020-11-20T21:12:14Z”,
“duration”: “149”,
“attentiveness_score”: “”
}
]
},
“meta”: {
“httpStatus”: “OK”,
“ErrorDetail”: null,
“IsSuccessful”: true
}
}

Thanks for sharing this, @kupadhyaya!

Since I can see that this meeting did have a waiting room enabled, and the duplicate entries for these attendees are all just a couple of seconds in duration, it does appear that this is reflective of them being admitted to the waiting room (1 record) and then admitted to the meeting (another record).

I hope this helps to clear things up, but let me know if you have questions about this!

Best,
Will

Hi Will,

Thanks for confirming, so would there be an indicator in the future to help discern between a waiting room Participant record versus the one in the meeting?

Regards,
Kedar

Hi @kupadhyaya,

While we do have it on our roadmap to make this clearer in the API response, it’s not currently denoted. However, if you need access to this information, you might consider leveraging the following webhooks:

I hope this is helpful,
Will

Hi Will,

Thank you again, that is a good suggestion, we may look into that. We are seeing more and more tickets with Participant Report discrepancies due additional records of them being in the waiting room or potentially getting disconnected at certain points.

We also uncovered another issue and where we made a call to get Participant details, but didn’t get any records in the response. However, when I tried through the Marketplace little earlier, I do see response with the Participant records, screenshots below. Can the team shed some light on this?

Meeting: 99140975650
Zoom Instance (UUID): WT9gcaGfQ2C2BYAitlQYRg==

API URL: https://api.zoom.us/v2/report/meetings/{meetingId}/participants

API Response:

Marketplace Response:

Thanks,
Kedar

Hi @kupadhyaya,

Are you still seeing this empty response when you submit the request outside of the Postman tool? Or was this a transient error?

If you’re still seeing this, can you confirm whether you were passing the UUID or the Meeting ID in your request url?

Let me know—thanks!
Will

Hey Will,

We have found 747 records (Meeting/Meeting Instances), but all records are from 11/25 or 11/26, none after that and one before on 11/19, if I recall correctly.
I haven’t tried through Postman, but I did try one instance through the Zoom Marketplace and got a response with Participant data. I believe we pass the Meeting Id in our code, but I will confirm and let you know.

Thanks,
Kedar

Hi @kupadhyaya,

Thank you for the update and for clarifying—please do let me know when you have a chance.

Thanks,
Will

Hi Will,

We are making the request by Meeting Id, not by Meeting Instance Id

Thanks.

Hi @kupadhyaya,

So far I’m not able to replicate this. If you’re stills seeing this issue, can you share your latest example (request URL and response) where the participant data is empty?

Thanks,
Will

Hi Will,

Thanks, I reran the query to check our table and we don’t have any new records, except from those two days that I mentioned originally. I wanted to ask you about another ticket, where it was reported that a Recording is stuck w/conversion in progress. I know it can take some time based on the size of the file to convert as well a the server load. However, this meeting/recording was from 12/2 and we have no record of receiving a recording completed event. Can your team take a look?

Meeting Id: 96111260562

Instance Id: VbnUcNKgRPq0Vzd9+DS2gA==

Events Received:

  • Meeting Started
  • Recording Started
  • Recording Stopped
  • Meeting Ended

Also, in cases such as this, what are our alternatives? Is there a way we can retry or retrigger a callback for meeting?

Thanks,
Kedar

Hey @kupadhyaya,

Strange—I’m looking into this for you (ZOOM-227924).

Thanks, and I’ll be in touch,
Will

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