Workspaces per Customer

Each of your customers gets their own workspace. The boundary is real: agents, credentials, runs, sessions, and usage in one workspace are invisible to every other. Provision one when a customer signs up, act on it over the API, suspend it when they leave.

Provision

curl -X POST https://api.levainlabs.com/api/v1/org/workspaces \
  -H "Authorization: Bearer $LEVAIN_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Acme Tools"}'

The response carries the workspace id — store it against the customer in your own database; it's the value you'll send in X-Workspace-Id from then on. The new workspace starts empty and headless: no members, no sign-in, no agents until you adopt one.

Provisioning requires the Enterprise plan, and an org can hold up to 500 workspaces. If a create fails, it's safe to retry — a workspace either comes back in the response or doesn't exist.

Address

Send the workspace id with an org key on any workspace-scoped endpoint:

curl https://api.levainlabs.com/api/v1/agents \
  -H "Authorization: Bearer $LEVAIN_ORG_KEY" \
  -H "X-Workspace-Id: $CUSTOMER_WORKSPACE_ID"

The rules are strict on purpose:

• An org key with X-Workspace-Id acts on that workspace. An unknown id, or one belonging to another org, returns 404.
• An org key without the header only resolves when the org has exactly one workspace; otherwise the request is refused with 400 and asks you to pick.
• A workspace-scoped key naming a different workspace in X-Workspace-Id is refused with 403 rather than silently ignored, so a caller never acts somewhere other than where it asked to.

List what you have with GET /api/v1/org/workspaces — each row carries headless (whether anyone can sign in) and lifecycle.

Lifecycle

A workspace is active, dormant, or suspended.

Suspend a workspace when its customer offboards:

curl -X POST https://api.levainlabs.com/api/v1/org/workspaces/$WS_ID/lifecycle \
  -H "Authorization: Bearer $LEVAIN_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{"state": "suspended"}'

Suspended workspaces refuse new runs until you set them back to active. Data, agents, and configuration are all kept, so re-onboarding a returning customer is the same call in reverse. The org's primary workspace can't be suspended — it carries the org's plan and sign-in.

Dormant is automatic: a workspace with no activity for 30 days is marked dormant, and the next run clears it. You never set it yourself; treat it as a signal that a customer has gone quiet.