GET /report/Cloud_Recording API inconsistent results

Hello Zoom support community,

I know things have changed a bit since with the some policies within the Zoom API and I apologize in advance if I bring up an issue already mentioned elsewhere.

Description
I am looking for assist with a couple issues I am experiencing with the GET /report/cloud_recording API call.

I recently started collecting the data from this API and have found the follow issues:

  1. Missing results
    a. Some dates are completely missing from the results. Most recently 9/1/2020 is missing
    GET https://api.zoom.us/v2/report/cloud_recording?from=2020-08-31&to=2020-09-03

    {
    “cloud_recording_storage”: [
    {
    “date”: “xxxx”
    “free_usage”: “xxxx”,
    “plan_usage”: “xxxx”,
    “usage”: “xxxx”
    },
    {
    “date”: “2020-09-02”,
    “free_usage”: “xxxx”,
    “plan_usage”: “xxxx”,
    “usage”: “xxxxx”
    }
    ],
    “from”: “2020-08-31”,
    “to”: “2020-09-02”
    }

  2. Some results have from previous dates have new values for the usage. In the below case we see both the Plan_usage and the Usage are dramatically out of sync and seems more inline with our current usage. Values changed for security
    GET https://api.zoom.us/v2/report/cloud_recording?from=2020-05-10&to=2020-06-09
    {
    “date”: “2020-06-02”,
    “free_usage”: “10 GB”,
    “plan_usage”: “0”,
    “usage”: “2.25 GB”
    },
    {
    “date”: “2020-06-03”,
    “free_usage”: “10 GB”,
    “plan_usage”: “3 GB”,
    “usage”: “12.25 GB”
    },
    {
    “date”: “2020-06-04”,
    “free_usage”: “10 GB”,
    “plan_usage”: “0”,
    “usage”: “2.97 GB”
    },

  3. Is there any way to get higher precision on usage? 1.21 TB versus 1211 GB or 1211463 MB

  4. What calculation does your system use for TB, GB, etc? TB = 1024^ 4 or 1000 ^4?

Thank you in advance for any insight you might have,
Sean

Greetings!

One additionally question:

  1. What time should the [GET /report/Cloud_Recording] be available to return values from the previous day? I ran the follow call at 2:30 AM CT but did I only received data 9/6, not 9/7.
    GET https://api.zoom.us/v2/report/cloud_recording?from=2020-09-06&to=2020-09-07

Thank you,
Sean

Hey @sohling,

Thanks for reaching out about this—I’m more than happy to look into this for you.

First, regarding:

Some dates are completely missing from the results. Most recently 9/1/2020 is missing
GET https://api.zoom.us/v2/report/cloud_recording?from=2020-08-31&to=2020-09-03

Can I kindly ask you to confirm that there is definitely a recording for this date—are you seeing the expected recordings in the Zoom UI? If so, can you share a screenshot and let me know the corresponding meeting ID for the 9/1 recording you’re expecting to see, if possible?


In regards to:

Some results have from previous dates have new values for the usage. In the below case we see both the Plan_usage and the Usage are dramatically out of sync and seems more inline with our current usage. Values changed for security
GET https://api.zoom.us/v2/report/cloud_recording?from=2020-05-10&to=2020-06-09

I’ll be happy to escalate this to our team to get confirmation on whether or not this is expected—I’d just like to confirm the actual values are close to the modified ones included here?


As for:

Is there any way to get higher precision on usage? 1.21 TB versus 1211 GB or 1211463 MB

The current values returned via API (GB) mark our current level of precision. However, you make a great point that it could be helpful to have more detail here, and I’m happy to share this feedback. I’d also encourage you to consider posting this suggestion in our Feature Requests thread.


Fourth:

What calculation does your system use for TB, GB, etc? TB = 1024^ 4 or 1000 ^4?

I believe our system uses the standard of 1GB = 1000TB, but I am working on confirming this for you.


Lastly:

  1. What time should the [GET /report/Cloud_Recording] be available to return values from the previous day? I ran the follow call at 2:30 AM CT but did I only received data 9/6, not 9/7.
    GET https://api.zoom.us/v2/report/cloud_recording?from=2020-09-06&to=2020-09-07

This data should generally be available within 24 hours of the previous day.


I hope some of this information is helpful—regarding the missing recordings, I’ll keep an eye out for the additional details requested.

Thanks!
Will

Thanks @will.zoom,

(1)
The Zoom Admin dashboard shows 601 recordings on 9/1/2020 and here is a single page’s worth of

