Contact Information
Useful Links
Legal
Use Cases
Case Studies
«Veeting» is a registered trademark of Veeting AG. Veeting AG is a registered business in Zurich, Switzerland. All Rights Reserved. © 2014 - 2026, Veeting AG.
In the Security section of the white-label settings, you decide how users of the instance log in. Authentication type has three options:
With every option, a user has to exist on the platform before they can log in. Sign-in identifies them by their email address and creates no one. Create users in Account management, or let your own system create them through the REST API.
Guests who join a meeting do not log in, unless the meeting admits only logged-in users. See Who may enter a meeting?.
| Setting | What it does |
|---|---|
| Login url | The address of your service. The platform sends it the email address and password a user entered, and expects to hear whether they are valid. |
| Reset Password url | Where the "forgot password" link on the login page takes users, so they reset their password with you rather than on the platform |
| Setting | What it does |
|---|---|
| Entry point | The single sign-on address of your identity provider |
| Issuer | The name under which the instance identifies itself to your identity provider |
| Public remote certificate | Your identity provider's signing certificate, so the platform can verify its responses |
| Authn context | The authentication context the platform requests, if your identity provider expects a specific one |
In your identity provider, register the instance with this address for the responses:
https://<host name of the instance>/api/v6/auth/saml/callbackThe response must carry the user's email address, which is how the platform recognizes them.
Yes, with cookie SSO. If your own web application sets a cookie that the instance's host name can read, the platform can use it to log the user in.
| Setting | What it does |
|---|---|
| Cookie SSO | Switches cookie SSO on |
| Cookie name | The name of your cookie |
| Cookie verification URL | Your service that receives the cookie's value and answers whether it is valid and which email address it belongs to |
The cookie must be readable by the instance, which in practice means that the instance runs on a subdomain of the domain that sets the cookie.
| Setting | What it does |
|---|---|
| Allow two-factor authentication | Users can protect their login with a code from an authenticator app |
| Allow two-factor authentication fallback to email | A user without their authenticator app can have the code sent by email. Convenient, but it makes the email account the second factor. On by default; turn it off where that matters. |
| Login as | Administrators of the instance can log in as one of its users, after confirming their own password and, if they use one, their second factor. Off by default. See The partner portal. |
| Use Captcha verification | Prospects have to solve a captcha when they register a trial account themselves |
Passwords and keys are never shown again once saved. The fields show a placeholder, and saving without changing it keeps the stored value.
We set some rules for you, such as the minimum password length and how long a session lasts. See Configured for you on request.
Contact our team to discuss the details.
«Veeting» is a registered trademark of Veeting AG. Veeting AG is a registered business in Zurich, Switzerland. All Rights Reserved. © 2014 - 2026, Veeting AG.