The "meeting token" object
"Meeting tokens" control room access and session configuration on a per-user basis.
A participant can join a non-public room with a valid meeting token. For private or public rooms, you can use meeting tokens to configure how a participant experiences the meeting (e.g. what call features are available).
Meeting token configuration properties set three things: room access, meeting time limits, and participant details, including their meeting permissions and available features.
A meeting token without a
room_name property allows access to any room in your domain. Always set the
room_name property when you are using meeting tokens to control room access.
See our guide to controlling room access for more details.
Your tokens are unique to your domain and rooms. Tokens from another Daily domain can never grant access to your rooms.
Two properties control how long a user is allowed to stay in a meeting.
eject_at_token_exp is set to
true, the user is kicked out of the meeting when the token expires. If the room is not public, then the user will not be able to rejoin the room.
eject_after_elapsed property is the maximum number of seconds the user can stay in the meeting. The user will be kicked out
eject_after_elapsed seconds after joining the meeting. If the meeting token has expired (and the room is not public) the user will not be able to rejoin the room. If the meeting token hasn't expired, of course, the user could reuse the meeting link and token to rejoin the room.
The two token properties
eject_after_elapsed override the two room properties
eject_after_elapsed. If either of the token properties are set, the two room properties are completely ignored for the current meeting session.
You can use tokens to configure when a participant can join a meeting, when their access expires, and the call features that are enabled for each participant in a meeting. For example, you could set up a virtual classroom so that only one participant in the meeting (the teacher) can broadcast audio and video (to the students).
For a full descriptions of all properties, please see the table below.
Setting a meeting token for a call participant via a factory or
join() method property is the only way Daily recommends using meeting tokens, for security reasons.
For example, to give a specific participant special access when they join a meeting (e.g. admin privileges), you'd write something like:
Under the covers, meeting tokens are JSON Web Tokens. They are signed, but not encrypted, so you can decode the raw token yourself, if you're interested. Note that this means you should never put information that you want to keep secure into a meeting token.
You don't ever need to delete a meeting token. Meeting tokens are just cryptographically signed chunks of information that are validated by our API endpoints; they don't exist as server-side resources.