Overview

What this reference explains

Team is the end-user workspace collaboration surface. Each user gets a personal workspace when their account is created. Owners invite teammates by email, assign roles, rename the workspace, and revoke pending invitations. Invitees preview and accept a link (registering if needed).

In the product UI the sidebar label is Team (route /team). API paths use /workspaces and /workspace-invitations. The feature registry key is workspaces.

Roles

• owner — full control; can manage members and invitations. Cannot be demoted or removed via the API.
• admin — can rename the workspace; cannot manage members.
• member — can manage workspace resources in other modules; not team admin.
• viewer — read-oriented access.

Invitations and role changes accept only admin, member, or viewer.

No create-workspace endpoint

There is no POST /workspaces. Personal workspaces are provisioned on user registration. This module lists workspaces the caller belongs to, shows one, and renames it.

Response envelope

Team uses {"data": ...} for reads and {"message": "...", "data": ...} (or message-only) for writes — not the panel {"success": true} envelope. Invitation accept for a new registrant also returns a top-level Sanctum token.

Feature availability

Gated by the workspaces feature. When disabled for an authenticated caller, management endpoints under /workspaces return 403 with {"message":"This feature is not enabled for your account. Please contact your administrator.","feature":"workspaces"}. Public invitation preview/accept only enforce that check when a user is already authenticated.

Out of scope here

• Reseller staff invitations (/reseller-staff-invitations, /reseller/staff).
• Workspace public API keys and the X-Workspace-Id request header used by other modules for scoping.