Three Zoom Meeting SDK web samples, three different integration shapes

One SDK, three shapes of integration

The Zoom Meeting SDK for web embeds meeting and webinar experiences into a web application through a WebAssembly module, and this repository is the sample set for it. The interesting part is that the repository does not contain one implementation but three, and the README frames the choice as picking your implementation rather than configuring one. The Components build uses React with TypeScript and Vite, runs on port 3000 and gives you the Component View. The Local build uses Vite 8 with Oxc and npm, runs on port 9999 and gives you the Client View. The CDN build uses vanilla JavaScript with Vite 8 and a CDN, also on port 9999 with the Client View. The published version tags, v6.5.0 from 2026-09-17 and v6.2.0 and v6.1.0 from 2026-07-08, track the shared SDK version rather than a single app.

Getting the sample running in five steps

The quick start is explicit. You clone the repository and move into it, then choose a directory, install dependencies with npm install, set up the auth backend, and start the app:

git clone https://github.com/zoom/sample-app-web.git
cd sample-app-web

cd Components    # or Local, or CDN

npm install

The auth backend is a separate repository, cloned with a shallow depth, and its .env.example is copied to .env so you can put your credentials in:

git clone https://github.com/zoom/meetingsdk-auth-endpoint-sample --depth 1
cd meetingsdk-auth-endpoint-sample
cp .env.example .env

The .env file takes either a CLIENT_SECRET or a ZOOM_MEETING_SDK_SECRET, and the backend is started with npm install and npm run start. The sample app itself starts with npm start, and the browser then opens the Components build on port 3000 or the Local and CDN builds on port 9999, where you enter a meeting or webinar number, a passcode and a role of Host or Attendee before clicking Join. There is a note for Node.js 16 users to use npm install --force.

Client View and Component View are not interchangeable

The two SDK views decide how much of your page the meeting takes over. Client View displays the Meeting SDK as a complete interface, giving the same experience as the Zoom web client inside your page. Component View lets you embed individual meeting components within an existing page layout, which is the flexible option when you already have a design. The restriction the documentation calls out is that component view is designed specifically for desktop browser use cases and not for mobile, and for mobile you are pointed at client view. That distinction matters for planning, because a team that wants a meeting embedded in a mobile web app has one path, and a team designing a desktop product has two, with the component view being the one that lets the surrounding product survive the meeting.

The CDN build and its cross-origin isolation requirements

The CDN sample uses Node.js 22, specifically 22.12 or newer, and it expects nvm to select that version inside the CDN directory before npm install and npm start, with npm run https using the included local certificate. The main server uses port 9999 and the meeting isolation server uses port 9998. When you host the built output, the README is specific about headers: configure Cross-Origin-Resource-Policy to cross-origin, and add Cross-Origin-Embedder-Policy require-corp and Cross-Origin-Opener-Policy same-origin for the meeting.html page. The Local build carries the same requirement with a different shape, since it says the meeting page receives cross-origin isolation headers directly, which is why the second server on port 9998 is no longer needed there. Getting these headers wrong is a common way for an embedded meeting to load on a laptop and fail in production, so treat that part of the README as a deployment requirement rather than a nicety.

The Local build moved to Oxc and carries its own Node floor

The Local implementation is the one that changed most recently, and its toolchain details are worth a paragraph. It requires Node.js 20.19 or newer, or 22.12 or newer, with Node 22 LTS recommended. Vite 8 uses Oxc for JavaScript transformation and minification, with npm run lint and lint:fix wired to Oxlint and npm run format and format:check wired to Oxfmt, and the note that SDK provided helper HTML is kept unchanged. Building produces Local/dist and npm run preview serves it. When deploying, the same cross-origin headers apply, and the README adds that React, ReactDOM, React Redux, Redux, Redux Thunk and Lodash remain external classic scripts, with those six vendor files copied into dist/node_modules by the build. The instruction is to deploy the entire dist directory, which is a small trap for a deployment pipeline that only copies the entry page.

The government variant needs its own key and version

For government applications the SDK key has to be applied for at the ZFG Marketplace, and there are two ways to wire that up. The first is a ZFG specific SDK version pinned in the dependency list, with @zoom/meetingsdk at 3.11.2-zfg. The second is configuring the ZFG endpoints directly, and the two views take different calls. For client view, setZoomJSLib points the library at the ZFG source path and init passes the ZFG web endpoint:

ZoomMtg.setZoomJSLib("https://source.zoomgov.com/{VERSION}/lib", "/av");
ZoomMtg.init({
  webEndpoint: "www.zoomgov.com",
});

For component view, the embedded client takes an asset path pointing at the ZFG av directory and the same style of web endpoint:

const client = ZoomMtgEmbedded.createClient();
client.init({
  assetPath: "https://source.zoomgov.com/{VERSION}/lib/av",
  webEndpoint: "www.zoomgov.com",
});

The two differences are the asset path shape, with and without the av segment, and the different entry points for the two views.

Editorial conclusion

The sample fits a team starting an embedded meeting experience who wants to see one working integration before writing the signature service, since the repository contains three complete setups against the same SDK. It does not fit a team expecting a maintained library, because a sample is a starting point that you copy, and it does not cover the ZFG variant without a separate key and a version pin. Verify first that you can run the auth endpoint sample and produce a signature, which is the actual dependency and lives in a second repository, that your Node version satisfies the requirement of the build you choose, and that your deployment sends the cross-origin isolation headers the meeting page needs.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. zoom/meetingsdk-web-sample on GitHub