Here’s a feature, stop moving around documentation! These threads in all these forums that reference your docs are 404’s!!! That makes these threads pretty much useless and frustrating and hell.
Totally valid feedback @mikkimichaelis, let me think on how we might be able to solve this at scale. Our docs have changed as our platform has evolved, we try our best at 301 redirects but sometimes things fall through the cracks.
What are you looking to get solved? Can I help navigate to the right place?
Thank you so much! I tried finding the actual post here that had the 404. I’m having difficulty opening the zoom app from expo and wanted to verify the urls to use on a device. The 404 link was to something such as “Zoom Client URLs”, which I did search the correct pharse in the docs but it came up with nothing very specific. Unfortunately I can’t remember the exact pharse.
1 Like
Got it!
@mikkimichaelis, I actually made the call to take that documentation down around 2020 (I think?). (we wrote it in 2018 & redid it in 2019). I did this for a few reasons:
- We don’t recommend developers like yourself use those client URL schemes as a good basis to launch the Zoom app as a deeplink or direct app launcher. We highly recommend using the Meeting URLs that go to zoom.us/** or subdomain.zoom.us/ as there’s significant auth context that gets passed down from the zoom domain to the zoom client. Meetings often have requirements that get checked at that join URL. Many, many users have SSO login flows on their account that benefit from cached login at that domain.
- We couldn’t commit that that URL scheme would always stay in place. We couldn’t continue to recommend (in docs) that someone use those client URL schemes to build a deeplink flow to join users into the app if there was a possibility that the Zoom link flow changed. We know who uses REST APIs and client SDKs and can communicate version changes accordingly. We were worried that sanctioning this as a developer “interface” would lead to a bad breaking change in the event the Zoom client team ever decided to change the scheme.
These aren’t secrets; they’re in network requests that get passed down from the start/join URLs of meetings to launch the client. But we don’t recommend building off of them, so we don’t have docs on that.
Can your Expo app launch web requests or is there a restriction on embedded web views? Or is this a matter of direct linking being more direct on mobile.
Totally understand your decision.
1 Like
Yes, I have my iOS app now launching Zoom App by using the Zoom App’s registered deep link “zoomus://”. This is working properly for me. Here’s my exact code
const password = `&pwd=${meeting.password !== '' ? meeting.password : meeting._password ? meeting._password : ''}`;
const url = `zoomus://zoom.us/join?confno=${meeting.zid}${password}&zc=0&uname=${user}`;
Is this the correct way to open the Zoom App such that it joins a meeting and takes into account #1 above?
I actually have a much larger issue I’d like to discuss with you. The reason I’m launching the external Zoom App is because my particular app need to join any public aa or na meeting. Therefore I can’t embed the sdk into my app and join the meeting internally, because the sdk has the limitation of only connecting to a single zoom meeting.
I’ve discussed this issue here once before and was told that I need to submit my app like any other market place app and stating my requirements. However I’m very confused exactly how to do this as my app is not a Marketplace app at all.
Here is the link to that previous discussion
My original app was build with the SDK and I would love to return to that architecture and discard zoom urls completely.
This is a well established and loved app on both marketplaces with 4.8 stars.
How do I get this process started with Zoom?
1 Like
Yes, but I’ve seen cases where uname isn’t accepted / is overridden by login requirements or logged-in state of the client. There also may be a moment where the user is told to go log in to join a meeting that has authentication requirements. As long as you’re cool knowing this isn’t our “official” recommendation, this should work.
Yes, I’m aware of the limitations. I’ve been using this method for 18 months in production.
So I went back and reread that thread and the documentation has been updated for my exact needs! It would seem the type 'Unlisted App’ has been added.
1 Like
If you want your app to embed the Meeting in AA/NA Live! (previous implementation), you should definitely use the Meeting SDK. If you want to kick out to the Zoom app, you don’t need to get reviewed — because your app wouldn’t have access to the user data available in the Meeting SDK.
You don’t need to be published/publicly listed on our App Marketplace; the app could be unlisted/undiscoverable on the Zoom App Marketplace. You’d have something like a “connect your Zoom account” button in your app and a user would be shown an app install page, then be redirected back if successful. (And yes we think you should share your honorable work with the world if that makes sense to you).
If you want to use the Meeting SDK, your app just needs to go through App Review to join meetings external to your own account (meetings hosted by users not on your same account). If you were building AA/NA Live! for people on your own account, we don’t need to review. If you allow users to download the app from the Play Store and join any meeting (say, connect a calendar or have people input the ID/passcode), your SDK key needs to pass through review in order to join those meetings.
Yes, so the app (client ID) you’re using now will just need to get submitted for review. And you select that you want to be the one to publish it - and just never publish it. The option would be available for you to make it discoverable, but not at all a requirement.
Thank you so much for your explination! I understand enough to get started building an unlisted marketplace meeting sdk app. The marketplace app will have a link to the app stores.
The nature of the app itself, being a tool for anonymous recovery, makes users not want to authenticate with pretty much anything. So I don’t see the need to ‘connect to you Zoom account’. All that’s needed on my Marketplace app are links to install the device app.
If users of the device app want to authenticate with zoom (say for profile pic or calendar integration) I’ll start that flow from within the device app itself.
Does all that sound correct to you?
Of course, sorry you got such a run-around on info on this. Hope we can help settle the path. Thanks for what you do to make Zoom better, particularly for the audience you serve.
Oh, yes, that’s totally right. You wouldn’t need to do any of that OAuth flow for the user if all you were doing is joining Meetings where you already had details (from calendar, etc).
Once reviewed, your unlisted app (your client ID) can join any Meeting.
Other participants in that meeting would see the app appear in the Meeting’s Active Apps Notifier in the top-left of the Zoom app. So you’ll want to add a similar icon/description to what you have in the Play Store. This acts as a privacy disclosure to tell people if some participants have joined via an app or there’s an app accessing data about the Meeting.