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).
You can create and validate meeting tokens.
Meeting token configuration properties set three things: room access, meeting time limits, and participant details, including their meeting permissions and available features.
Room access
room_name
Always set room_name
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.
Meeting time limits
Two properties control how long a user is allowed to stay in a meeting.
If 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.
The 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_at_token_exp and eject_after_elapsed override the two room properties eject_at_room_exp and eject_after_elapsed. If either of the token properties are set, the two room properties are completely ignored for the current meeting session.
Meeting time limits tutorial
Participant details, meeting permissions, and available features
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).
nbfexpis_owneruser_nameuser_idenable_screensharestart_video_offstart_audio_offenable_recordingstart_cloud_recordingPay-as-you-goclose_tab_on_exitredirect_on_meeting_exitlang
For a full descriptions of all properties, please see the table below.
Using meeting tokens
To use a meeting token, pass it as a property to the factory method of your choice, or via the join() method.
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:
Heads up!
Don't forget to generate your meeting tokens server-side to keep production applications secure.
Read about how to set up an instant Daily server with Node.js and Glitch.
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.
Learn more about meeting tokens