Documentation Request: Zoom Settings that Block OAuth Recording Download

Description
I want to understand how the old and new settings that were added affect the ability of an Oauth app to download cloud recordings. I’m specifically interested in what variants of these settings exist so we can direct our users to fix their settings when an otherwise valid Oauth request for a recording is rejected. It is confusing right now because new settings were added and I’m not sure if the new settings replaced existing ones. And there are potentially up to five places now that will break an Oauth app (unless the old ones are gone now).

At some point, we might look into converting our app from Oauth to JWT so we can access the workaround that exists in that framework. But we don’t really want to do this and it’s my understanding that some or all of this difficulty will go away in Q3/Q4 when Oauth apps are given more privileges to access these recordings (per BUG downloading cloud recordings with access token set results in an invalid response)

HOW THINGS WORKED BEFORE APRIL

Before the most recent changes, an Oauth app would not be allowed to download a recording if the user had the following option disabled:

“Share Cloud Recordings Only with Members of my Account”

I have in my notes that this setting sometimes had a different label and would appear to some users as “Only the Host Can Download Cloud Recordings”

Are one or both of these settings still valid? Or were they renamed/replaced by the new settings?

HOW THINGS WORK NOW

There are now the following settings that might break Oauth downloads of a recording:

“Only Authenticated Users Can View Cloud Recordings” – Does this indeed break things for an Oauth app? Is this the replacement for the old “Only the Host Can Download Cloud Recordings” and/or “Share Cloud Recordings Only with Members of my Account”?

I suspect these 3 settings are all the same thing, right? Or do all 3 appear depending on different circumstances?


“Require Password to Access Shared Cloud Recordings” – This is the new one that broke stuff starting in April. And I know now that this setting only applies to NEW recordings. Existing recordings still need to have the password turned off individually via the “Password protection” toggle on the individual recording.

Will all these recordings also suddenly become accessible via Oauth in Q3/Q4 when things are fixed? Or will a password-protected recording always be inaccessible to an app?

Also… was there a workaround to this for Oauth (other than using JWT)? Is an Oauth app able to get the password and supply it somehow?


I notice there is also a toggle on each individual recording labelled “Share this recording publicly” versus “Only authenticated users can view”. Is this the per-recording version of “Only Authenticated Users Can View Cloud Recordings”? So, existing recordings might have this set to “Only authenticated users can view” and not be accessible via Oauth?

Also, there’s a per-recording setting called “Viewers can download”. What’s the effect of this?


I’m sorry to be asking so many questions but frankly, the new settings are very confusing. When a user installs our Zoom Oauth app, they explicitly give us permission to access their recordings. Our app then potentially cannot actually access their recordings and we have to show an error message to the user and explain what steps they must take in their account so that the app will work properly. But there are now numerous different settings in different places and I am trying to get a handle on which settings are relevant, what workarounds exist for these settings, and what exactly will be changing in Q3/Q4.

Thank you.

Error
Trying to get an understanding of when an Oauth app will not be allowed to download a recording

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

Which Endpoint/s?
Recordings endpoint. Fetching a list of “download_url’s”

Hey @debra,

If this setting is enabled or password is enabled, you will need to use the download_token in the recording completed webhook webhook, or a JWT token as a query param.

Please also see these support docs:

Thanks,
Tommy