Configuration

Keys, Auth, and Encryption

Each Radist project uses three credential types. Understanding how they fit together is the foundation for a secure integration.

Credential overview

Your project starts with a public key. Create secret keys from the project Keys section and store them when they are shown — Radist only displays a secret key once. Keep secret keys in trusted server code. The public key can be used by browser clients to mint additional participant tokens and authenticate the signaling socket.

CredentialUsed AsPurpose
rad_sk_...Authorization: Bearer rad_sk_... with project id in the pathTrusted backend calls, including P2P call creation and room creation.
rad_pk_...Authorization: Bearer rad_pk_... for HTTP; publicKey query param for WebSocketAdditional browser token minting and WebSocket signaling authentication.
ct_...callToken query param for P2P, roomToken query param for roomsSingle-use participant access to a specific call or room.

Encryption baseline

How encryption works

WebRTC media uses SRTP with DTLS keying, and WebRTC data channels run over SCTP protected by DTLS. Radist should be treated as the setup and signaling control plane. The browser WebRTC transport handles end-to-end encryption for media and data between peers.

Typical auth flow

  1. 1 Your backend authenticates the user through your own auth system.
  2. 2 Your backend creates a call or room using the secret key and project id.
  3. 3 Your backend sends one participant token to each approved browser session.
  4. 4 Each browser uses its token to join the call. The token is consumed on first use.
  5. 5 The browser can mint a replacement token with the public key if the original expires before use.

Environment variables

All server SDKs automatically read these environment variables when explicit options are not provided.

VariableDescription
RADIST_PROJECT_IDYour project id, used as the path parameter in all API calls.
RADIST_KEYYour secret key (rad_sk_...). Never expose this in browser code.