Thanks — I’m responding to your question about how long a prefetched LiveKit token will remain valid and whether you need to refresh it before room creation. • Token lifetime is determined by the token’s

exp

(expiration) claim at generation. When you generate the token on your server you set how long it’s valid; there’s no fixed, implicit LiveKit default that will override that. • A prefetched token that hasn’t been used to connect becomes invalid after its

exp

time is reached. If a client attempts to connect with a stale token the server will reject it with a token-expired error. • If a token is already used to establish a connection, LiveKit keeps the session active even after the token’s

exp

time (connected sessions are not torn down immediately when the token expires). • Practical suggestion: pick a TTL that matches your prefetching window. Common choices are 10–60 minutes depending on how long you expect tokens to sit unused. If you need to guarantee freshness for every immediate room-creation attempt, generate the token on-demand; if you want to prefetch, set a sufficiently large

exp

and track the timestamp so you can refresh before it expires. If you’d like, tell me: • How long you plan to prefetch before room creation (typical interval), and • Whether prefetched tokens will be used only once (one client connects) or may be handed out to multiple clients. I can then recommend a concrete TTL and a simple refresh strategy for your use case. Sources: Troubleshooting 401 Unauthorized and Token Errors | LiveKit | Troubleshooting 401 Unauthorized and Token Errors | LiveKit | server-sdk-kotlin | livekit/livekit_composite | DeepWiki, with interactive elements