Operational units within an organization. Workspaces activate and own Service Lines, hold team membership, and provide the operational scope for all delivery activity.
The Scrums.com API is planned and not yet publicly available. Endpoints and behaviour are subject to change before release.
A workspace (WS-*) is the operational unit within an organization. It is where delivery happens: Service Lines are activated within workspaces, teams are assembled within workspaces, and integrations connect at the workspace level.The platform hierarchy is ORG-* owns WS-* which activates LIN-*. Workspaces are not projects. Projects are labels applied to work; workspaces are structural operational containers.
Most resource operations are scoped to a workspace. API tokens can be narrowed to a single workspace to enforce isolation between teams or business units.
Users are added to workspaces with a role. Workspace roles are: admin, member, viewer. Organization-level owner and admin members implicitly have access to all workspaces in the org.
A workspace activates Service Lines. Every LIN-* belongs to exactly one workspace. Usage, capacity, and observability queries are most commonly filtered by workspace_id.
Large organizations typically run multiple workspaces representing business units, product areas, or engineering tribes. Each workspace has its own: team, Service Lines, integrations, and budget visibility. Billing rolls up to the organization.
Align workspaces with operational teams, not business entities. A workspace is where a team works day-to-day. Use project labels and Service Line tags to represent business groupings.
Scope API tokens to workspaces. For integrations that operate within a single team, issue tokens scoped to that workspace. This prevents cross-team data access and simplifies debugging.
Do not archive workspaces with active Service Lines. Close all Service Lines first. Archiving a workspace with active LIN-* will block further metering and may cause invoicing gaps.