API authentication & request safety

The current HTTP surface

The API reference is generated from the Go application’s OpenAPI contract. It describes the current browser-facing workspace, company, reports, authentication and runtime operations. The contract version is a development version, not a promise of a stable external integration release.

These operations do not expose a general API-key, bearer-token or client-credentials interface. Do not build a third-party service by collecting users’ browser session cookies. Agree a separately qualified machine-access contract for server integrations or native mobile apps.

Browser sessions

Start sign-in through /auth/login. A successful callback sets the secure, HTTP-only, host-only __Host-session cookie. Browser requests use the same LMS origin and include credentials. JavaScript must not read or store the session secret.

The separate __Host-csrf cookie is readable by the same-origin app. Protected writes require its value in X-CSRF-Token and a matching Origin, checked against the stored session secret. The browser sets Origin; do not spoof it or disable CSRF to make an integration work.

Authority on every operation

• The active company and user come from the verified session.
• Roles and organisational scope are checked independently of authentication.
• Company writes additionally require recent authentication and configured assurance.
• Switching company rotates the session; refresh the current state after switching.
• The signed provider back-channel logout endpoint is a protocol endpoint, not a browser CSRF endpoint.

Use examples safely

Reference examples are illustrative and never run automatically. Replace placeholders only in an authorised local or test environment. Keep passwords, secrets, callback codes, cookies and logout tokens out of logs and support messages.

The reference provides parameter constraints and response schemas. Read the operation description and the relevant feature guide before making a state-changing request.