EddytorDocs & API
06 · Workspaces

Create & manage workspaces

Create, rename, archive, and manage members - via CLI or REST.

Creating and managing workspaces requires the workspaces:write scope, held by organisation Admins. Listing requires workspaces:read, which every role has.

Create

eddytor create workspace "Data Science" 

or via REST:

curl -X POST "$BASE/api/v1/organisations/$ORG_ID/workspaces" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name": "Data Science"}'

Names are 1-100 characters and must be unique among the organisation's live workspaces (a name freed by archiving can be reused). See the Workspaces API reference.

List & inspect

eddytor get workspaces

Admins see every workspace; other members see the default workspace plus the ones they are explicit members of. A workspace you can't access returns 404 - existence is not leaked.

Members

Non-default workspaces grant access through explicit membership; org Admins are implicit admins everywhere and don't need a row. The member must already belong to the organisation.

eddytor create workspace-member <workspace-id> <user-id> --role builder
eddytor delete workspace-member <workspace-id> <user-id>

Adding an existing member again updates their role (upsert). Roles reuse the four organisation roles: admin, builder, editor, viewer (CLI default: viewer). Member listings return explicit members only - implicit access (Admins, the default workspace) is computed, not stored.

Good to know

The default workspace takes no explicit members - every org member already has implicit access at their org role, and attempts to override that per-user are rejected.

Rename

eddytor set workspace-name <workspace-id> "New name"

The default workspace cannot be renamed.

Archive

eddytor delete workspace <workspace-id>

Archiving is permanent - there is no un-archive. It takes effect immediately:

  • Every API key bound to the workspace is revoked in the same transaction.
  • The workspace's shared storage configurations disappear from members' listings, and affected engine sessions are dropped at once.
  • Sessions bound to the archived workspace fall back to the organisation's default workspace on their next token refresh rather than being logged out.

The default workspace cannot be archived.

Audit trail

Workspace activity lands in the organisation audit log as workspace.created, workspace.archived, and workspace.member_changed events.

On this page