Cloudflare RealtimeKit Tokens: Set Expiry, Revoke and Refresh

Identify the participant token first

When your backend adds a user to a meeting through the Add Participant API, it receives a participant ID and an authentication token. After the user chooses to join, the frontend passes that token to the RealtimeKit SDK. The meetingId and participantId fields scope the token to one participant in one meeting.

This guide concerns that participant JWT, or JSON Web Token, rather than a credential used to administer a Cloudflare account. While a token remains valid, its participant can join multiple live sessions of the same meeting over time. Leaving one session does not mean the token has expired.

Where do the start and expiry fields go?

When adding a participant, put not_before and expires_on inside the request’s token object. When refreshing a participant token, put them in the refresh request body instead. Both are optional: not_before defaults to the current time, and expires_on defaults to 100 days after not_before.

not_before may be in the past, expires_on must be in the future, and the entire validity window cannot exceed 100 days. If you supply only one field, check the resulting window against the other field’s default. Optional fields do not make every combination valid.

Use RFC 3339 timestamps with a timezone offset, such as 2026-12-01T15:00:00Z, where Z means UTC. The response returns the issued token’s start and expiry times in UTC. Do not send a local clock time without its timezone as though it were an equivalent timestamp.

Match the event window and check its boundaries

For a hypothetical interview allowing entry on December 1, 2026 from 15:00 to 17:00 UTC, set not_before to 2026-12-01T15:00:00Z and expires_on to 2026-12-01T17:00:00Z inside the Add Participant token object. This is an illustrative configuration; the expiry must still be in the future when the request is made.

With an authorized test participant, check joining before the window, within it and after expiry, using the returned UTC times as a reference. This is a suggested check, not a real meeting test performed for this article. The announcement and reviewed documentation do not specify whether expiry alone disconnects an already connected session, so do not promise that this setting forcibly ends a meeting at a scheduled time.

Refreshing leaves previously issued tokens valid

Your backend can call Refresh Participant Token before or after expiry. The new token uses the existing participant record, including its participant ID and preset, which defines its role and permissions. Refreshing does not require treating the user as a newly added participant.

A refresh does not invalidate earlier tokens. Each remains valid until its own expiry. If you need to withdraw access that was shared or is no longer needed, issuing a fresh token alone is insufficient: explicitly choose revocation of the target token or deletion of the participant.

Revoke one token or immediately block them all?

Revoking an individual token leaves other tokens issued to that participant valid. Rejection of the revoked token can take up to 60 seconds to propagate to every location, and the participant may rejoin with it during that interval. A successful revocation response is not proof that every location has already blocked it.

To immediately block access through all of a participant’s tokens, the documentation directs you to Delete Participant. Revoking a token or deleting a participant also removes that participant from the current active meeting session. Choose the scope carefully: deletion affects all their tokens and is not equivalent to ending just one older token.

Individual token revocation does not require changing the entire meeting to INACTIVE. Confirm the meeting, participant and intended scope before acting so that handling one person’s access does not stop the whole meeting.

Use the failure reason and keep billing claims narrow

Expired, not-yet-valid and revoked tokens cannot join. The UI and Core SDK report the token as invalid. The API error’s reason can be participant_token_expired, participant_token_not_yet_valid, participant_token_revoked or participant_token_invalid. Use the actual reason to check the time window and revocation state rather than attributing every failed join to network egress.

RealtimeKit rejects these invalid tokens before the participant enters the meeting stage, so those rejected joins are not billed. This does not make successful participation, other usage or the entire service free. The announcement and participant documentation do not establish new plan or country eligibility or numeric prices; check your actual account and current billing terms before implementation.