auth

Continue into a verified workspace when existing sign-in rules agree

Recheck the server session and the linked member without reading a redirect flag.

post/v1/auth/continue-workspace-link

Request

  • Base URL: https://api.patricia.app (the document declares no server; this is the origin it was published from)
  • URL: https://api.patricia.app/v1/auth/continue-workspace-link
  • Auth: HTTP bearer

Response

Successful Response

access_tokenstring required
refresh_tokenstring required
token_typestring
expires_ininteger required
landing_hint'pending_invitation' | 'diverted_unknown_workspace'

A non-authorization hint explaining WHY a session landed where it did.

The dashboard reads it to show the right next step instead of a bare landing. It never grants access: the token's tenant claim (or its absence) is the sole authority. Two values, and they differ in whether the session has a workspace at all:

PENDING_INVITATION lands TENANT-LESS — a returning user with at least one pending invitation and no active available home. It is NOT "only pending memberships": the branch is chosen on has_pending before the deactivated/unavailable fallback, so a user holding a pending invite alongside deactivated or unavailable ones lands here too. The SSO guard declines to mint an empty duplicate tenant, and the hint points them at accepting the invite / signing in from the connected workspace.

DIVERTED_UNKNOWN_WORKSPACE lands WITH an active workspace — a returning user who signed in from a chat workspace Patricia does not know. The guard diverts them to their existing primary workspace rather than minting a second one, and the hint is what lets the dashboard say so and offer a deliberate way to create a separate workspace instead of failing silently.

decision_keystring nullable

Changes

No recorded changes to this operation across all 1 revision of this API.