Query parameters

Overview

Query parameters configure a meeting room directly from its URL. They let you control an embedded meeting room without writing any code, which is especially useful when you place the room in an iFrame in your own application.

Append them to a meeting URL:

https://<DOMAIN-NAME>/meeting/<MEETING-ID>?participantName=Test%20User&meetingPassword=1234

URL-encode every value. Otherwise a name containing a space, an email address, or anything with & or = in it breaks the rest of the URL.

Boolean parameters take the literal strings true and false.

Using this page with an AI assistant

If you are using an AI coding assistant, copy the text below into it and add a sentence describing what you want to build. AI assistants accessing this page receive a separate, token-optimized version of our full developer documentation, specifically tailored by our engineers for AI coding assistants.

Before writing any code, read this page:
https://www.veeting.com/en/developer-documentation/query-parameters

It documents the URL query parameters of a Veeting Rooms meeting room.
Keep these five rules in mind:

1. URL encode every value. Names and email addresses usually contain
   characters that need it.
2. Booleans are the literal strings "true" and "false". Not 1 or yes.
3. Parameter names are identifiers. Never translate them, whatever
   language the surrounding page is in.
4. The platform strips tokens and personal data out of the URL, so do
   not read them back from window.location later. Keep them in the
   application instead.
5. Only use parameters that appear on that page. Do not invent one and
   do not use one you found by reading our JavaScript bundle.

What I want to build:

Two things to know before you start

The platform removes some parameters from the URL. Anything that carries a token or personal data is stripped, plus a few more parameters. Removal happens either immediately or before the browser navigates. That is deliberate: those values then do not persist in browser history, in a bookmark, or in a Referer header. The lists are at the end of this page, and they matter if you expect to read a parameter back out of the address bar later.

Not every parameter the platform accepts is listed here. The others are internal, serve support tooling, or carry other access tokens that we do not describe publicly. If you need one that is not documented, ask us rather than relying on one you found by reading our JavaScript bundle: an undocumented parameter carries no compatibility promise.

Participant details

These parameters pre-fill the "Join Meeting" screen so the participant does not have to type them.

The room resolves culture in this order:

1. If your instance offers exactly the code you pass, the room uses it. Instances offer bare de by default, so de stays de.
2. Otherwise, if your instance offers the browser's primary language exactly, the room uses that.
3. Otherwise a bare code maps to a fixed locale, if your instance offers it: en -> en-US, de -> de-CH, es -> es-LA.
4. Otherwise the browser's primary language goes through the same map.
5. Otherwise the room uses the alphabetically first language your instance offers.

In steps 1 and 3, culture overrides a language the participant chose on an earlier visit in the same browser. In steps 2, 4, and 5, that earlier choice wins.

Access and authentication

The meeting's tokens are fields of the meeting object: read the meeting back through the REST API and take data.moderatorToken, data.invisibleToken, or data.backstageToken from the response.

Note: These values are credentials. Keep them out of links you share with people who should not have them. See "Parameters the platform removes" below: the platform strips moderatorToken, invisibleToken, backstageToken, and jwtToken from the URL for exactly that reason. meetingAccessHash and meetingPassword are not stripped: they stay in the address bar, and so end up in browser history, in bookmarks, and in any Referer header.

The "Join Meeting" screen

Layout and media

TV screens and directors

Two kinds of participant join a meeting without being seen: a TV screen that shows the meeting on a wall or a stage, and a director who steers the meeting from the background. Both carry invisibleToken.

TV screens

A TV screen combines enableTVMode with invisibleToken:

https://<DOMAIN-NAME>/meeting/<MEETING-ID>?enableTVMode=true&invisibleToken=<INVISIBLE-TOKEN>

By default, a TV screen shows the meeting room content only once regular participants can see it. To show it from the moment organizers and moderators can start preparing the meeting, about 60 minutes before the start, add backstageToken:

https://<DOMAIN-NAME>/meeting/<MEETING-ID>?enableTVMode=true&invisibleToken=<INVISIBLE-TOKEN>&backstageToken=<BACKSTAGE-TOKEN>

Directors

A director is a moderator who stays invisible and sends no media. Combine invisibleToken with moderatorToken:

https://<DOMAIN-NAME>/meeting/<MEETING-ID>?invisibleToken=<INVISIBLE-TOKEN>&moderatorToken=<MODERATOR-TOKEN>

Do not add enableTVMode to a director's link: TV mode ignores moderatorToken, so the director would join as a TV screen without moderator rights.

Devices

In the meeting

Embedding, testing, and support

Parameters the platform removes

The platform takes two sets of parameters out of the URL. Neither removal is a bug, but both will surprise you if you expect to read a value back from window.location later.

Removed immediately, always. These do not remain in the address bar, with the one exception described below:

meetingAccessToken
meetingAccessRequestToken
meetingChallengeCode

Removed before the browser navigates. The platform reads these first and then clears them, so they do not end up in history, in a bookmark, or in a Referer header sent to a third party:

skipJoinMeetingScreen   jwtToken          moderatorToken
invisibleToken          backstageToken    interpreterToken
authenticationSkipToken participantName   participantUuid
participantEmail

The exception is an unattended client. On a client opened with enableTVMode or autoApplyUpdates set to true, an automatic update reload during a meeting puts every parameter the client was opened with back into the address bar, tokens included, so that the client rejoins the room. The reload replaces the current history entry instead of adding one. Separately, setting forcePreserveQueryParameters to true turns off the removal before navigation.

If you need a value after joining, keep it in your own application rather than reading it back from the URL.

Common mistakes

• Forgetting to URL-encode a value. A space in participantName is the most common case.
• Setting skipJoinMeetingScreen=true without participantName and expecting the join screen to be skipped. With no name available, the participant still sees it.
• Hiding the consent checkbox and assuming consent has been handled.
• Expecting moderatorToken or participantName to still be in the URL after the meeting room has loaded.
• Sending backstageToken but leaving out enableTVMode=true or invisibleToken. On its own it does nothing.
• Adding enableTVMode to a director's link. TV mode ignores moderatorToken.
• Sending 1 or yes for a boolean. Only true and false are recognized.
• Translating a parameter name. Parameter names are identifiers and are always in English.
• Using an undocumented parameter found by reading the bundle. They carry no compatibility promise.