recordings.

One of the meeting UUID’s is ‘o9LQPu8GRCunmLzvb0bSyA==’

(2)
I will DM the you exact response to GET https://api.zoom.us/v2/report/cloud_recording?from=2020-05-10&to=2020-06-09.

(3)
Please do share my feedback and I will add a feature request. Thanks!

(4)
Thanks.

(5)
Ok, so no set time. Thank you. My API current gets the last two days and I will continue to do that as it will update if it changes.

Hey @will.zoom,

Not sure if this is the correct way to DM, but we will try.

Regarding (2) in the post: GET /report/Cloud_Recording API inconsistent results - #4 by sohling

Below is the response from the API call: GET https://api.zoom.us/v2/report/cloud_recording?from=2020-05-10&to=2020-06-09.

I have bolded three instances where the usage is significantly higher than when I originally pulled the data.
Original values (as stored by an ETL process here at Loyola:

  • 2020-05-26 7.27 TB
  • 2020-05-27 7.35 TB
  • 2020-06-03 7.86 TB

Thank you for reviewing,
Sean

{
“cloud_recording_storage”: [
{
“date”: “2020-05-10”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.54 TB”
},
{
“date”: “2020-05-11”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.58 TB”
},
{
“date”: “2020-05-12”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.62 TB”
},
{
“date”: “2020-05-13”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.67 TB”
},
{
“date”: “2020-05-14”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.72 TB”
},
{
“date”: “2020-05-15”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.76 TB”
},
{
“date”: “2020-05-16”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.79 TB”
},
{
“date”: “2020-05-17”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.82 TB”
},
{
“date”: “2020-05-18”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.88 TB”
},
{
“date”: “2020-05-19”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “6.95 TB”
},
{
“date”: “2020-05-20”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.04 TB”
},
{
“date”: “2020-05-21”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.11 TB”
},
{
“date”: “2020-05-22”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.14 TB”
},
{
“date”: “2020-05-23”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.13 TB”
},
{
“date”: “2020-05-24”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.14 TB”
},
{
“date”: “2020-05-25”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.16 TB”
},
> {
> “date”: “2020-05-26”,
> “free_usage”: “10.79 TB”,
> “plan_usage”: “3 TB”,
> “usage”: “15.33 TB”
> },
> {
> “date”: “2020-05-27”,
> “free_usage”: “10.79 TB”,
> “plan_usage”: “3 TB”,
> “usage”: “15.33 TB”
> },
{
“date”: “2020-05-28”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.44 TB”
},
{
“date”: “2020-05-29”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.49 TB”
},
{
“date”: “2020-05-30”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.52 TB”
},
{
“date”: “2020-05-31”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “8.2 TB”
},
{
“date”: “2020-06-01”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.63 TB”
},
{
“date”: “2020-06-02”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.75 TB”
},
> {
> “date”: “2020-06-03”,
> “free_usage”: “10.79 TB”,
> “plan_usage”: “3 TB”,
> “usage”: “15.01 TB”
> },
{
“date”: “2020-06-04”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “7.97 TB”
},
{
“date”: “2020-06-05”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “8.01 TB”
},
{
“date”: “2020-06-06”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “8.04 TB”
},
{
“date”: “2020-06-07”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “8.05 TB”
},
{
“date”: “2020-06-08”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “8.15 TB”
},
{
“date”: “2020-06-09”,
“free_usage”: “10.79 TB”,
“plan_usage”: “0”,
“usage”: “8.25 TB”
}
],
“from”: “2020-05-10”,
“to”: “2020-06-09”
}

Thank you,
Sean

Hi @sohling ,

Thank you for getting back to me with these details.

Regarding point 1, our team is looking into this. (ZOOM-197288).

Regarding point 2, our team is also looking into this. (ZOOM-197291).

Regarding point 4, I’m still waiting for confirmation on this!

Thanks, and I’ll be in touch as soon as I have some updates.

Best,
Will

Thanks @will.zoom,

Looking forward to working with you and your team as they get to debugging/resolving this.

Sean

Hi @sohling,

An update for you—regarding point 1, our team has recommended that the following endpoint is best for your use case, and should give you results that align more with the screenshot you’ve provided in the UI:

Regarding point 2, I’m still looking into this.

Regarding point 3, we recommend the standard conversion of 1 Terabyte is equal to 1000 gigabytes.

Thanks, and I’ll be in touch regarding point 2.

Best,
Will

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