Token format
Scoped tokens use a prefix that identifies the scope:vxa_bot_VDXyV683YBvsCRrlUtnWWKLC0qTtGNaxGgVS8F5s— bot scopevxa_tx_eFgh1234abcd5678...— transcription scopevxa_browser_xyz789...— browser scope
vxa_ prefix) retain full access for backward compatibility.
Scopes
| Scope | Prefix | Access |
|---|---|---|
bot | vxa_bot_ | Bot operations: start/stop bots, check bot status, webhooks, voice agent |
tx | vxa_tx_ | Transcription and meeting data access: view meetings, read transcripts |
browser | vxa_browser_ | Browser sessions: VNC, CDP, workspace |
Enforcement
Scope enforcement happens at the service level, not the gateway. Each backend service declares which scopes it accepts:| Service | Endpoint examples | Allowed scopes |
|---|---|---|
| meeting-api | POST /bots, GET /bots/status | bot |
| meeting-api | GET /meetings, GET /transcripts | tx |
| api-gateway | POST /browser-sessions | browser |
403 Forbidden:
Creating scoped tokens
Create tokens via the admin API: Single scope:scope parameter accepts: bot, tx, browser. Use scopes (plural) with comma-separated values to grant multiple scopes to a single token.
Using scoped tokens
Use scoped tokens the same way as regular tokens — via theX-API-Key header:
Legacy tokens
Tokens created before scoping was introduced have novxa_ prefix. These tokens retain full access to all endpoints for backward compatibility.
To migrate a legacy token to a scoped token:
- Create a new scoped token with the desired scope
- Update your application to use the new token
- Revoke the legacy token via
DELETE /admin/tokens/{id}