Workspaces

No path in the API carries a workspace id. There is no /workspaces/{id}/posts — every operation is /posts, /schedules, and so on, and the workspace they act on comes from how you authenticated:

• An API key already is a workspace. It was created inside one workspace and only ever resolves to that one. Sending x-workspace-id for a different workspace alongside an API key answers 404 NOT_FOUND — a key can never be redirected to a different workspace by a request header. Sending it with the same id it already resolves to is a no-op.
• A session (dashboard or CLI login) resolves to whichever workspace is currently active for that browser or CLI session. Send x-workspace-id: <organizationId> to act on a different workspace you belong to, without switching your active workspace first.

If neither resolves to a workspace you are a member of, every org-scoped operation answers:

{ "code": "WORKSPACE_REQUIRED", "message": "Workspace not found. Select or create a workspace to continue." }

with HTTP status 412.

Asking for a workspace you are not a member of answers 404 NOT_FOUND, not 403 FORBIDDEN — the distinction would tell an attacker the workspace exists.

Why not a path segment

A version segment (/api/v1) is the only thing that belongs in a path. Putting the workspace there as well would let a client believe it could switch workspaces by editing a URL, when the actual authority is the credential. It also means the same route works unchanged whether the caller authenticated with a key, a session, or (for shared links) neither.