Skip to content

Workspaces and access

A workspace is the account everything belongs to. Agents, People, channels, media, API keys, and branding are all owned by exactly one workspace, and nothing is shared between workspaces.

In the Agent API the same thing is called an org, and it appears in every management path as /v1/orgs/{org}/…. Workspace is the operator-facing word and org is the API word for one concept.

The workspace is also the isolation boundary. Every query the platform runs is filtered by the caller's workspace, so a member of one workspace cannot read another's data even when they know an agent's id.

Members and roles

A person joins a workspace as a member and holds exactly one role in it. The four roles form a ladder, and each one includes everything below it.

Role What it can do
Viewer View most resources, and try agents in the emulator.
Editor View, create, update, and delete most resources.
Admin Everything an editor can, plus administrative actions such as minting API keys and managing connections.
Owner Full control, including changing who the members are and what roles they hold.

In practice the split falls where you would expect. Reading an agent's configuration, its conversations, and its People needs viewer. So does trying an agent in the emulator, inbound or outbound, with the agent's existing personas, and resetting a persona to start over: nothing done there reaches a real person. Creating or editing personas needs editor. Changing Behavior, Knowledge, channels, and outreach needs editor. Minting an API key and connecting an outside account such as Google Calendar need admin. Adding a member or changing a role needs owner.

Roles are per workspace. Someone who works across two workspaces holds a role in each.

What a role does not control

Roles are the only access dimension. There are no permission bundles, no per-agent roles, and no per-resource sharing: a member who can edit one agent can edit every agent in that workspace.

When a customer should reach exactly one agent, give them their own workspace rather than a narrower role.

API keys

An API key belongs to one workspace and carries the scopes chosen when it was minted, such as agents:read or people:write. A key never exceeds the role of the member who minted it, so an editor's key cannot perform admin actions even when it carries the scope.

Keys are shown once, at creation. Anychat stores only a hash and cannot show a key again.

The Messaging API uses a different credential: a per-agent access token, with no scopes and no roles, where the token is the agent. See Reference.

Anychat staff access

Anychat operators can act inside a customer workspace to run provisioning and support. Those actions are recorded and attributed, and they follow the same role ladder rather than bypassing it.

What's next