Getting read timeouts when calling oauth refresh token endpoint (Please let me know how I can get paid support if possible)

If there is a way we can get immediate paid developer support please let me know how and the pricing. Some of the problems we’ve been experiencing the past 2 weeks after a year with no issues could be catastrophic to our business.

We are making API calls to
and occasionally getting read timeouts.

Because this is an essential endpoint needed to keep our access tokens working, when we don’t get response, it completely breaks the application for the client and all their users.

We only make calls to this endpoint from a single thread, so this is not a problem with us receiving an invalid refresh token. We are just not getting a response from Zoom.

I can provide timestamps of when this has happened, as well as the request data and headers.

There is no error, our background process hangs awaiting a response from the zoom api.

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

Which Endpoint/s?

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

  1. Send request to
  2. No response received

Additional context
Here is our code:

        HttpRequest postRequest = HttpRequest.newBuilder()
            .uri(URI.create("" + refreshToken))
            .header("Accept", "application/json")
            .header("Authorization", "Basic " + authHeader)
            .build();"Retrieving new access token, credentials={}, refreshtoken={}, authheader={}", credentials, refreshToken, authHeader);

    HttpClient httpClient = HttpClient

    HttpResponse<String> response = httpClient.send(postRequest, HttpResponse.BodyHandlers.ofString());"refreshAccessToken response={}", response.body());

The final logging statement never executes and our process hangs due to no read timeout currently set (since we have a connect timeout we can be certain an initial connection is established but a response is never received).

Since we never receive a response, we aren’t able to persist the new access token / refresh token pair. All subsequent attempts to make any requests with the previous access token or attempts to refresh for a new access token then fail.

I’m able to provide the timestamps, access tokens, and refresh tokens this has happened for. It happens very rarely but having to make the client re-authorize the app during a live conference is very problematic for us. Thanks for your time.

Update: This could be due to our async logger’s ringbuffer filling up and blocking the rest of the code from continuing. Still investigating, if someone at Zoom could still confirm that the above endpoint hasn’t had any issues with response times that would be immensely helpful for us.

Thanks for your time.

Also: Information for obtaining paid developer support would also still be extremely helpful for us.

4:27 pm Update: Still observing the issue after disabling other processes using the same async logger, suggesting it may still be a lack of response from the api.

When did your issues start? I’m trying to track down a similar issue that seems to have started earlier this week, potentially around April 5. I’m using JWT instead of OAuth and I’m seeing intermittent errors like “failed to open stream: HTTP request failed” and “SSL: Handshake timed out”.

Our issues also started this past Monday.

I can also confirm it’s not a logging issue on our end. We are getting huge response times or no responses in some cases and they are occurring more fequently. I’ve added timeout handling and we are now getting timeout exceptions for some requests to the refresh endpoint.

If we wait for the request, it never finishes. If we set a timeout for the connection and make a new request to refresh, the refresh token has already been invalidated and we have never received it.

Would also like to add that we are experiencing the same issues people are experiencing here:

Increasing the tolerance limit for our account would help us immensely.

Yeah, the OAuth token refresh process is going to be even worse because you need the requests to succeed.

I ended up adding three layers of checks, because I’m seeing two different kinds of timeouts and some incomplete responses (truncated JSON). @tommy @shrijana.g Did something change with the API backend or perhaps load balancing within the past week? I don’t see anything on the API Changelog.

EDIT: Hmm, this might be an issue with our data center, because I can’t reproduce the issue when connecting to the API outside of our datacenter. Sorry @s27_zoom I may have used your post to reinforce my own confirmation bias.

Hey @s27_zoom and @Jonathan_Champ,

Thank you for reaching out to the Zoom Developer Forum.

We are working to roll out paid developer support in the near future and will make an announcement when it’s available. For now, you are encountering critical issues or need immediate assistance, the best option is to email us at Doing that will create a ticket with us where we can investigate issues directly.

Along those same lines, please send an email to with a link to this thread. In that email, please include those details. I’ll investigate the issue further and reach out to our engineering team to see if they are able to offer any insight.

This is something we can look at but I want to make sure that we resolve the issues with the timeouts and then make sure that we cover our bases when it comes to reducing invalid tokens before moving to increase the tolerance.

Please also send an email to with any relevant information you’ve been able to gather about the issues. I’ll investigate this and confirm if it’s related to the issues that @s27_zoom is encountering.


Hi @MaxM,

We stopped seeing connection issues Saturday afternoon. We do believe it was a localized issue because we were not seeing the same issues when using systems outside of the affected datacenter. I’m not exactly sure why it’s working now, but I suspect that our colocation provider fixed something that was causing packet loss. Sorry for diluting this discussion.


Update from us:

We’ve observed the exact same behavior as @Jonathan_Champ it sounds like and the last instance of the problem occurred at April 10th, 2:35pm Eastern for us.

We were not able to test outside of our datacenter, but attempts were made from from different ip addresses from the same VPC and the problem still persisted. We are using a datacenter based on the east coast for reference.

1 Like

Hey @Jonathan_Champ and @s27_zoom,

Thank you both for the updates.

@s27_zoom The only change on our end from April 10th was an update to the Web Backend. My understanding is this would be separate from the OAuth system but it’s possible a change there fixed the issues you saw.

However, based on what @Jonathan_Champ reported, this was most likely related to an issue at the data center, ISP or backbone network level. If you’re not seeing this issue any more, it’s hard to say.

Let me know if you encounter any further instances of this and we’ll investigate it right away. Your best bet is to send an email in to if the issue is urgent.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.