We were wondering if there is a way to enter a Meeting using the browser version instead of Zoom app, for example in Chrome, and force the name of the participant.
The link to enter the meeting is something like this:
and when we fill the name and actually enter to the meeting:
We tried using the “dn” parameter but it also asks the user for the user name before entering the meeting.
Can we add a parameter to one of these URLs so we can enter directly to the meeting with the given name? Or at least the input for the name is filled with the given name?
Hello Zoom Team … I just wanted to follow up and see if this feature was ever developed?
We also are looking for a way to bypass the name and email address prompt when user goes to the web client. We are hoping to pass those as parameters in the webclient URL.
While this may not be officially supported (I’m not sure I’m not from Zoom) i have found away to do this if you “Inspect” the “Join via browser link” you will find a URL embedded that will take you directly to this meeting room. I have put the link below it may be slightly different for you but this worked great for me inside an iFrame.
Let me know if this works and I will let you know if we come out with an editable link based solution to pre-fill / pass by the name field when using the browser.
Thanks @tommy! This is a great solution. I think the email step prevents me from using it for my immediate purposes, but I have no doubt this will come in handy.
I’ve also started trying the js sdk in the meantime. It seems a bit slower, but I’ve submitted another request to try to get more information on best practices for setting up the js sdk host:
Regarding the email step, the response of POST /meetings/{meetingId}/registrants includes the unique join url (join_url) If you wanted to use/save/send it differently you could do that.
We are looking at your other request and will get back to you as soon as we can!
I’ve gotten pretty far with the web sdk. Still waiting on a few answers, but it’s looking great, so might still go that route. But this is a fantastic solution in the meantime.
Just wanted to check, at what URL are the docs (if up now) for supported URL parameters like prefer and un? Afraid some Googling only led me back to this thread!
And is there a way for the value of un to propagate to the client-side Zoom app, if users have that installed? It seems that un works great if a user doesn’t have the Zoom app installed (or declines to open a meeting in the Zoom app when prompted, instead joining via their browser. But if I user does allow the URL to trigger the client-side Zoom app to open, it seems that (if they’re not logged in) the name field in the app itself is prepopulated with their own computer’s username rather than the value of un? That’s the behavior we’re seeing on macOS and Linux, at least.
Hi @tommy, apologies for the ambiguity. URLs of the /wc/ form do work as expected with the web client. I should have asked if there’s a way to use prefer and un (or some equivalents) with URLs that open the Desktop/Mobile Zoom Client (as do URLs of the /j/ form), to pre-populate the user’s name in that client (if they’re not already logged in)?
The only way to pre populate a user’s name on the Zoom Desktop/Mobile Client if they are not logged in is to have them set a default name in the Zoom Client like this,
Click Join a Meeting
Enter a name and check “Remember my name for future meetings”. Join any meeting/a test meeting you make to save the settings.
Then when the user joins/clicks a meeting via a join url that name will be used when they join.
This does not help. To protect privacy, all users on our site have usernames. I need to specify the username the app should use on the join URL and not let the invitee enter anything they feel like entering which might reveal personally identifying information!
The web client has its own problems, especially microphone volume. We’re using that right now because we can specify a name. We are going to be switching, though, to the download client so that we have a microphone check and put up with the fact that people are probably going to enter a name that does not match the records we’re keeping by username.