Erroneous status code from API

API and Webhooks
1

Description
We are facing this issue from today where we are getting erroneous status code from zoom.
The Updating Recording Registrant’s Status API (https://marketplace.zoom.us/docs/api-reference/zoom-api/cloud-recording/meetingrecordingregistrantstatus) returns 204 (which is success according to documentation). However, the approval remains in the pending state.
Surprisingly, the issue happens randomly when we are calling the API from our code as a step during a list of consecutive calls.
However, when we call it from postman as an individual call, it processes correctly.
It so happens that when we test it from code, if it fails it keeps failing randomly for a very large amount of time (the entire day for example). If it works it works for the entire day at times.

Error

  • Affected API:
    Updating Recording Registrant’s Status - https://marketplace.zoom.us/docs/api-reference/zoom-api/cloud-recording/meetingrecordingregistrantstatus
  • Sample Meeting ID: XXXXXXXXXX
  • Sample API URL: /meetings/ XXXXXXXXXX /recordings/registrants/status
  • Sample Request Object:
    {‘action’: ‘approve’, ‘registrants’: [{‘id’: ‘YYYYYYYYYYYYYYY’}]}
  • Response code:
    204
  • Issue:
    We are getting status code 204 which as per the documentation indicates - “Registrant status updated.”, which is a success in this case.
    However, the registrant is not approved when we check from our account on zoom.

Which App Type (OAuth / Chatbot / JWT / Webhook)?
JWT

Which Endpoint/s?
/meetings/{meetingId}/recordings/registrants/status

How To Reproduce (If applicable)
Steps to reproduce the behavior:

  1. Request URL - /meetings/ XXXXXXXXXX /recordings/registrants/status
    Headers - NA
    Body - NA
  2. See error - No error as such but the process doesn’t happen in spite of receiving success (204)

Screenshots (If applicable)
Not applicable. The details have been shared above.

Additional context
We have automated our flows since we have a huge volume.
Also, having manual approval set to “on” and approving only designated users help us secure our recordings.
It will seem very odd to see the approval pending message when students will click on the Play Recording button on our website. Also, it will be impossible for us to manually approve these.

2

Hey @gourav.ims,

Can you share your code snippet? I wonder if it’s a bug or edge case in your code.

Also please share your full request that is failing, including meetingID and registrant ID so I can debug.

Thanks,
Tommy

3

Hi Tommy,

We could in fact replicate this on postman as well.

Please go through following postman collection:
https://www.getpostman.com/collections/8858b8a160405e886424

The set of requests in this collection mimics our exact flow in code.
I have used the following environmental variables. I have also mentioned default/sample values.
webinarid: 929741871. This is one of the testing webinars. Please use your own webinar id which has a recording.
registrant_id: any initial value
share_url: any initial value.
registration_counter: 1

When we were trying earlier in postman, we were trying manually by calling 1st API (Create registrant) and then copying the required value manually and pasting that in the body of the next API (Approve registrant). The delay was sufficient to get the process done.

However, when we ran the workflow on postman using automation tests (to simulate our code) where the requests are sent back to back, it reproduces the bug.
The second API (Approve registrant) returns 204 (indicating success). However, when you check on the zoom admin account, the requests are in the pending tab. They remain pending and do not get processed ever.

We tried the following scenarios:

Iterations 1, delay none - bug reproduces - all remain pending
Iterations 1, delay 1000 ms - bug reproduces - all remain pending
Iterations 5, delay 3000 ms - bug reproduces - most remain pending
Iterations 3, delay 2000 ms - bug reproduces - most remain pending
Iterations 5, delay 5000 ms - bug is not reproduced and approval happens properly.

In code, we are sending the second request immediately after reading the registrant_id from the first request.
The documentation doesn’t mention any delay requirements.
Also, when we run the collection for 3+ iterations the delay above 3500 is working.
In the production environment, any adding even a second of forceful delay will affect the user experience negatively.

I hope zoom looks into this at the earliest.

Let me know if you still need to see our code since the bug gets replicated easily on postman.

4

Hey @gourav.ims,

I am guessing this is due to some async processes or due to the increased traffic on the Zoom API platform.

As a workaround, please add the delay, maybe in the background of your code so the user is not stuck in a flow.

No need to send your code I will talk with the engineers, I appreciate you debugging this further.

Thanks,
Tommy

5

Hi Tommy,

Thank you for confirming and sorry for the late reply.

We have implemented a delay of 3500 ms to be on safer side. So far it has been working.
As discussed earlier this is not an elegant solution since our loading gif is shown for 5+s because of this delay. Let’s hope the engineers come up with a fix and confirm to us here so that we can remove the delay.

Its crazy since we have gone live with zoom.
Some or the other issue has been happening.
I am about post another topic now. Hope someone like you posts a reply at the earliest.

6

Hey @gourav.ims,

Yes, please continue posting your questions.

Thanks,
Tommy

7

@gourav.ims, thank you for reporting this issue! We’re still running into the same issue.

@Tommy, please get back to use ASAP when this issue is fixed. This is a cornerstone to our way of addressing Zoombombing at Harvard and we cannot afford to put a 3.5s delay into each registration due to the sheer volume we’re working with. This is a showstopper for Zoom security for us.

Thank you.

8

Hey @abrams,

We are working to address this asap and I will keep you updated. (ZOOM-151205)

Thanks,
Tommy

9

@gourav.ims and @abrams

You could try this workaround…

  1. Subscribe to Recording Registration Created event
  2. Create recording registrant via the API.
  3. Listen for Recording Registration Created event to arrive, pipe data into next step…
  4. Trigger the Update Recording Registrant’s Status API call to execute (using the ID from the previous step’s event data)
  5. [OPTIONAL] Subscribe to Recording Registration (Approved/Denied) events (for verification)

This isn’t the prettiest workaround…but it should workaround the API-only issue you’ve identified, latency doesn’t matter using this approach (since you don’t have to block code execution to handle the latency). Then you can just subscribe to the Zoom API Changelog to see when this gets resolved and you can un-kludge the code from the workaround.

10

Hi @bdeanindy, thank you for the detailed workaround steps!

I have another solution that would actually help a lot: make a new add list of registrants endpoint. If we were able to register 20-30 people at a time, that would be epic. At that point, we could afford to wait the 3.5s for registrations to become active.

Is this feasible?

Thank you!

11

Hey @abrams,

We will look into the batch add registrants endpoint. You can do this on the Zoom Web Portal for Webinars with a CSV file, if that helps at all:

Can you private message me one of the affected meetingIDs so I can look at the logs for the delay issues?

Thanks,
Tommy

12

Hi @Tommy,

As for CSV upload, we are using meetings, not webinars. We cannot switch to using webinars because there are meeting features that we need.

I’ll send you a private message with a meeting id.

Thank you!

1 Like
13

Gotcha!

Thanks,
Tommy

14

Sorry, I could not reply earlier.
We did not get time to try and implement the method you have suggested since it will take quiet an efforts.
However, we have a strong feeling that this approach will not work.
The issue is not that the reply for the status update API or the approval is delayed. The API returns that 204 success and the request doesn’t get approved at all.
The issue is not even with registration API as well since the registration reflects immediately.

Apart from the above technical reasons, we also have an issue in implementing this approach.
We have a list of webinar recordings on visible on our portal where students can click to view. How and when will we open the recording URL for student using this non-blocking way?

15

How to subscribe for a particular issue only?

16

Hey @gourav.ims,

We are working to fix this.

Can you explain more? I do not understand.

Thanks,
Tommy

17

Basically, our flow is such that, students click on a play button to view the recording.
What @bdeanindy has suggested in his non-blocking alternative is not going to work from us because we cannot change our entire flow to a behavior where students request for viewing the recording and then they get the recording URL later.
We had assumed that the approval will be instantaneous (which actually are in most of the cases) so that we can redirect them to the recording URL immediately after they click on play.

18

Hey @gourav.ims,

Gotcha, once you receive the response from the Update Recording Registrant’s Status API you could display the recording for that user.

Thanks,
Tommy

19

Hey @abrams, @gourav.ims,

Are you still having this issue? If so, please share your meeting IDs and a link to this thread to developersupport@zoom.us so we can look at the logs.

Thanks,
Tommy

20

Honestly, we kinda gave up on this :stuck_out_tongue: We are working on implementing this for Fall.

Are there updates (is this bug potentially fixed)? If so, that would increase our chances of continuing to use this feature.