We made changes to our logic that determines when to send requests to the Zoom API. We did not change anything related to our Zoom client, or authentication.
For each request we send to the Zoom API, we first request a new token, then send our request using that token. The authentication request succeeded, yet our request to the registrant endpoint got 401 Unauthorized with an error code of 124.
This support article recommends submitting a Support request. (The Support ticket system is no longer in operation, which I only learned after writing up a full ticket.)
Unfortunately, we do not have an active staging environment, and these errors led to downstream data issues in our system, so I’m very wary of merging in the faulty code until we have a better idea of what caused these errors.
Thank you for posting a Zoom Developer Forum. Based on the error it looks like you are using are invalid access token when hitting the registration endpoint. Can you clarify if you were using a server to - server APP type? It seems like there you may be making a subsequent access token request, which may be invalidating the token making the request to the registrant endpoint.
Yes, this was made server-to-server from a recurring task. However, I think the registration request immediately followed the auth token request. Here are screenshots from our error-tracking app. (The top one is the auth request, and the second is the failed registration request.)
These happened very quickly, and we only run one of these jobs at a time. Could it be something else?
Also, good news is that we had major data error when this job ran; at first I thought it may have been related to the failed Zoom request, but it turns out it’s from another part of the app. So this error is now much more benign! (I still want to understand why it happened and what we can do to prevent it, though.)
Thanks for the additional context. It sounds like the behavior may have been a by-product of the major data error you mentioned. Is that accurate? Generally, I see the “Invalid access token ” when making subsequent to get an access token. This is because each time you call to get an access token, it invalidates the previous access token that was issued. To prevent this, you can submit a support request to increase the index tolerance, you will be able to generate tokens at different indexes so the tokens won’t get invalidated. Here is the post with more details on this topic you can check out :
Thank you again for your help! We have to hold on re-implementing this functionality for at least another week. It probably is related to our internal data issue. If we still have this problem, I will reach out. And thank you for sharing the other thread!