Comparing domain, room, and meeting token REST API configurations for Daily calls

If you’ve built with Daily’s APIs before, you will likely be familiar with the various ways developers can configure their domains, rooms, and meeting tokens.

In today’s tutorial, we’ll take a look at what domains, rooms, and meeting tokens control when it comes to building WebRTC video and audio-only apps with Daily. We’ll also review their order of priority, which settings override other ones, and how to use Daily’s dashboard or REST API to quickly set various configurations.

For those of you who have not worked with Daily APIs yet – fear not! – we’ll review what all of these terms mean and see how different settings can interact with each other.

Domains, rooms, and meeting tokens defined

Let’s start by defining some of the terms we’ve mentioned so far:

• Daily domain: Domains represent your top level object in the Daily API. Once a domain is created and has an account associated with it, you can begin creating Daily rooms to host video calls. Domains can have multiple Daily accounts associated with them. For example, a company using Daily to add video chat to their app may have one domain they’re using with separate accounts for each employee. Your domain can be found in the top-left corner of the Daily dashboard.

• Daily room: Rooms are used to host Daily video and audio calls and represent the location of the call. Think of going into an office building for a meeting – you need to know which room to enter to be in the same space as the people you're meeting with. Rooms are associated with your Daily domain. Each Daily room will have a unique room URL that participants can join to attend a call.

• Daily meeting token: Meeting tokens are unique tokens used to control room access and authorize specific call attendees. Additionally, they provide a way of updating session configurations on a per-user basis. Think of them as a way for a call participant to show ID confirming they're allowed to join the call with certain privileges.

Daily apps will use a room URL for users to be able to join a specific room. Room URLs include your domain and the room name, so those values are already set when a user goes to join a Daily call.

Meeting tokens, on the other hand, should be passed as an option in Daily’s factory methods or the join() method for the intended participant. Meeting tokens are considered optional for many use cases so not every app will use them. (See our room control guide for additional information on meeting tokens.)

callObject.join({
	url: 'https://your-domain.daily.co/your-room-name',
	token: DAILY_MEETING_TOKEN,
});

Room URLs can be found or created in the Daily dashboard under the Rooms tab or, if you’re using the REST API, the room URL is returned in the GET and POST endpoint responses.

Note: The Daily dashboard is an interface for interacting with the Daily REST API. Therefore, anything you can do with the dashboard, you can also do yourself with the REST API.

Shared settings between domains, rooms, and tokens

Domains, rooms, and tokens can each be configured with a wide range of properties. Some of the properties available will be specific to domains, rooms, or tokens and some will be shared across a combination of them.

Domain configurations will be applied to all rooms and participants associated with that domain.

Room configurations are more specific than domain configurations and are applied only to the specified room.

Meeting tokens, which are used on a per-user basis, have a list of configurations that are even more specific than room settings, since they only affect the participant joining the call with that meeting token.

If you’re a front-end developer or familiar with CSS, this may be reminding you of CSS’s rule of specificity. In this comparison, domains are like elements, rooms are like classes, and meeting tokens are like IDs.

Overriding settings and understanding which settings take priority

Given that domains, rooms, and meeting tokens have different levels of specificity, their rules for specificity can also be used to override existing settings. (Again, think of how CSS styles can override each other.)

In terms of configurations, meeting token settings will always override room or domain settings when the same property is set on them. Similarly, room settings will override domain settings for the same property.

Domain settings are the most general and the easiest to override.

Let’s look at an example of how to take advantage of this.

Turning off Daily Prebuilt’s prejoin UI for a specific room

Let’s say you’ve built an app that has Daily Prebuilt embedded. As a general rule, you have the domain property enable_prejoin_ui set to true because you know people like to test their devices before joining a call.

Here’s an example cURL command of how to turn on this setting at the domain level:

curl --request POST \
--url https://api.daily.co/v1/ \
--header 'Authorization: Bearer <API-KEY>' \
--header 'Content-Type: application/json' \
--data '{"properties":{"enable_prejoin_ui":true}}'

Now let’s say you have one call a week with a colleague where your cameras are always off (so you don’t even care if you have food in your teeth). Your colleague has asked to turn off the prejoin UI to make joining the call even faster.

Accomplishing this is quite straightforward: you can leave your domain settings to have enable_prejoin_ui set to true and create a Daily room that has the enable_prejoin_ui property set to false. The result will be that all rooms will default to the domain settings, but your one room with the prejoin UI turned off will use the room setting because it is considered more specific.

curl --request POST \
--url https://api.staging.daily.co/v1/rooms/ROOM-NAME\
--header 'Authorization: Bearer <API-KEY>' \
--header 'Content-Type: application/json' \
--data '{"properties":{"enable_prejoin_ui":true}}'

Meeting tokens to trump them all

As mentioned, meeting tokens have the highest specificity. Let’s look at another example of how to take advantage of this:

Let’s say you don’t want participants in a call to record a meeting. No problem – just make sure the room property enable_recording is set to false.

curl --request POST \
--url https://api.staging.daily.co/v1/rooms/ROOM-NAME\
--header 'Authorization: Bearer <API-KEY>' \
--header 'Content-Type: application/json' \
--data '{"properties":{"enable_recording":false}}'

But what if you want a specific meeting owner to be able to start a recording? You can do that by creating a meeting token for that room with is_owner and enable_recording properties both set to true. This way only the specific participant joining with that token will be able to start the recording.

curl --request POST \
--url https://api.daily.co/v1/meeting-tokens \
--header 'Authorization: Bearer <API-KEY>' \
--header 'Content-Type: application/json' \
--data '{"properties":{"is_owner":true,"enable_recording":true}}'

These are just a couple examples of how to override shared properties in the Daily REST API, but the takeaway is the same for each of them:

• You can override domain settings with room or token settings of the same name.
• You can override room settings with token settings of the same name.

Wrapping up

We hope this tutorial helps you get the most out of your domain, room, and token settings available through Daily’s REST API. To learn more about room control and different configurations you can use, check out this curated list of Daily guides:

• Understanding calls with Daily’s dashboard
• Configuring room settings
• Meeting access control
• How to configure large calls of up to 15,000 participants