If you need to build a fully custom UI, use the Daily call object.

Domain, room and meeting token properties

Many parts of the in-call experience can be customized by changing domain, room or meeting token properties.

Properties that can be set at both the domain and room level

If a property is set for the domain and also set at the room level, the room setting takes precedence.

Properties that can be set at both the room and meeting token level

If a property is set for the room and also set in the meeting token, the meeting token setting takes precedence.

These UI-related properties can be specified at the room level:

And these UI-related properties can be configured using meeting tokens:

UI flows when a user joins a meeting: managing room access and pre-meeting experiences

If you’re using Daily Prebuilt, setting enable_prejoin_ui to true at either the room or domain level turns on a lobby experience for call participants. They can check their camera and microphone before joining a call, and also wait to be admitted by the host if the room is private and they are joining without a token.

You can also take advantage of a suite of Daily methods and events geared towards implementing a custom lobby if you're building on top of the Daily call object and using WebSocket signaling (signaling_impl = 'ws' in your room config). With these methods and events you can:

• Determine the local participant's access level, even before attempting to join a meeting: preAuth(), accessState(), 'access-state-updated'
• Request elevated access to a meeting: requestAccess()
• Manage pending access requests (if you're a meeting owner): waitingParticipants(), updateWaitingParticipant(), updateWaitingParticipants(), 'waiting-participant-added', 'waiting-participant-updated', 'waiting-participant-removed'

These methods and events are also all available when using Daily Prebuilt if you'd like to build similar waiting room experiences around the call embed.

UI flows when a user leaves a meeting

Two properties control what happens when a user leaves a meeting from a standalone browser tab: close_tab_on_exit and redirect_on_meeting_exit.

If close_tab_on_exit is set to true, the browser tab closes when the user clicks the leave meeting button in the in-call menu bar.

If the redirect_on_meeting_exit property is set, the property value will be interpreted as a URL that the browser should redirect to when the user clicks the leave meeting button. A query string that includes the parameter recent_call=<domain>/<room> is appended to the URL.

📘

By default, there is no leave meeting button in the iframe embedded UI; you control that meeting flow with your own UI code outside the iframe. Or you can add a leave call button to the embedded UI with our Javascript API.

API plan level, and Daily branding

There are currently two different "flavors" of UX defaults for Daily rooms: with Daily branding (Free and Launch plan), and without Daily branding (Scale plan).

This applies to all of the following cases:

• The room was created by an API call,
• The call UI is embedded in an iframe,
• The call was joined via a URL that includes a meeting token

To remove Daily branding, upgrade to the Scale plan. The free and Launch plans include Daily branding. (See API pricing plans.)

Here's a table listing the differences between the two different UX variants: