Force username when entering meeting using browser Zoom app



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:{IDMEETING}/join?pwd=&dn={PARTICIPANT_NAME}&track_id=&jmf_code=&meeting_result=

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?



Thank you,




David Pereira





Thanks for your suggestion. Now our api doesn’t support your need.

You can connected our support team, we will support this feature in the future version.



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 :slight_smile: 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.




Sorry typed the wrong URL its this one…


Hello, Is this supported now? Basically, the ability to enter the name for the user via the url and to skip the page that asks for the user’s name.

Hey Zeusstl,

I believe the only way to accomplish this is with our meetings API:

POST /meetings/{meetingId}/registrants

Docs here:

This generates a unique url for the user and sends them an email to join the meeting.

The only catch is the meeting has to be scheduled.
(You can do this from your meetings web dashboard

And the “Registration” setting must be set to “Required”
More about that here

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:

You’re welcome Zeusstl, happy to help!

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!

HI @tommy,

Does the API support to enter Display Name through the URL now?

Subhan Ahmed

@zeusstl Good news, I just found out we have this feature!

Using this url you can pass a default username. Be sure to include the prefer=1 param and base64encode the username in the un param.{MeetingID}/join?prefer=1&un={Base64EncodedUsername}

So the final url would look like

(tommy is dG9tbXk= in base64)

I will be sure to add this to our docs!

Thanks and hope this helps!

Wow @tommy. That’s awesome. Thanks!

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.

Is there also a query token for a leaveUrl?

No problem!

Do you mean for when a meeting participant leaves a meeting? If so, this might help:


Go to the “Meeting Participant Joined/Left” Tab

Let me know if thats what you’re looking for, otherwise can you share some more details?

Hi, @tommy, all,

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.

Thank you!

Hey @malan, thanks for reaching out!

Currently we don’t have any docs for this feature.

The url should always open the web client, hence the /wc/ path in the url.

What url are you using to give the user the option to open in the Desktop/Mobile Zoom Client?


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)?


Hey @malan,

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.

Let me know if this helps!

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!

Hey @asprague,

In my post above, you can set the username for users joining a meeting with the Zoom Web Client with this url:


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.