Skip to main content
Everything in Bandwidth Agent Builder is scoped to a workspace. When you join a workspace you are given a role, and that role decides what you can do inside it — from read-only viewing all the way up to managing billing and deleting the workspace. Roles are per workspace: the same person can be an Owner of one workspace and a Viewer of another. Your active workspace (and therefore your current permissions) is whichever one is selected in the workspace switcher.

​
The four roles

Roles are hierarchical: every Owner can do everything an Admin can, every Admin can do everything an Editor can, and every Editor can do everything a Viewer can.

​
What each role can do

Editor vs Admin, in one line: Editors build (create, edit, run), Admins manage (delete, integrations, members). Deleting content and configuring integrations/AI connections are intentionally Admin-and-above.

​
Viewer

Read-only. Viewers can open agents, browse the knowledge base, and review calls, runs, and dashboards — but they cannot create, edit, run, or delete anything. Buttons for those actions are hidden, and the API rejects the request if attempted.

​
Editor

Editors build the product: create and edit agents, tools, knowledge bases, campaigns, and folders, and run/test them (test calls, starting campaigns, publishing agents). Editors cannot delete content or touch integrations, AI connections, or members.

​
Admin

Everything an Editor can do, plus the “manage” surface: delete content, configure integrations (telephony, webhook credentials) and AI connections (model/provider keys), and manage members (invite, remove, revoke invites).

​
Owner

Full control. Everything an Admin can do, plus changing other members’ roles, billing, and deleting the workspace. The first person in a workspace is its Owner, and a workspace always keeps at least one Owner (the last Owner cannot be removed or demoted).

​
How permissions are enforced

  • Server-side first. Every action that creates, edits, deletes, or configures is checked on the API against your role in the active workspace. An insufficient role gets 403 Forbidden regardless of what the UI shows — this is the real guard.
  • UI reflects your role. Controls you can’t use (create, delete, integration settings, member management) are hidden or disabled so you don’t hit dead ends.
  • Reads are open to all members. Any role can view the data in workspaces they belong to.
Labs Auth proves user identity; Bandwidth Agent Builder still applies the active workspace membership and role to every authenticated request.

​
Managing roles & access

  • Assigning a role happens when you invite someone. From Team members → Invite members, pick the workspace(s) to grant access to and choose a role for each — one invite link can grant access to several workspaces, with a different role in each.
  • Changing a role later is done by an Owner from the Team members page.
  • Inviting is available to Admins and Owners, and you can only invite people to workspaces where you are an Admin or Owner.
See Workflows & Agents for what you build inside a workspace, and Campaigns for running agents at scale.

​
Additional Labs access

Phone-call controls and campaigns also require the Labs super_user role. Workspace roles still apply: an Editor or higher can initiate calls, while changing telephony configuration requires Admin or Owner access. Labs API keys act as their owner and retain that user’s workspace permissions. They cannot use bearer-only call or campaign endpoints. Manage keys through the Labs platform.