API Get Recordings
Dev zoom url → path: docs/api/rest/reference/video-sdk/methods/#operation/recordingGet Description
I’m thinking if it’s possible to fetch recordings based on session_name. The reasoning for this is the following:
On a normal call I only create one session_id.
On a different call but both users left the room and then rejoined later, I saw that zoom creates a new session_id but with same session_name as I defined previously but adding a session_key with my previous session_id. The part that zoom creates a new session_id and I only get notified at the frontend leaves me with my DB unsynced.
Right now I’m having a hard time for this scenario to keep my DB in sync, if I could query recordings based on session_name that should solve all of my issues.
Or if you have a way to solve this I’m all ears.
You can use client.getSessionInfo().sessionId to get the sessionId and sync that with your database. You can see an example of this in our Telehealth sample app. We store all different sessionIds for a single “session name” in the database. We can then query those recordings using the API.
This is not something I would recommend since we rate limit the API but you can also query all sessions and recursively get the recordings as a last resort. Link to code
Actually, it would be a significant lift for us to implement option #1, as all we’re trying to do is avoid closing the session on a simple browser refresh. We’re hoping to increase the call threshold for a couple of minutes after the session ends, rather than immediately destroying it, similar to the “EmptyRoomTimeout” parameter from Twilio twilio-dot-com/docs/video/api/rooms-resource#request-body-parameters-1
Implementing this threshold would be extremely helpful for cases where the user refreshes the page or briefly disconnects without requiring a full session reinitialization.
Hey @alanc I understand your use-case, but this isn’t supported at the moment. The recommended way to keep sessions alive is by adding a linux client to the meeting, which again wouldn’t be ideal for what you’re trying to do. It would require some engineering effort still.
I’ll check with the product team if we can add a timeout wait feature to the roadmap, but it’s not a supported use-case at the moment.