Skip to main content
Never import digital-human/server into a client component or place an API key in browser JavaScript, HTML, local storage, URLs, analytics, or logs.

​
Server and browser boundary

Your server uses the API key to create, inspect, refresh, and end sessions. It returns only this browser-safe value:
The token is a short-lived bearer credential restricted to its LiveKit room. Treat it as sensitive while it is valid:
  • Return it only to an authenticated, authorized browser.
  • Use Cache-Control: no-store on responses containing it.
  • Do not include it in a URL or persistent browser storage.
  • Redact it from application and error logs.

​
Use the smallest scopes

API keys can have these session scopes: Use separate keys when applications need different permissions. Rotate keys according to your organization’s credential policy and revoke unused keys.

​
Protect application routes

The server routes that create or refresh browser connections should enforce your own authentication and authorization. A safe route should also:
  • Validate the calling user’s access to the requested digital human.
  • Rate-limit session creation.
  • Generate or validate idempotency keys.
  • Avoid returning upstream error details that your users should not see.
  • End abandoned sessions when your product knows they are finished.