Meeting SDK Web 6.2.0 — wc/info returns HTTP 503, join fails with -3000 on own-account live meeting

Meeting SDK Web
1

Hi,

We’ve integrated the Meeting SDK for Web 6.2.0 (Component View) into our own LMS at campus.academiaenlevo.com.br. Students join scheduled classes from inside our platform. No join has ever succeeded.

The visible error is:

{ “type”: “JOIN_MEETING_FAILED”, “reason”: “connection error”, “errorCode”: -3000 }

But the actual failure, captured in DevTools, is:

POST https://zoom.us/api/v1/wc/info → HTTP 503

init() completes fine. The SDK dies on that call, every time.

Our setup

  • App: General App, Admin-managed, published to our account (“Users within my account”, Live).
  • Meeting SDK is enabled under Features → Embed — confirmed in the downloaded Manifest File: embed.meeting_sdk.enable: true, platform Web.
  • Using the Production Client ID / Client Secret from that same app.
  • A separate Server-to-Server OAuth app on the same account creates the meetings, and works perfectly.

What we’ve already ruled out (please skip these — happy to show evidence for any):

  1. Signature format. HS256 JWT with appKey, sdkKey, mn, role: 0, iat, exp, tokenExp. exp - iat = 120 minutes.
  2. Credential pair. appKey matches the app’s production Client ID exactly; the secret is that same app’s Client Secret. Both were re-entered together to rule out a mismatched pair.
  3. Clock skew. Our server’s clock is identical to yours — compared against the date: header from api.zoom.us, zero seconds difference.
  4. Browser environment. HTTPS, cross-origin isolated (COOP same-origin + COEP require-corp), SDK bundle loaded from source.zoom.us with crossorigin=“anonymous”.
  5. Meeting settings. Created via our S2S app on the same account, with waiting_room: false, join_before_host: true, approval_type: 2.
  6. The meeting itself is healthy. It opens normally in the Zoom Web Client at app.zoom.us/wc//start.
  7. Live meeting, host present — still 503. We started the meeting as host and then joined via the SDK on a clean page load. Same result.
  8. Reproduced with three different meetings, both API-created and created manually in the web portal.

Questions

  1. What makes wc/info return 503 for an existing, live meeting owned by the same account as the app?
  2. Is there an account-level setting outside the app — something like allowing embedded Web SDK, or a domain allowlist — that must be enabled before Meeting SDK credentials are accepted?
  3. Does the March 2, 2026 OBF/ZAK requirement apply when joining meetings owned by the app’s own account? If so, what exactly is missing from our join flow?

Happy to share the app’s Client ID, account ID, and a failing timestamp privately via DM.

Thanks!

2

@Psicanaliticamente I’ll PM you for more information

3

Hi @chunsiong.zoom,

We are seeing the same behavior in a separate LMS staging integration using Meeting SDK for Web 6.2.0 (Component View). SDK initialization succeeds, but join displays “Fail to join the meeting.” Our application receives only a generic SDK failure, and the console shows the warning “clear before initial.”

We reproduced it in a clean Chrome session while the host meeting was already live. We verified:

  • General app development Client ID/Secret pair matches the server configuration
  • Meeting SDK is enabled and the app is installed on the owning account
  • The meeting and SDK app belong to the same Zoom account
  • Participant role is 0
  • JWT claims follow the current documented format
  • Meeting passcode matches
  • No meeting authentication requirement is enabled
  • The same meeting joins normally through the Zoom Web Client

Zoom Support classified our case as configuration-related and directed us to the Developer Forum. We have not independently confirmed an HTTP 503 from wc/info because our current browser diagnostics expose only the generic SDK callback, but our setup and visible failure closely match this report.

Could Zoom staff confirm whether this is a current Meeting SDK 6.2.0 incident, or advise which configuration should be checked next? We can provide the app Client ID, account ID, failing timestamp, and support case number privately. No credentials or meeting passcode will be posted publicly.

4

Hi @chunsiong.zoom, following up on our September 3 report. The issue remains unresolved and is blocking our LMS staging validation.

Could you please confirm whether this is a known Meeting SDK 6.2.0 incident or an account/app provisioning issue? We can provide our Client ID, Account ID, support case number, and a fresh failing timestamp privately. Please advise which diagnostic information you need and where we should send it securely. Thank you.