Scopes
A scope is a coarse-grained permission attached to an API key. v0.9.11 exposes a deliberately small set focused on call tokens — the primary mechanism for the SDK to start WebRTC sessions.
Available scopes
| Scope | Allows… |
|---|---|
CREATE_CALL_TOKEN | Mint a short-lived call token bound to a specific WebRTC-enabled endpoint. The token is what your client app exchanges for a session. |
READ_CALL_TOKEN | Read or query existing call tokens (e.g. to confirm status). Does not allow minting new ones. |
READ_TEAM_APPS | List the team's apps and their metadata (IDs, names, endpoints). Useful when your integration needs to discover which app to call into rather than hard-coding endpoint IDs. |
All three scopes apply to the WebRTC-gated portion of TelAPI — keys with these scopes are only useful on a platform where the webrtc feature flag is on. The async LLM webhook endpoint (/api/v1/webhooks) uses its own auth and is not controlled by API-key scopes; see Webhooks.
The team's available scopes are configured by a platform admin under Admin → Teams → API Access Configuration. A team admin then chooses any subset of the team's available scopes when creating each key.
Picking the right scopes
- Server that mints call tokens for browser clients —
CREATE_CALL_TOKEN. This is the common case: your backend authenticates your end-user, then asks Delphi for a one-shot call token, and hands the token to your client. - Server that picks an app/endpoint dynamically before minting — add
READ_TEAM_APPSso your backend can list the team's apps and select the right endpoint at runtime. - Auditing / read-only integration —
READ_CALL_TOKEN(and optionallyREAD_TEAM_APPS) only. - Both/all — give the key the scopes it actually needs. Most teams have a single backend that mints tokens; a separate read-only key is reasonable for analytics or dashboards.
Avoid issuing one wide-scope key shared across services. Prefer one key per integration point so that rotation and revocation can be done independently.
Future scopes
The scope set will grow as more of the platform is exposed via TelAPI. Each new scope follows the same model: defined per-platform, allowed per-team, selected per-key. Watch Release notes for additions.
See also
- Authentication — the request header and key model.
- Call tokens — the workflow
CREATE_CALL_TOKENenables. - Webhooks — async LLM callbacks (different auth, not scope-controlled).
- API keys (user guide) — admin workflow for keys.