Integrate with LXS

Engineers use these guides to connect a product to LXS Directory (authentication, sessions, tenant APIs) and optionally the LXS-hosted front-end. Pick an integration path first, then follow the shared runbooks for front-end shape, auth, sessions, and OAuth/OIDC.

Hosted documentation

Environment	Base URL
Development	https://docs.dev.us.lxs.lxp.live
QA	https://docs.qa.us.lxs.lxp.live
Production	https://docs.prod.us.lxs.lxp.live

Tenant vanity hosts (for apps and APIs) follow your deploy’s CLIENT_VANITY_DOMAIN_BASE pattern, for example https://{tenantSlug}.mm.dev.lxs.lxp.live.

Two integration paths

	Path A — First-Party Session	Path B — OAuth Connected Application
Who owns the browser session	LXS (HttpOnly session cookie on the LXS site)	Your application (you issue and store your own session after OIDC)
How the user signs in	Same login flows as LXS (local, SAML, tenant OAuth, managed Microsoft/Google, etc.)	LXS acts as an OpenID Provider; your app is the OAuth client
API authorization	Browser sends the LXS session cookie (credentials: 'include') plus deploy headers	Your backend calls LXS with a Bearer access token from the token endpoint (LXS session token)
Best when	Your UI and APIs share the LXS vanity domain (or you proxy so cookies are first-party)	You run a separate product domain and need a standards-based OIDC boundary
Session data	Read via GET /api/v1/directory/session/me; you cannot mutate session contents	User identity via /userinfo; your app owns profile/session state
Guides	Path A overview	Path B overview

Both paths support LXS-hosted front-end (ship features inside the provided Vue apps) or a custom front-end that calls Directory REST APIs.

Path comparison (flows)

flowchart TB
  subgraph pathA [Path A — First-Party Session]
    U1[User browser] --> FE1[LXS or custom FE on same site]
    FE1 -->|cookie + x-24g-* headers| API1[Directory API]
    API1 -->|Set-Cookie session| U1
  end

  subgraph pathB [Path B — OAuth Connected App]
    U2[User browser] --> RP[Your app / RP]
    RP -->|redirect /authorize| OP[LXS Authorization Server]
    OP -->|login if needed| Login[Directory authentication]
    Login --> OP
    OP -->|code| RP
    RP -->|POST /token| OP
    RP -->|Bearer token| API2[Directory API /userinfo]
  end

Recommended reading order

1. Stack builder — interactive (EXAMPLE) wizard to pick Path A vs Path B and hosted vs custom.
2. Front-end: hosted vs custom — where your UI runs relative to LXS.
3. Authentication — auth configs, strategies, and deploy headers.
4. Path-specific guide: First-Party Session or OAuth Connected Application.
5. Sessions (Path A) or OAuth / OIDC (Path B).
6. REST API reference — OpenAPI spec and Swagger UI.

What this site is not

• Not a substitute for tenant admin configuration in the LXS dashboard.
• Not internal runbooks or wiki content — everything here is written for integrators consuming public Directory APIs.