There seems to be a race condition with recording registrant API endpoints.
We’re trying to invite certain members of our platform (that attended a meeting) to a recording via the Zoom API. However we’re struggling to properly leverage the API as it has some weird behaviour.
First we’re setting the settings for the recording to the appropriate settings so it can work with registrants, this works properly as we can see in the Zoom dashboard that the settings are correctly applied. When the recording is ready we add our members as registrants to the recording as registrants and approve them so they can view the recording (we don’t want users to be able to register themself, so everyone is added via the API). However we’re experiencing what seems like a race condition:
To set the registrants we call the endpoint (this can not be done in bulk, so has to be per user a call):
- (1) POST /meetings/{meetingId}/recordings/registrants
{
“email”:“<user_email>”,
“first_name”:“<first_name>”,
“last_name”:“<last_name>”,
“status”:“approve”
}
We do this for all our registrants and collect the registrant ID’s from the responses. The API specification mentioned that you can add the “status”:“approved” in this POST request (1) and then the registrant should be approved, however this doesn’t seems to impact the status of the registrant and it is still what it was before this request (i.e. denied or pending if newly created). As that doesn’t work for setting the status we set the status via the PUT registrant status endpoint:
- (2) PUT /meetings/{meetingId}/recordings/registrants/status
{
“action”:“approve”,
“registrants”: [
{“id”:“<registrant_id>”}
]
}
This gives an 204, indicating they’re all approved we thought, it also sends out an email to the registrant that they’re approved and can access the recording now (little do they know, as they can’t access the recording). When looking in the Zoom Workspace dashboard they’re not approved (well sometimes they are but 99% of the time they’re not). So we’ve build in an extra step to check who is actually approved, and see if it failed or not:
- (3) GET /meetings/{meetingId}/recordings/registrants?status=approved
This returns all registrants we wanted to approve (which should mean that these registrants are approved, and at the point of the request where approved in the Zoom system). However if we look in the Zoom Workspace dashboard they’re not approved. If we they call (3) again (a few seconds later), they’re also not approved anymore. It looks like after (1) Zoom starts doing some additional processing in the background, and finishes after (2) and (3) and overwrites back to the state of (1). If we wait 1 second between (1) and (2) the race condition is way less prevalent. Similar for between (2) and (3). We’re now adding some seconds of sleep, but this is very arbitrary and hacky, every time we see it going wrong we higher up the number of seconds to sleep . This can’t be best practice for the Zoom API, and I hope this is not the expected behaviour. Is there any way to fix this, or is there a workaround that is less hacky?