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 authenticates browser signaling plus public-call and space admission requests.
| Credential | Used As | Purpose |
|---|---|---|
| rad_sk_... | Authorization: Bearer rad_sk_... with project id in the path | Trusted backend calls, including P2P call creation and room creation. |
| rad_pk_... | Authorization: Bearer rad_pk_... for HTTP; publicKey query param for WebSocket | Browser signaling and public-call or space admission. |
| ct_... | callToken query param for P2P, roomToken query param for rooms | Single-use participant access to a specific call or room. |
Encryption baseline
How encryption works
P2P media and data use WebRTC's DTLS/SRTP and DTLS/SCTP transports. SFU rooms additionally use Insertable Streams with client-side keys and per-frame encryption by default, so the SFU only forwards encrypted media payloads.
Typical auth flow
- 1 Your backend authenticates the user through your own auth system.
- 2 Your backend creates a call or room using the secret key and project id.
- 3 Your backend sends one participant token to each approved browser session.
- 4 Each browser uses its token to join the call. The token is consumed on first use.
- 5 Your backend mints another token when an unused private token must be replaced.
Environment variables
All server SDKs automatically read these environment variables when explicit options are not provided.
| Variable | Description |
|---|---|
| RADIST_PROJECT_ID | Your project id, used as the path parameter in all API calls. |
| RADIST_KEY | Your secret key (rad_sk_...). Never expose this in browser code. |