Problem / AccessDenied on Downloading files from a WebHook event

Currently experiencing issues when trying to automatically download recordings after a webhook event (“event”: “recording.completed”)
We automatically used the
“download_url”: “https://XXXXXXXXXXXXXXXXXXXXXXXXXXX/”,
to pull back the recording.

now getting a

<?xml version="1.0" encoding="UTF-8"?>AccessDeniedAccess denied

This was working properly over the last week, but seems to have changed in the last 12 hours (guessing updates w/ LOAD on zoom).

From the DOCS, I see they now have a spec for
authorization: Bearer {download_token}

Do we now need to use a JWT token to download the files ? Client_ID / key or something to form an authenticated request?

Please advise, any suggestion / updates to DOCs would be appreciated, as currently not working and we have a university waiting to give green light on process.

I’ve tested this both on my PRO account as well as against an University instance.

To Reproduce(If applicable)
Steps to reproduce the behavior:
Try and download a file listed in the
“recording_files”: [{
“id”: “GUID”,
“meeting_id”: “SYSYSYSYYSYSYSY”,
“recording_start”: “2020-03-22T15:55:44Z”,
“recording_end”: “2020-03-22T15:56:42Z”,
“file_type”: “MP4”,
“file_size”: “1962489”,
“play_url”: "XXXXXXXXXXXX,
"download_url": “XXXXXXXXXXXXXXX”,
“status”: “completed”,
“recording_type”: “shared_screen_with_speaker_view”
} ]

  1. See error

    Screenshots

If I try and use the JWT Token but still getting
Authentication Bearer Token I get the following error in a Postman GET
{
“status”: false,
“errorCode”: 401,
“errorMessage”: “java.lang.NullPointerException”,
“result”: null
}

Any updates / suggestion to get success in automating downloads ? can this be done as a JWT app ?

We have the exact same issue since about 7 hours ago.
Anyone has a temporary workaround?
We’ve already opened a ticket on behalf of the Open University of Israel but no response yet.
This is a critical issue - can someoneat Zoom please investigate and escalate ASAP?
Thanks.

Hey Tom,
So I’m not sure if this is NEW doc or not (don’t remember seen that in the past) they have additional information at
(Can no longer find the documentation link)

but if you add
?access_token={YOUR_VALID_JWToken}
to your “download_url”
as a querystring parameter it will start working again.
My initial Bearer attempts where not working. but this works for now…

Hoping we get updates if the APIs see more changes.
Good luck

1 Like

Thanks Nicolai!
This solution is working for us…
Zoom definitely need to improve their API update notifications, this isn’t the first time…
Good night,
Tom.

1 Like

Glad it’s working for you as well.

Agreed on docs and any changes / updates to APIs and WebHooks, though I also appreciate these are pretty extenuating circumstances.

Let’s just all Pay it forward on the community forums, there is probably lots of people bashing their heads against the wall and I can only image how flooded support is at this point, so let’s all help each other out !

1 Like

Hi @Nicolai/@tomkl,

We’re glad that you were able to get it working! We do have the ?access_token={download_token} listed within our Recording.completed reference docs[1], was it hard to find or just overlooked? We’re asking because we want to make sure our developers are able to easily find what they need within our docs without having to spend more time answering questions.

1 - https://marketplace.zoom.us/docs/api-reference/webhook-reference/recording-events/recording-completed

Thanks

Hi Michael,
Our main concern is that it was not necessary to use the token this way prior to yesterday.
A change was made by Zoom yesterday which made our old method of downloading records obselete.
We were not aware of this change and apparently, other users were not aware as well, so I guess that the notification of API changes is something we hope will be executed better in the future.
Thanks,
Tom.

As @tomkl indicated, it was more that the API spec changed w/ no notification, since it was working with no tokens most of last week and then suddenly stopped.

I’m not sure if that was a new addition to doc or oversight on my part, however yesterday, I saw the token documentation once, and then went back to find it again and couldn’t …
so not sure if there are different versions of docs, or it being edited.
Exceptional circumstances.

All good for now.

Hey @tomkl, @Nicolai,

We are aware of the issue and looking into if anything on the Zoom side affected this change. (ZOOM-146185)

For now, the work around is to add your JWT Token to a query param to the download_url and not use the authorization bearer header:

$access_token=JWT_TOKEN_HERE

Thanks,
Tommy

Hey @tommy is there any status update on this or ETA when this will be fixed?
And what would be a workaround for users with OAuth access token?

Hey @tkrevh,

Unfortunately no ETA yet as the release was delayed.

For OAuth work around, use the download_token in the recording completed webhook.

Thanks,
Tommy

Hey @tommy, I totally missed that, this is really helpful, thank you so much!

1 Like

Hey @tkrevh,

You are welcome! :slight_smile:

Thanks,
Tommy