Switching, tokens & API keys

Every credential in Eddytor is bound to one organisation and one workspace at the moment it is issued. 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 and never touches the ones you already have. Your profile (GET /v1/users/me) lists all memberships and the workspaces visible in the currently bound organisation, which is what switcher UIs are built on.

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. Legacy tokens and keys from before workspaces existed resolve the same way - nothing broke when workspaces arrived.

Switching context

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

Under the hood a switch is a token refresh with an organisation_id or workspace_id parameter - your session is re-issued with the new binding. Switches are validated before the refresh token is consumed, so asking for an organisation you're not in, or an archived workspace, fails cleanly (invalid_grant) without burning your session.

Two behaviours worth knowing:

• An explicit switch to an invalid target is always an error - never a silent fallback.
• An inherited binding that becomes invalid (say, your bound workspace was archived while you were away) quietly degrades to the organisation's default workspace on the next refresh, so archival doesn't force-log-out a whole team.

API keys

Keys are bound to the organisation and workspace of the session that mints them, and only ever reach that workspace:

• 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 simply isn't visible until you switch there: reads are bound, writes are permission-checked.