Assume meeting #12345689 takes the following course:
Host starts meeting #12345689 at 3:00
Participant joins meeting #12345689 at 3:01
Host ends meeting #12345689 at 3:30
Remembering something he forgot, Host once again starts meeting #123456789 at 3:40
Participant joins meeting #123456789 at 3:41
Host ends meeting #123456789 at 3:45
Expected result
GET /report/meetings/{meetingId} should show duration of 35 minutes
Actual result
GET /report/meetings/{meetingId} shows duration of 5 minutes
For some reason, the API (and UI dashboard) only show the last segment of the meeting. When we use webhooks to calculate the duration, we properly receive webhooks for meeting.started and meeting.ended for each segment and can calculate the duration of 35 minutes.
However, we would like to use the API to correct our webhook-calculated meeting durations since we cannot guarantee that webhooks will be 100% reliable (e.g., if there is an error receiving webhooks at some point in time, or the webhooks do not arrive reliable, which has been an issue in the past).
Is there an API method that will provide the accurate aggregated duration of all segments (in this case, 35 minutes)?
To get the meeting report of the previous instance, you would need to pass in the meetingUUID, which you can get from the meeting ended webhook, or the GET /report/users/{userId}/meetings endpoint.
OR, you could call the GET /report/users/{userId}/meetings endpoint which will return a list of meetings, the latest two of which would be the two meetings you want to calculate the duration of.
I have now tested this and found that generally GET /report/users/{userId}/meetings corresponds fairly well with the webhooks, with the exception that some non-final meeting segments which our webhooks capture are sometimes not returned by GET /report/users/{userId}/meetings.
For example, for Zoom Meeting 51368xxxx by user ID 3XfVc5nJQ3SE4LvmCxxxxx we received the following start/end segments via webhook:
However, in GET /report/users/3XfVc5nJQ3SE4LvmCxxxxx/meetings, only the final segment is returned, leaving our duration off by 19 minutes. Since our duration reports are used for medical billing, a 19 minute shortage can push a billing code down one level.
Other examples just from yesterday are:
Meeting 78149xxxx - 9 minute initial segment captured by webhook was not returned by API
Meeting 83118xxxx - 33 minute initial segment captured by webhook was not returned by API
Meeting 66370xxxx - 66 minute initial segment captured by webhook was not returned by API
Meeting 44137xxxx - 57 minute initial segment captured by webhook was not returned by API
Meeting 63126xxxx - Of 3 segments, a 2 minute initial segment and then a 14 minute second segment captured by webhook were not returned by API
Meeting 56447xxxx - 10 minute initial segment captured by webhook was not returned by API
Meeting 17556xxxx - 25 minute initial segment captured by webhook was not returned by API
Meeting 42556xxxx - 54 minute FINAL segment captured by webhook was not returned by API
[There are 6 more of these from yesterday, but you get the idea]
Are these discrepancies something you’re aware of? Is it perhaps by design, where certain segments that provide a meeting.started/meeting.ended webhook pair are intentionally omitted from API results for some reason? And, most importantly, when the webhooks and API results disagree, which should be used as truth? So far it is looking like whichever method yields the longer duration is the one more likely to be correct.
We have similar issue, we observed webhooks are not reliable and we wanted to rely on absolute values via api. For multiple instances of starts instances of same meeting we need total meeting minutes and also participants total minutes by using this api https://marketplace.zoom.us/docs/api-reference/zoom-api/reports/reportmeetingparticipants. passing uuid gives specific instance details but getting uuids for a meeting it self we didn’t find solution @tommy can you helps us here
