Workspaces and Teams
Share an Action inbox safely with workspace roles, invitations, and explicit ownership boundaries.
Workspaces are the tenant boundary for people, Sources, Actions, notifications, and audit history. Every account receives a personal workspace; inviting another person turns that workspace into a team workspace.
Switch before you operate
The active workspace controls the dashboard inbox and the API's user-scoped reads. Select the workspace that owns the Action before reviewing, assigning, or changing team settings.
Roles at a glance
| Role | Can review and decide | Can claim | Can assign or unassign | Can manage people and policy |
|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes | Yes |
| Approver | Yes | Yes | No | No |
| Viewer | Read-only | No | No | No |
Decisions require an owner, admin, or approver membership. Assignment changes require an owner or admin. The API checks the active membership on every user-scoped operation.
Members
See active people, their email, role, and join time in Settings → People and routing.
Invitations
Invite an email address with an admin, approver, or viewer role; each invitation has a bounded lifetime.
Routing
Send open Actions to a named reviewer or let an approver claim one from the shared queue.
Invite a teammate
Team invitations require the Team plan. Owners and admins can create them from Settings or the API.
1. Choose the email and role
The invitation accepts admin, approver, or viewer. The email is normalized and must match the account that accepts the invitation.
2. Create the invitation
curl -X POST https://api.actionbox.cloud/v1/workspaces/invitations \
-H "Authorization: Bearer $ACTIONBOX_USER_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"email": "[email protected]",
"role": "approver",
"expires_in_days": 7
}'The allowed lifetime is 1–30 days and defaults to 7. The response contains the raw invitation token and acceptance URL once. Send that link through a trusted channel.
3. Accept the invitation
The invited person signs in with the invited email, then submits the token to POST /v1/workspace-invitations/accept. Acceptance switches their active workspace to the invited workspace.
There is only one usable pending invitation for an email in a workspace. Creating a replacement supersedes the older pending credential. Owners and admins can list or revoke pending invitations.
Manage membership safely
Owners and admins can use these user-session endpoints:
GET /v1/workspaces
POST /v1/workspaces/select
GET /v1/workspaces/members
PATCH /v1/workspaces/members/{user_id}
DELETE /v1/workspaces/members/{user_id}The service prevents a workspace from losing its last owner. Only an owner can change owner roles or remove an owner or admin. Removing a member immediately revokes their membership; open Actions assigned to them are returned to the unassigned queue, while terminal history remains intact.
Keep boundaries clear
- A Source belongs to one workspace and cannot address another workspace through its key.
- A user sees Actions and notifications for the active workspace, subject to the Action's retention window and filters.
- Viewer access is read-only; it does not grant claim, decide, assignment, invitation, or role-management capability.
- Workspace invitation tokens are bearer credentials. Treat them like passwords and do not include them in screenshots or logs.
Decision access is not assignment access
An approver can claim and decide an open Action, but only an owner or admin can explicitly route it to another member. Use Assignments and routing for the shared-inbox workflow.
Next: Notifications, Sources and keys, or Decisions and outcomes.