Docs / API and agents

Session and shell API

How the web app learns who is calling, the shell data per workspace, and the public apply context.

The session is an Auth.js-compatible encrypted cookie issued by services. Every route needs a valid session unless it is marked public (default-deny, auth/session.guard.ts). A bearer token carrying the same value is accepted for the mobile shell.

How a session is checked#

  1. Decode the token with the shared secret; reject an expired or clock-invalid one (24 hour session).
  2. Reject it when the user logged out, when the user's sessions were revoked after it was issued, or when its organization is revoked (suspended or denied tenants).
  3. Apply the workspace and impersonation overlays. They can only narrow or re-target a verified session, never create one.
  4. Anything else is a 401. State-changing browser requests also pass the Origin guard: a foreign Origin header is a 403; clients that send none (mobile, curl) pass.

Routes#

Method and pathWhoWhat
GET /sessionsession (401 when signed out){ user, impersonating }
GET /session/post-login?next=sessionwhere to go next: /onboarding for a new customer without an organization, a safe same-site next, or the role's landing page
GET /shell/vendor, /shell/applicant, /shell/platformsessionheader and navigation data for each workspace (counts of pending references, unread messages)
GET /account/workspaces, GET /account/vendor-startsessionwhich workspaces the business has enabled
GET /apply/contextpublic; a session adds prefill and historywhat the apply page needs for a supplier link or QR
POST /reference/:token/vendor-start, POST /reference/saved/:token/vendor-startpublicstart a supplier signup from a reference page: sets a short-lived cookie and redirects (303) to /signup?as=vendor&from=reference
POST /auth/sign-outpublic (ends dead sessions too)clears the session cookies
POST /auth/heartbeatsessionrenews the cookie while the user is active

All session-dependent answers carry Cache-Control: private, no-store.