Skip to content

Issues with zoom integration #35

Closed

Description

@MinosChatzidakis

Before submitting

  • I've searched existing issues and this isn't a duplicate.
  • This is a reproducible bug in Calnode — not a configuration/setup question or a feature request.

What's the bug?

Hi,
I have successfully created a zoom app and have added the credentials I got in the Calnode settings.
I have also successfully connected my personal zoom account with Calnode and everything's working flawlessly.

However, when I invite someone from the members tab and they create an account, trying to connect their zoom account results in an error. Upon research, it looks like the zoom app I created is only available to be used by me.
The solutions I have found are the following, all flawed in their own way:

  1. Publish the app (Marketplace Submission): This is the path designed for commercial software companies. To publish, my app must pass a strict review, which it most likely is not in a place to do. I am required to submit technical design documentation, prove I have security controls in place, and pass web application security scanning and manual vulnerability testing conducted by Zoom. It is pretty evident this path is almost impossible, especially since I am trying to do all of this for an open source project I do not own or have any affiliation with.

  2. Join the accounts: By joining accounts, users within my Zoom account can discover and install the app as long as they belong to the account. Once they are internal members of my account, my unpublished Calnode app will work for them instantly without any security reviews or technical design forms. But this comes at a big price. Specifically, it leads to complete loss of user independence: When someone accepts an invite to join my Zoom organization, their personal Zoom account ceases to exist as an independent entity. Their account is permanently absorbed under my umbrella, meaning my admin dashboard can see their meeting history, recordings, and usage logs, and I can enforce settings on them. External users are not going to be particularly keen on surrendering total control of their Zoom account to me.

Apart from that, the financial burden shifts to me: If the users expect paid features, I have to purchase and assign a dedicated Zoom Pro/Business license for every single person I add, rather than letting them use their own existing paid accounts.

Lastly, instead of a simple one-click "Authorize" screen, this scenario expects users to check their email, accept an account migration prompt, and agree to transfer their data to my organization. This is also a not very attractive path.

  1. Ask for permission to share from Zoom: Zoom provides an "authorization URL" that you can share with external users to grant them limited access to test your beta integration. To get this link, one must complete the Technical Design section of the build flow and provide supporting evidence for your security practices. After submission, Zoom's security team reviews the request. If approved, a user-level beta app allows a maximum of 100 external user installations. However, this is not a permanent solution: the link is valid for 4 weeks, and while you can request two extensions, you only get a maximum of 90 days of beta testing. After 90 days, you are forced to fully publish the app or access is cut off. This is also not a particularly viable option, as I am not the author of the project, and even though I can read and interpret the .MD files to understand the architecture and the security design of Calnode, the possibility that my app will get accepted is rather slim, for the same reasons as solution 1.

So I don't know if this is a bug, or an oversight, or something that just hadn't occurred yet, but I am curious to know what the thought process was when the zoom integration was implemented. In other words, how are Calnode users expected to deal with this obstacle? Is there a playbook we can follow?

For what it's worth I have tried hosting both on Docker and Render, even though I do not think that's where the issue lies. Attempts have also been made using different settings within Calnode to no avail.
I am also absolutely certain that the user has an active zoom account, so that's not the issue either.

Thanks in advance

Steps to reproduce

  1. Create zoom app and add credentials on Calnode
  2. Invite a member from the members tab
  3. As the invitee, click on the link received and create a Calnode account.
  4. Attempt to connect zoom from the calendar tab
  5. Observe error

Calnode version / commit

v0.8.0

How are you running Calnode?

Railway / other PaaS

Logs, screenshots, or anything else

Image The above image is the error message I am getting when trying to connect zoom from an account that's not the 'super admin', so to speak.

Activity

  1. pullfrog commented on Sep 7, 2026

    @pullfrog
    Contributor
  2. distronode-com commented on Sep 17, 2026

    @distronode-com
    Contributor

    This isn't a bug in how Calnode talks to Zoom, but Calnode's own setup text pointed you the wrong way, so I've opened #52 to fix that.

    What you ran into is Zoom's distribution rule for apps that aren't published: only users inside the Zoom account that created the app can authorize it. Zoom's docs say it directly: "You can only share private apps with members within your Zoom account" (sharing private and beta apps). Your invitee is refused on marketplace.zoom.us/error before Zoom ever redirects back to Calnode, which is why Calnode shows nothing. Step 2 of Settings → Zoom said "your own team's Zoom users can still connect". That meant users in your Zoom account, but in Calnode, "team" reads as the Members page.

    Your write-up of the three ways around it matches Zoom's docs: bring people into your Zoom account, beta sharing (up to 100 external users, 4 weeks plus two 4-week extensions), or publishing. There's also a fourth option that needs no Zoom app at all. Set the event type's location to Zoom and paste a Zoom link. Calnode uses that link for a booking whenever the host hasn't connected Zoom. It's one link per event type, so it fits a personal meeting room better than a rotation of hosts. For a rotation, the built-in video rooms don't need a per-host account.

    #52 corrects the settings text and adds a Zoom section to DEPLOY.md covering all of the above.

  3. shockalotti commented on Sep 17, 2026

    @shockalotti
    Contributor

    Thank you for the thorough analysis, @MinosChatzidakis - your three options and their costs are exactly right, and there is no fourth code path: Zoom refuses external users on its own consent page before any callback, token, or error reaches Calnode. Nothing in settings, hosting, or reinstalling changes that.

    What I've done instead of code:

    • New docs/ZOOM.md: setup plus a ranked, honest playbook - (1) built-in LiveKit video, which needs no Zoom app at all; (2) same Zoom account, with the independence/licensing costs you listed; (3) publishing, for vendors productizing Calnode; (4) the 90-day beta link as a bridge. Plus a list of things that do not work, so nobody burns an afternoon on them.
    • The Settings → Zoom page no longer implies any team member can connect: step 2 now says same-Zoom-account explicitly, and a warning block with the doc link appears once configured.

    For most teams hitting this wall, option 1 is the real answer: if Zoom won't have you, the video in the box already covers hosted meetings plus recording with zero per-user OAuth.

    On a contributor building per-member BYO Zoom apps: it would technically work and would be accepted within bounds spelled out at the bottom of the doc (instance app stays default/fallback, everything inside internal/zoom, existing secret encryption). It hasn't been built because it asks the least technical users to do the most technical thing - register a Marketplace app each - while LiveKit covers the need with no configuration.

  4. shockalotti commented on Sep 17, 2026

    @shockalotti
    Contributor

    Shipped: docs/ZOOM.md with the ranked playbook, plus a same-account warning on the Settings page so the next team meets the answer before the wall. Closing as answered.

  5. MinosChatzidakis commented on Sep 18, 2026

    @MinosChatzidakis
    Author

    I understand, thank you for the time you took to clarify the confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions