Workspaces

Slab5 separates the account boundary from the operational workspace boundary.

For the end-to-end developer path, see Personal workspace lifecycle.

Account and tenant model

A Slab5 tenant represents one account. In the hosted control plane:

A personal Slab5 tenant belongs to one signed-in WorkOS/AuthKit user.
A shared Slab5 Team maps to one WorkOS organization behind the scenes.
A WorkOS user can belong to multiple Slab5 Teams through WorkOS organization memberships.

WorkOS owns human authentication, social login, MFA, team membership, and invitations. Slab5 owns workspaces, module access, credentials, audit events, usage events, and billing policy.

Supported WorkOS roles map into local Slab5 workspace roles for control-plane authorization. Unknown team roles default to local member access rather than admin access.

The hosted dashboard separates account-level and active-workspace navigation.

Account-level pages manage resources that belong to the selected account:

Teams
Workspaces
Billing

Active-workspace pages manage or inspect the currently selected workspace:

Overview
Modules
Data & Insights
Webhooks
Members
API Keys
MCP Clients
API Playground
Usage
Audit Log
Settings

Usage and Audit Log views are scoped to the active workspace, not every workspace in the account.

Workspace boundary

A workspace belongs to one Slab5 tenant. It is the operational boundary for app and agent access across the app plane.

Every workspace-owned record includes tenant_id and workspace_id. API and MCP services must filter every read and write by workspace context derived from the API key, MCP client token, or future OAuth grant. Human control-plane views only return workspaces where the signed-in user has active workspace membership.

Workspace display names can be changed in the admin console. Workspace IDs and slugs are stable identifiers and should be treated as durable references.

Membership and administration

Workspace administration requires local owner or admin membership in the target workspace. Owners and admins can create or revoke workspace credentials, change module access, update workspace settings, invite team members, and change MCP auth policy.

Members and readonly users can be part of a Slab5 team without receiving credential or workspace administration rights.

Workspace deletion is an owner/admin action. The dashboard only shows the delete action when the signed-in user has delete permission for the active workspace.

Credentials and modules

API keys and MCP clients are granted to one workspace. Owners and admins create credentials from the Slab5 console, and the full secret is shown once.

Module enablement lives at the workspace level, so disabling a module prevents new credentials from requesting that module's scopes and prevents module routes or tools from executing. This is separate from scopes: a credential needs both the scope and the enabled module.

Use REST when you are building an app. Use MCP when you are connecting an agent. Both operate on the same workspace data, scopes, module enablement, audit events, and usage events.

Workspace deletion

Deleting a workspace is a destructive control-plane action that requires a typed confirmation phrase. Slab5 prefers archival and revocation over physical deletion.

When a workspace is deleted, Slab5 archives the workspace and revokes or disables workspace access artifacts where the schema supports it:

workspace API keys
static MCP client tokens
OAuth workspace grants
workspace memberships
entitlement overrides scoped to the workspace
tenant module and webhook state tied to the workspace

Slab5 writes audit events for the deletion and related access revocation where possible. Existing app-plane records are not treated as reusable active workspace data after the workspace is archived.

Billing, audit, and usage

Workspaces consume included usage and prepaid usage balance through metered REST, MCP, storage, webhook, workspace, credential, and high-volume operations. When usage balance is exhausted or a monthly cap is reached, billable operations pause until balance, cap, or entitlement state changes.

Control-plane recovery paths remain available during a billing pause: owners and admins can inspect billing state, usage events, audit events, credentials, module settings, and data reduction options. Writes in the app plane continue to emit audit and usage events with request IDs when they are allowed to run.