Call Recordings with the Phone API

Hello, we are having an issue figuring out how to download all recordings for a call from start to finish. We are not using WebHooks right now, only the Phone API. Our workflow is something like the following:

1- Get the account call log for the last 6 hours (and we keep moving forward the sliding window), taking note of the calls we already analyzed(completed calls).

2- Get the recordings for each completed call

My questions are, without using webhooks.

  • How do we know if the completed call has a recording before downloading it? An announcement says the field has_recording is deprecated and is not even shown in the accountCallLogs operation (but is still shown in the json results).

  • In case there is a recording, how do we know if it is available for download?

    • How to download the recordings using the Phone API? Something like the download_url field if we used the webhooks!

I appreciate any help you can provide.

Is anyone from support at Zoom here?

Hi @jose
Thanks for reaching out to us
To be able to get call recordings you could benefit from our Phone API endpoints
You could use the Get/users/recordings endpoint

Regarding your questions, if you are not leveraging webhooks, you would have to wait some minutes to have the recordings ready, unfortunately, we do not have a set time on how much it will take for a recording to be completed and ready to query.
And yes the has_recording field has been deprecated.

Is there any endpoint to get the call recordings from the whole call, from start to finish?

So, if the has_recording field is deprecated, how do I know in advance if the call has a recording? this way I would not even try to download it.

Hi @jose
We do not have an endpoint to query the specific call recording for a specific call, but we do have webhooks that would suffice this scenario, which is the phone.recording_completed that will let you know when the recording is ready to download and you will also get the download_url in the payload

Yes, I know that if I use webhooks or websockets notifications, I can get notified when a recording is complete. Still, for cases when the call does not have a recording, I cannot wait for the notification to publish the call. If I get a notification that the call recording is complete, I can be sure that the call has a recording, but if I don’t, how do I know if the call has a recording? In this case, the has_recording field was handy.

My workflow is like this:

When a call finishes, I get the call log (pooling every 10s this endpoint: /phone/call_logs), analyze the call, and:
1- if the call does not have a recording, I will publish the call ASAP to our systems
2- If the call has a recording, I wait for the recording to be available for download, download the recording, and publish the call to our system.

Any suggestions?

Hi @jose
I see what you mean.
I do not think there is a workaround for this if you are not using webhooks, you will have to call the phone/call_logs endpoint and implement the workflow you are currently using/or have in mind

Thanks for the answer, I am wondering what was the decision behind the removal of that field: has_recordings

Thank you @jose
Unfortunately, I am not aware of the reason behind this decision, but I can look internally to see if there is any information available, and if so I will get back to you

One last question: what is the API call to download a recording based on the recording_id? I cannot find any in the documentation for recordings!

What endpoint are you talking about? to download phone recordings, you just need user_id

When I call that endpoint with my the user_id coming in the call log, I got not recordings

what about if I use this endpoint: /phone/call_logs/{record['id']}/recordings
I found this in the forum but I cannot find it in the documentation!
Here is the forum link: https://devforum.zoom.us/t/change-in-phone-api-call-get-recording-by-call-id-file-url-no-longer-listed-in-documentation/93107

Hi @jose
Sorry for the late reply here
I can not find the endpoint you are mentioning here, but after reading the thread you shared, it looks like the endpoints are in beta so they are still private