Skip to main content
Your credential identifies a user. That user’s current membership, workspace role, and any additional operation-specific requirements determine access.

Labs API keys

Create an API key in API & Developers → API keys. Send both headers on every API-key request:
Keys belong to your account. They are not restricted to the workspace selected when you create them. Each request selects a workspace with its header, and access follows your current role there. Changing workspace in the console does not change this header. See workspaces and permissions.

OAuth user access tokens

Operations that support user access tokens accept:
Obtain a token through an authorized Labs OAuth client. Contact your Labs administrator if your application does not have one. User tokens have a maximum lifetime of 15 minutes; let your OAuth client obtain fresh tokens when needed. Keep integration credentials in your server’s secret store. Bearer requests use your account’s selected workspace. Their workspace is not selected by the API-key workspace header.

Operation-specific requirements

Each endpoint describes its accepted credentials and required role. Outbound call and campaign operations require a user bearer token with the additional Labs super_user role; API keys cannot authenticate to those operations. A workspace Owner role does not grant super_user. Telephony operations can have provider-specific or outbound-calling restrictions; check the operation before calling it. Send one credential type per request. Do not send an API key as a bearer token. The former X-API-Key header is not supported.

MCP connections

The MCP server uses a separate Labs OAuth flow and resource URL. It does not accept the API keys or REST tokens described here. Follow MCP authentication. For failed requests, see API errors. For key expiration, rotation, and revocation, see API keys.