Slab5

Personal workspace lifecycle

Every developer starts in a personal workspace. The personal workspace is where API keys, MCP tokens, records, audit logs, usage events, and first integrations live while the developer is evaluating or building with Slab5.

Account creation

When a developer creates a Slab5 account and first opens the control plane, Slab5 creates or assigns a personal workspace. The first workspace should be ready to use immediately.

The personal workspace should expose:

  • Workspace name and slug.
  • API base URL.
  • MCP endpoint.
  • API key creation.
  • MCP token creation.
  • Enabled modules.
  • Audit and usage views.

Workspace isolation

A personal workspace is isolated from other workspaces. Credentials created in the personal workspace can only access that workspace.

Every API route and MCP tool resolves the workspace from the credential before it reads or writes records. Workspace boundaries apply to CRM, Support, tasks, activity, CMS, assets, integrations, analytics governance, product analytics/BI, audit events, and usage events.

Endpoints and credentials

Use the endpoint values shown in the workspace. Hosted Slab5 workspaces use this shape:

Personal workspace environmentbash
SLAB5_API_BASE_URL=https://api.slab5.com/v1
SLAB5_MCP_URL=https://mcp.slab5.com/v1
SLAB5_WORKSPACE_API_KEY=slab5_personal_workspace_api_key
SLAB5_WORKSPACE_MCP_TOKEN=slab5_personal_workspace_mcp_token

Create separate credentials for separate clients:

  • Use a workspace API key for REST clients and backend apps.
  • Use a workspace MCP token for agent clients.
  • Use narrow scopes for each workflow.
  • Store raw secrets outside Git and browser clients.

Default modules and scopes

The personal workspace should include the modules needed for the first journey:

  • CRM
  • Support
  • Tasks
  • Activity Log
  • Files and Media
  • Integrations
  • Analytics Governance
  • Data & Insights

For the first CRM workflow, create credentials with:

Quickstart scopes
crm:read
crm:write
tasks:write
activity:write

Add module-specific scopes only when the workflow needs them.

Audit, usage, and request IDs

Every successful REST request and MCP tool call returns a request_id. Store it in client logs.

Writes should create audit events. API and MCP calls should create usage events. The request ID connects the response to support debugging, audit review, and usage visibility.

Use idempotency keys on write requests that may be retried. Reusing the same key and body should return the original result instead of creating duplicate workspace records.

Additional workspaces

The personal workspace is enough for first testing and agent experiments. Create another workspace only when you need stronger separation:

  • One workspace for a team.
  • One workspace per customer-facing environment.
  • One workspace per integration test lane.
  • One workspace for read-only demos.

Additional workspace creation requires billing to be enabled, unless Slab5 has granted an account override. This keeps self-serve testing simple while preventing unbounded workspace sprawl. Billing usage balance, usage events, and cap state should be visible from the control plane before a founder promotes workflows into another workspace.

Promotion path

The personal workspace proves the integration contract. Before moving a workflow to production:

  • Create production credentials in the target production workspace.
  • Recreate only the scopes needed by the workflow.
  • Confirm module enablement.
  • Preserve idempotency behavior.
  • Confirm audit and usage visibility.
  • Swap endpoint and credential environment variables without changing business logic.

Account deletion

Account deletion is available from Account Settings and requires a typed confirmation phrase. It cannot be undone from the dashboard.

For a personal account, deletion archives the personal Slab5 tenant, revokes local API keys and MCP clients, removes workspace access artifacts, and archives workspaces owned by the account where the schema supports it.

For Teams owned by the user, Slab5 archives the team tenant and revokes local workspace access artifacts. For Teams where the user is only a member, Slab5 removes the user's local memberships and leaves the team intact.

Was this page helpful?