Erroneous status code from API

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.