Generating self-signed tokens
Create a JWT using your domain’s API key as the secret. The payload must include:r: the room nameiat: the current time (Unix timestamp)d: yourdomain_id
domain_id is available from the domain configuration endpoint.
To learn more about and test your tokens, refer to https://jwt.io/.
Token property abbreviations
Self-signed token properties use shortened field names in the JWT payload:Restricting exit redirects
A self-signed token is validated by its signature alone, so any account able to sign tokens for your domain can setrome (redirect_on_meeting_exit) to any destination. Because the meeting link itself is on a daily.co subdomain, a participant has no visual cue that leaving the call will send them somewhere else.
If that matters for your deployment, set the redirect_on_meeting_exit_allowed_hosts property on your domain. It is optional and unset by default, in which case any destination is permitted and behavior is unchanged. Once set, it is enforced for self-signed tokens, tokens created through the API, and the domain-level redirect_on_meeting_exit:
*. entry matches subdomains only and not the apex domain, so list both if you need both. Use a bare scheme ending in : to permit a mobile app deep link.
A destination that is not on the allowlist is dropped rather than rejected: the participant joins and leaves the call normally, they are just not redirected. This is worth knowing when testing, because there is no client-side error to observe.
Regardless of whether an allowlist is configured, exit redirects to
javascript:, data:, vbscript:, blob: and file: URLs are always rejected.Permissions abbreviations
Thepermissions property uses the following abbreviated structure: