Download url format changed?

The download url format in ‘recording notification’ includes ‘/’ now after “webhook_download/”. eg.
2020-04-27 07:03:42 -07:00: Recording notification Body= { timezone: ‘Europe/Paris’,
2020-04-27 07:03:42 -07:00: recording_files:
2020-04-27 07:03:42 -07:00: [ { id: '------,
2020-04-27 07:03:42 -07:00: meeting_id: ‘------------------------’,
2020-04-27 07:03:42 -07:00: recording_start: ‘2020-04-27T14:00:04Z’,
2020-04-27 07:03:42 -07:00: recording_end: ‘2020-04-27T14:02:12Z’,
2020-04-27 07:03:42 -07:00: file_type: ‘MP4’,
2020-04-27 07:03:42 -07:00: file_size: 25879319,
2020-04-27 07:03:42 -07:00: play_url: ‘’,
2020-04-27 07:03:42 -07:00: download_url: ‘https://—’,
2020-04-27 07:03:42 -07:00: status: ‘completed’ },

Is it a bug or you are going to send url with '/'s??? Please let us know. This is breaking our code. We need to update our code accordingly. But, not all the the download urls received with ‘/’ though.

I have messaged actual log with full url to Tom ( Tommy Gaessler).


The url part after ‘/’ is always same for all ur customers: 98tyKvX2_------------------_b-----xZfXnlc-----_bZ56ir6Wh-Q

Looks like all the download url with /98…

Try with

recording.download_url = recording.download_url.Replace(“webhook_download”, “download”);
recording.download_url = recording.download_url.Substring(0, recording.download_url.LastIndexOf("/"));

Thanks. We could able to download with the received url as it is. No issues.

We are using the last part of url (after last ‘/’) to identify each files differently. It used to be unique all the time (last 1.5 years or so). Now all our customer’s url end with same string after last ‘/’. It creating lots of problems, We applied temp fix for this as of now.

We would like to know whether it is temporary or not. Will Zoom update the url in different format in the future without notice or not. Zoom may thinks that it is a small change. But it is affecting our entire products including it triggered some security issues. We fixed it though now.


Hey @cpineda, @selva.iyyamperumal,

We did increase the length of the download_url. Please see this page for a description of the update: