Recent Issues and Improvements to the Web SDK

As usage surged over the last few months, the Web SDK has faced a number of reliability issues, bugs, and security changes that impacted usage and experience. We would like to take this post as an opportunity to address those issues earnestly and detail the path forward.

As developers ourselves, we understand the importance of reliability, smooth versioning, and the pain of unplanned breaking changes. We also know we can be more proactive with our direct communication. If you haven’t already done so, make sure you add your email to the Developer Contact information to the “Information” page of your JWT App. Find more information on our Stay Up To Date docs.

Black Screen in 1.7.8 - Resolved

With the release of 1.7.8, a number of users and developers reported an unexpected black screen rather than their video appearing. This affected versions 1.7.8 and 1.7.9.

Main thread: Possible Bug with video streaming

This issue was difficult to reproduce universally, so while bug fixes were released in 1.7.9, some users did continue to see intermittent black screens on join. After further testing and direct help from community developers to reproduce, we identified the issue was caused by a throttling of user role assignment during join. If the user role returned too quickly or out of order, the active video component was not mounted.

With the release of 1.7.10 we’re confident this issue has been fixed. If you have any reports of users facing this issue, please do let us know.

reCAPTCHA in 1.7.9 - Opt out available

In version 1.7.9, the Web SDK added support for the Zoom Web Client’s inclusion of reCAPTCHA in the user join process. We hear you - this added an inconvenient additional step for your end users.

Main thread: SDK 1.7.9 - Recaptcha feature documentation

This decision was made to ensure that any user joining via the web client is an intended participant, and we stand by that goal. We’ve implemented a new identification strategy on the Web SDK join process to better understand when reCAPTCHA does need to be triggered. Our goal is for you to provide the most frictionless join process possible, but there may be some scenarios where an end user is prompted by verification.

Currently we’re not releasing what these exact conditions are, but most end users will not see a reCAPTCHA check.

Opting out of reCAPTCHA

If you would like to opt out of reCAPTCHA, fill out this form and reCAPTCHA will be removed from all meetings held on your account (this is tracked via API Key). Please note this is not a full guarantee we will approve removing it for your account, and we may ask additional questions.

Note: This post will be updated with any on-going issues facing the Web SDK. The two issues above are not meant to be an exhaustive list.

As of 07/15/20 there are also some reports of audio quality issues we are working to resolve. I’ll update this post with full information.

Upcoming changes & improvements

As we come out of our 90-day feature freeze and security prioritization, we’re dedicating our engineering effort to releasing a number of long-awaited improvements to the Web SDK. Check out our Developer Roadmap for additional releases; however, there are a few high-priority items we know you’re looking for which we’re working hard to release:

  • Webinar Hosting (1.8.0; end of July): Webinar Hosts and Panelists will be able to join a webinar.
  • Webinar Registration (1.8.0; end of July): SDK join methods will support joining webinar participants from registration links.
  • 720p Video (short-term roadmap): Increasing video quality is a high-priority improvement; however, this improvement will come when we can guarantee a high standard of in-meeting quality and reduced CPU usage.
  • Gallery View (short-term roadmap): Allowing for multiple high-quality video feeds is a resource-intensive operation within a browser, thus it is not yet available - but we’re working to optimize and release this in the short-term.

The future of the Zoom Web SDK

The Web SDK was initially designed to allow you to put the Zoom web client into your own web app. It was not designed to be building new video products. That’s probably understandable if you’ve tried to do this. Customizing, embedding, and wrangling the SDK into unique video products can - and will - be improved.

As we become a tool on which the entire world connects, we’re committed to be the easiest platform for you to build new apps which do the same. We’re dedicating resources and engineering effort to improving tools, libraries, and your developer experience. In this thread, I invite you to tell us what you want and show us what we can improve.

We don’t take your frustration lightly, and apologize for any bad experience caused by unexpected issues with the Web SDK. As we grow, we’ll continuing to learn and improve. Let’s build together.

– The Zoom Developer Relations Team

As a plug, if you want to join a diverse, energized team dedicated to connecting the world, we’d love to have you join us:



Could you please answer my question from here:

  • what is your policy regarding ‘account blocking’ after bad password inputs? Do you block accounts on websdk key level?

thx in advance

Hi @harald.glanzer, cross posting from your other thread:

I’ll DM you to better understand your use case and implementation.

Thanks for posting this. I hope you welcome some feedback. I hope it does not come off as negative or offensive.

Here are the biggest issues that we faced when attempting to integrate… First of all of course browser compatibility with FireFox and IE Edge is a problem. I’m not sure if it’s been addressed yet?

Second part that is a big deal is that “Q&A” popup becomes empty if it’s closed by accident.

Third part is missing polling component, entire company was complaining about it when we tried web embedding Zoom.

Given so many problems we just did a reverse integration, where we let Zoom handle the registration and have people get their individualized join links by email. We just pull reg data from API into our platform. However this only gives us a fraction of functionality that we wish and keeps us limited.

In reality WebSDK is a resource that could really open up a lot of room for cool things. If this thing had all issues sorted out then it would be easy to make proprietary web streaming events that people could make money from and in turn expand their Zoom accounts for bigger capacities, resulting in more revenue for Zoom.

Just from stand point of of events business, i saw whole array of platforms (during product demos) just using Zoom links for commercial agendas instead of full embedding of WebSDK. And most feedback was just “their web platform is not very reliable”.

Again, not trying to be offensive, just sharing problems we’ve had.

1 Like

one question, when we can join the IOS APP with Google Chrome browser, not launch zoom APP ? Android platform has been working fine, but IOS not really. still look forward to …

Thank you for your feedback @anton.skvortsov! :slight_smile:

We will use this to improve the Web SDK.


1 Like

Hey @chungjordan,

Are you referring to joining meetings with the Web SDK on iOS?


@michael.zoom Are there any details in what the fully customizable Web SDK entails? I have a bunch of asks for what I’d like to see out of a Web SDK, but many/all of them might be taken care of by a more customizable SDK.

Some examples:

  • Hooks into events, e.g. “participant is in waiting room” or other connection/disconnection events
  • Programmatically lock a meeting (especially in response to an event)
  • Customizable UI, e.g.
    • only have an “end meeting” button
    • choose how to display the “participant is in waiting room” modal
    • overlay connection quality somewhere in the UI, maybe next to the participant’s name
  • Auto-join audio (I believe auto-joining video already happens, albeit after a few seconds delay)
  • Clearer error messages, e.g.
    • when I leave a meeting (but do not end) and then, within a few minutes, host and join a new meeting, I get “Failed to join meeting.” with no other information. But if I end the earlier meeting, there is no error.
    • while implementing the signature generation code, the error message for a bad signature was simply “Your connection has timed out” (paraphrasing). adding a debug flag with detailed errors would be helpful

Other features my company would like:

  • Higher resolution video
  • Virtual backgrounds
  • Unminified source code so that if an error message is unclear or some other behavior isn’t matching documentation, I can set breakpoints and debug much more easily
    • I get that this not be acceptable, but I can’t stress enough just how much pain this would alleviate. I have to bug support far more than I would like simply because I can’t debug anything myself.

All of that said, I want to express some gratitude to the support team. I can’t imagine the massive strain all of you are under during COVID, so I appreciate that you’re all working hard to help us and that you’re open to feedback.

EDIT: Another suggestion: some way where I can test the Zoom window through Continuous Integration. I don’t mean to test Zoom itself, but I would like to test my customizations that surround Zoom (e.g. the leaveUrl). I want to use a fake meeting (to avoid rate limits and external web requests), and I don’t really need a video feed. Though simulating a participant joining could be helpful.

Hey @abiyani,

Thanks for sharing your interest and suggestions around this. :slight_smile:

If you have any more, feel free to add them as a feature request here: #feature-requests.

We will defiantly share more about the customizable Web SDK in the near future.