Switching, tokens & API keys

Every credential in Eddytor is bound to one organisation and one workspace at issuance. Access tokens carry org and ws claims; API keys freeze their binding at mint. There is no "all workspaces" credential.

One account, many organisations

An account can belong to any number of organisations - accepting an invite adds a membership rather than replacing one. GET /v1/users/me lists all memberships and the workspaces visible in the currently bound organisation.

If a token doesn't name an organisation, it resolves to your earliest-joined organisation; if it doesn't name a workspace, it resolves to that organisation's default workspace.

Switching context

eddytor set org <organisation-id>
eddytor set workspace <workspace-id>
eddytor whoami        # shows email, role, workspace, and your organisations

An explicit switch to an invalid target - an organisation you're not in, or an archived workspace - is always an error, never a silent fallback: it fails with invalid_grant without consuming your session.

An inherited binding that becomes invalid (your bound workspace was archived while you were away) degrades to the organisation's default workspace on the next refresh.

API keys

A key freezes its organisation-and-workspace binding at mint (API keys), so switch to the target workspace before minting.

• Minting inside an archived or inaccessible workspace is rejected.
• Archiving a workspace revokes all keys bound to it.
• Key listings expose organisation_id and workspace_id; null means a legacy key, which behaves as bound to the organisation's default workspace.

Registering into a workspace you're not bound to

Writes are allowed into any workspace where you have Admin/Builder access, even if your session is currently bound elsewhere - so an Admin can share a config into a team's workspace without switching first. The result isn't visible until you switch there: reads are bound, writes are permission-checked.