Zoom meetings inside QR Setu — integration assessment

⚠ ASSESSED 2026-09-04 FROM ZOOM'S CURRENT DEVELOPER DOCUMENTATION, FETCHED LIVE. A LOG.

Every claim in §1–§4 marked [Zoom] was read from a Zoom developer page or support article that day and is cited in §9. Claims marked [inference] are our reasoning over those facts. Claims marked [unverified] could not be confirmed from an official page and are stated as such. Zoom's policy pages change quarterly; re-read the minimum-version table before any release.

The brief (owner, 2026-09-04): join and attend meetings inside QR Setu, never in the Zoom app or an external browser · minimal or no SDK version maintenance on our side · a reusable platform capability across Consumer and Merchant, irrespective of industry · assessed client and backend: joining, auth, creation and lifecycle, webhooks, security and tokens, reuse, scale, offline, expansion, operations, cost.

0 · The answer in one paragraph

There is no Zoom integration path with zero version maintenance — and that is Zoom's policy, not a gap in our search. Every Zoom SDK, including the web SDK, is under a quarterly minimum-version enforcement: versions below the published floor "cease functioning in production, preventing customers from joining meetings" [Zoom]. What we can choose is where the version lives. The recommended architecture puts it in one server-rendered web page that QR Setu hosts, loaded inside the app in a WebView, using Zoom's Meeting SDK for web — a pattern Zoom documents as supported on both Android and iOS [Zoom]. The quarterly bump then becomes a web deploy with a smoke test, never an app-store release, and the same page serves a browser visitor and a merchant. For hosting (creating rooms), the launch model is Server-to-Server OAuth on QR Setu's own Zoom account, which avoids the Zoom App Marketplace review that any join of a meeting outside our account now requires [Zoom, effective 2026-03-02] — a review with no stated SLA, observed to take three months in one public case. Hosting on a person's own Zoom account (the design's current premise) is possible later and costs two Marketplace reviews.

1 · What Zoom officially offers today, and what each costs to maintain

Option	What it is	In-app join?	Version maintenance we own	Verified
A · Meeting SDK, native (Android / iOS) via the React Native wrapper	Zoom's meeting UI compiled into the app	✅	Highest. Native binaries in the app; a new build per quarterly floor; RN wrapper supports RN ≤ 0.75.4 and "Expo is not supported" — our app is Expo SDK 57 / RN 0.86. Android AAR historically 89 → 126 → 148 MB; forum reports of APKs growing 20 → 90 MB	[Zoom] RN page · [forum] sizes
B · Meeting SDK for web (Client View), inside a WebView, on a page we host	Zoom's meeting UI as JS loaded from Zoom's CDN at a pinned version	✅	Lowest available. The pinned version is one string in one server page; a quarterly floor is a web deploy. No native SDK, no binary growth, Expo-compatible (a WebView is an ordinary RN component)	[Zoom] docs + two official blogs: "embed the Meeting SDK for web… in WebViews on native Android and iOS apps", "supported in Meeting SDK for web 2.10.1 and above", positioned "if you are optimizing your app for package size"
C · Zoom's own web client (zoom.us/wc/join/…) in a WebView	Zoom's hosted join page	❌ in practice	none	[forum] the web client in an Android WebView prompts for the Play Store instead of joining; "Join from your browser" is a host-account setting that may be off. Not a supported embedding surface. Rejected.
D · Video SDK (sessions, not meetings)	Zoom's media stack for our own sessions; UI Toolkit on Android / iOS / web (not RN)	✅	Same quarterly policy; per-minute billing; sessions are not Zoom Meetings — "only your Video SDK account can start and join your sessions"	[Zoom] auth + fact sheet
E · Deep link to the Zoom app	hand-off	❌	none	excluded by the brief

The policy that decides the maintenance question — verbatim

"On a quarterly basis, Zoom enforces a required minimum version for each SDK. Versions below the published minimum will cease functioning in production, preventing customers from joining meetings." … "Zoom enforces new minimum versions quarterly, during the first weekend of November, February, May, and August." … "Zoom will make an effort to support a given version for at least 9 months before it falls below the minimum version." — [Zoom] SDK minimum version policy and the Software Quarterly Lifecycle Policy.

The lifecycle table [Zoom] on 2026-09-04: Meeting SDK native floor 6.0.2 (Android/iOS); Meeting SDK (Web) 3.6.0 today, rising to 4.0.0 on 7 November 2026 — a major version becomes the floor with one quarter's notice; Video SDK 1.11.0 native and web; the Video SDK UI Toolkit (web) is listed too. The web SDK is explicitly inside the policy. So option B does not escape maintenance; it makes it a deploy instead of a release, which for a two-person team distributing an APK from a website with no store listing is the difference that matters.

⚠ [unverified] No "latest" alias for the CDN path was found in Zoom's documentation; every example pins https://source.zoom.us/{VERSION}/…. We should not rely on an unpinned URL even if one worked, because a silent major bump (3.x → 4.0) on the CDN would be a production outage nobody deployed.

2 · Authentication and access — how a person gets into a room

[Zoom] The Meeting SDK joins with a server-signed JWT (HMAC-SHA256 over the Meeting SDK app's Client ID / Client Secret; exp ≥ 1800 s after iat, ≤ 48 h recommended; "generate this where you can securely store your Meeting SDK credentials, such as through a backend"). role: 0 joins; role: 1 starts and requires the host's ZAK. A participant joining needs meetingNumber, password, signature, userName — no Zoom account. A ZAK is needed to join only when the host has required authenticated participants.

[inference — the QR Setu flow]

app / browser ──► GET meet.qrsetu.com/join/<participant-token>          (apps/web, SSR, no-store)
                  page loads Meeting SDK for web @PINNED from source.zoom.us
                  page calls EF meeting-join-token(participant-token)
EF                validates the participant row · rate-limits · signs a role-0 SDK JWT (≤ 2 h)
                  returns { signature, meetingNumber, password, userName }   (never the Client Secret)
page              client.join(...) → the meeting runs inside the WebView

• The participant token is ours: an opaque, hashed, per-person, per-meeting token from meeting_participants (the same shape as biodata share tokens). It is what the calendar's Join and the WhatsApp reminder carry. Revoking it revokes the seat; Zoom's own passcode never appears in a QR Setu link.
• The Client Secret lives only in the Edge Function's secrets. The page and the app never see it.
• Offline: the join page is not cached (no-store); the app shows the design's "the link we last saw" state and retries; a Zoom outage surfaces as the SDK's own error, rendered by us.

3 · Hosting — three models, and the review rule that separates them

⚠ THE RULE THAT CHANGED THE RECOMMENDATION — [Zoom]

"Apps will need to go through our App Review process to join Meetings outside their own account." Effective 2 March 2026. The review requires production credentials, detailed test cases, end-user test credentials and possibly a demo; it has four stages (completeness, functionality, security — a Technical Design Document and OWASP Top-10 testing, remediation) and no stated timeline ("varies based on app quality…"). One public forum case: submitted 2 September 2025, promised "by the end of this week", approved 11 December 2025. Beta and unpublished apps are usable only by members of the developer's own Zoom account [Zoom].

Model	Rooms are minted on	Zoom reviews needed	Licences	Fits the design?
H1 · Server-to-Server OAuth, QR Setu's own account	QR Setu's licensed users (a seat pool)	None to launch — meetings are inside our account, so SDK joins need no review; S2S apps are internal	Paid seats. Business / Education / Enterprise licensed users may host up to 2 concurrent meetings [Zoom KB]; Basic is capped at 40 minutes. So capacity = 2 × seats, and concurrency is a scheduling constraint we enforce	⚠ Contradicts meeting-providers.js contract #2 ("the room is minted on the host's own provider account under their own plan") — a design change
H2 · User-managed OAuth, the host's own account	the host's Zoom	Two: the OAuth app (unpublished apps cannot be authorised outside our account) and the Meeting SDK app (joins are outside our account)	none for us; the host's plan sets their limits (the design already reads limits from the auth response, never hardcodes them)	✅ the design's model
H3 · Video SDK	our Video SDK account (sessions)	None (not a Marketplace app)	10,000 free minutes / month, then $0.0035 per minute [Zoom fact sheet]; sessions up to 5,000 users	⚠ Not Zoom Meetings: no Zoom link, no Zoom app, no interop; UI Toolkit exists for web (usable in the same hosted page) but not for RN

[inference] H1 also yields webhooks for every meeting (meeting.started / ended / participant_joined / left) on our own account with the standard CRC validation and x-zm-signature HMAC [Zoom] — which is what makes "joined via QR setu" (the design's honest attendance fact) recordable server-side rather than trusted from the client. Under H2, webhooks arrive per authorising user and the Meeting SDK app review still gates the join.

4 · Recommended architecture — a platform capability, not a feature

                 ┌────────────────────── QR Setu ──────────────────────┐
consumer app ────┤  Meetings tab (calendar · detail · join)            │
merchant app ────┤  Sessions (host: create · reschedule · cancel)      │   ← same seams
browser ─────────┤  meet.qrsetu.com/join/<token>   (apps/web, SSR)     │
                 │        └─ Meeting SDK for web @PINNED (Client View)  │   ← the ONLY place a Zoom version lives
                 │  EF meeting-join-token      role-0 JWT, rate-limited │
                 │  EF meeting-host            S2S: create/update/delete│
                 │  EF zoom-webhook            CRC + HMAC, → ledger     │
                 │  meetings · meeting_participants · meeting_invite_   │
                 │  states · meeting_joins · meeting_provider_rooms     │
                 └─────────────────────────────────────────────────────┘

1. Join surface = one hosted page (apps/web, tiers/meetings/routes/join.tsx): loads the Meeting SDK for web Client View (the view Zoom names for mobile) from Zoom's CDN at a version pinned in one constant; requests the signature from the EF; client.join. Rendered in the app through react-native-webview (a new dependency — owes the size callout; it is a thin bridge, not a media stack) with camera/mic permissions and allowsInlineMediaPlayback per Zoom's iOS blog and setMediaPlaybackRequiresUserGesture(false) plus a permission-granting WebChromeClient per the Android blog [Zoom]. The same URL works in any browser, so a recipient without the app joins too.
2. Provider seam (packages/data/meetings, packages/domain/meetings): createRoom, updateRoom, cancelRoom, joinTicket. The Zoom implementation sits behind it; no screen and no seam names Zoom, so Google Meet or Teams is a second implementation (meeting-providers.js's own rule: "the provider is a row, never a branch").
3. Hosting at launch = H1 (S2S OAuth on QR Setu's Zoom account, a small pool of licensed seats, concurrency enforced by our scheduler: 2 per seat on Business+). Rooms are created with waiting_room off and join_before_host on so the participant's Join works without a Zoom client on the host's side; the host joins with role 1 via a ZAK our EF fetches for the seat user.
4. Lifecycle: create → room minted (or saved without a room and retried — the design's provider_failed state) → reminders (local, unchanged) → join tickets → webhooks record started / ended / joins → joined via QR setu facts → post-session follow-up list. Reschedule writes an exception (contract #1) and updates the room's start time; cancel deletes the room and marks the occurrence.
5. Security: Client Secret and S2S credentials in EF secrets only; participant tokens hashed at rest; SDK JWTs ≤ 2 h; webhook endpoint validates CRC and x-zm-signature, dedupes on event id; join tickets rate-limited per participant and per source; the join page is noindex, no-store.
6. Observability: every ticket issue, room create and webhook lands in a meeting_events ledger (the payment_events idiom); a watchdog query counts tickets issued with no meeting.started in the window.
7. Version operations: a check:zoom-sdk-floor script (proposed) reads Zoom's lifecycle table and fails CI when our pinned web SDK is within one quarter of the floor — the cheapest layer that can observe the defect, and the only thing that makes "quarterly" survivable for two people.

5 · Trade-offs stated, not hidden

• H1 contradicts the design's hosting premise. The design reads the host's plan limits from their own Zoom; under H1 the limits are QR Setu's seat pool and the Connect Zoom / Meeting account views become "QR Setu hosts this for you". That is a Claude Design round, and it is cheaper than two Marketplace reviews on an unbounded queue before launch. H2 remains the path if hosts must own their rooms — start its reviews early, they are the critical path.
• The WebView is not the native SDK. Zoom names the native SDK as "preferred" and the WebView as the package-size option; feature coverage follows the web Client View (Zoom: "the web client has limited features"). For yoga batches, PTMs and reviews that is sufficient; for breakout rooms or advanced host controls it may not be. State it in the product, not in a footnote.
• Cost: H1 = seats (Zoom lists Business per user per month; India pricing differs — get a quote); H3 = usage. Neither is free. The design's "QR setu does not sell Zoom plans" stays true under H1 because the host never buys anything; QR Setu carries the seats.
• Scale: the join page is stateless and edge-cached except its token exchange; the EF signs a JWT per join; Zoom carries the media. The bottleneck is seats × 2 concurrency under H1 — a scheduling problem we can see, not a capacity cliff we cannot.

6 · What can be built on the current architecture, and what is an extension

Current architecture

Extension

The join page in apps/web (SSR route + headers) · the EFs on the shared kit · the token and rate-limit tables from the consumer plan · webhooks on the razorpay-webhook pattern · the meetings schema already in the plan · local reminders

react-native-webview (new dependency, size callout) · S2S OAuth to Zoom (new external credential set, an EF calling Zoom's REST API) · a Zoom account with licensed seats · a Meeting SDK app on the Marketplace (development credentials suffice for our own account's meetings — ⚠ [unverified] whether Zoom permits an unpublished app's credentials for production traffic on own-account meetings; a forum case shows error 6601 when this is wrong. Confirm with Zoom before P9 starts.) · (H2 only) a user-managed OAuth app + two Marketplace reviews

7 · Decision required

	Recommendation
Join surface	B — Meeting SDK for web in a QR Setu-hosted page, in a WebView. The only path where a quarterly floor is a deploy, not a release; officially supported by Zoom on both platforms; Expo-compatible; one surface for app, browser, consumer and merchant.
Hosting at launch	H1 — S2S on QR Setu's account. No Marketplace review to launch; full webhooks; needs a Claude Design round to reword the Connect views and a seat quote from Zoom.
Later	H2 if hosts demand their own accounts — start both reviews the day it is decided. H3 (Video SDK) stays the documented alternative if seat economics fail or Zoom interop is not needed.
First act	Confirm with Zoom the unpublished-credentials question above, and open the Zoom developer account under Digious Platforms Private Limited (organisation accounts only).

8 · What this assessment cannot see

• Zoom's review timelines beyond one public case; there is no SLA anywhere in the documentation.
• The exact feature gap between the web Client View and the native SDK for our meeting shapes — test it on a real yoga batch on Dev before promising it.
• Indian pricing for Zoom seats; every number here is from public US pages.
• Whether an unpublished Meeting SDK app's credentials are acceptable for production traffic on own-account meetings ([unverified], §6).

9 · Sources (read 2026-09-04)

• SDK minimum version policy · Zoom Software Quarterly Lifecycle Policy — version enforcements for developers · Video SDK minimum version policy
• Meeting SDK for web · Best practices using the Meeting SDK in an Android WebView · Best practices using the Meeting SDK in an iOS WebView · Component view — meetings
• Meeting SDK authentication · Meeting SDK for React Native — integrate · Meeting SDK for React Native
• Meeting SDK feature review & requirements · App review process · Zoom security review for Marketplace apps · Create an OAuth app · Internal apps (Server-to-Server)
• Using webhooks · Webhook validation changes
• Video SDK · Video SDK authorization · Video SDK fact sheet · Video SDK for React Native · Video SDK + Expo blog
• Hosting multiple meetings simultaneously · Enabling the "Join from your browser" link
• Forum evidence (not policy): Android SDK size 126 MB · APK 20 → 90 MB · Zoom app approval timeline · Beta app cannot join external meetings · Zoom in Android WebView prompts for the Play Store