"Get meeting recordings" endpoint does not return all recordings if a meeting has been interrupted and restarted

I have a meeting which has been interrupted and restarted (this is a one-time meeting, not an occurrence of a scheduled meeting).

The Zoom UI shows multiple sets of recordings, corresponding to each segment of the meeting (i.e. each time it was started), but only the recordings for the last segment are returned by the “get meeting recordings” endpoint in the API.

I gather from reading other postings on this forum, and some of the documentation, that Zoom creates a new “meeting instance” each time the meeting is started, and the UUID for each instance can be used to retrieve the recordings. However, the “list past meeting instances” endpoint returns only one instance for this meeting, so I cannot use the UUIDs to get any of the other recordings.

How do I get the list of instances so I can fetch all recordings? Or, how do I get all the recordings for this meeting ID, rather than just the latest set?

Hi @stephen-isc
Thanks for reaching out to the Zoom Developer forum and welcome to our community!
Allow me to do some testing on my end, I am going to try and replicate this behavior
I will come back with an update shortly.

Hi @stephen-isc
I did some testing on my end and I was not able to replicate this behavior.
When I called the endpoint Get past meeting instances, I was able to get 2 uuids for each time I started the meeting and using those uuids I was able to query the recordings.

Can you please confirm that when calling the endpoint Get past meeting instances you only get one meeting UUID?

Yes, I can confirm that - I’ve just tested it again.

I created a meeting using the account I am posting this message from, with the ID 85946448708, joined it, left it, and joined it again, and the endpoint returns the following:


The meeting definitely stopped and started again, but I only see one instance in the list returned.

We originally saw this problem with meeting 83074110964, and that for some reason now returns no instances at all (just an empty array).

@elisa.zoom has there been any further movement on this?

Sorry @stephen-isc
I did not get a notification for the previous message.
I just took a look at both meetings and I can see that both have 2 instances, you should be getting an array with 2 objects, one for each instance.

Can you please try again and confirm that this is just getting you back 1 instance?
Can you also share the entire request URL you are sending

@elisa.zoom I am making a GET request to the following URL: https://api.zoom.us/v2/past_meetings/85946448708/instances (using cURL), with a bearer token in the Authorization header.


curl https://api.zoom.us/v2/past_meetings/85946448708/instances -H "Authorization: Bearer eyJzdiI6IjAwMDAwMSIsImFsZyI6IkhTNTEyIiwidiI6IjIuMCIsImtpZCI6IjY0OGFmZDliLTBhM2QtNGIzZS05MGIxLTQ3OWZkYjM4MDRhMiJ9.eyJhdWQiOiJodHRwczovL29hdXRoLnpvb20udXMiLCJ1aWQiOiJZR0pGblB4WlN3aXMyc1pUUDg1eVB3IiwidmVyIjo5LCJhdWlkIjoiNGQxMDUwMmFhMzQyMWFiNjdiZjFkMDIzODFjMTMwZTAiLCJuYmYiOjE2OTI3MTgyNzEsImNvZGUiOiJZTFpPcENUcVQtdUJUVnZHQjlONElROFBWdjNvUUF1T0EiLCJpc3MiOiJ6bTpjaWQ6Wm14b2tObE9SdXVQTzZ3cllibkdTUSIsImdubyI6MCwiZXhwIjoxNjkyNzIxODcxLCJ0eXBlIjozLCJpYXQiOjE2OTI3MTgyNzEsImFpZCI6Ik40c3BGaHF0UmsyaUJ0ZDg4aHl1aXcifQ.xOShBXvSxvdNA5jkMFZrf1DVH58uJoM8rS4t-uuMclivbqXQaSZqnVJB05M3pDw_8zFb6ETqZWg7RVUm11Qdhg"

Returned data:


I haven’t actually tried doing this from code yet - since it didn’t appear to return what I expected when I tried it from the command line, I went and asked this question before doing any more towards implementation.

Hi @stephen-isc
I can see on my end that the meeting 85946448708 has 2 instances, which is interesting that is only returning one. I will send you a private message so you can share with me more details about this and I can look further into this

Updating this public thread, it looks like this report was a mistake and the Get meeting recordings endpoint is working as expected

That’s not quite what I meant: the report of two instances producing a single recording was incorrect. The report that the endpoint is not working right is still very much correct.