Developer portal

Authentication

Three modes cover every integration pattern: API keys for server-to-server, OAuth 2.0 for user-authorised third-party apps, and SCIM 2.0 service tokens for provisioning.

API keys (bearer tokens)

The primary authentication method for server-to-server integrations. Generate in the app at /settings/api-keys.

Scoped per API key — full tenant, module-scoped, or read-only.
Shown once on creation; SHA-256 stored, never recoverable.
Rotate keys without downtime — two keys can be active at once.
Audit log captures every call with key-id, route, status, timestamp.

curl https://app.qehsethos.com/api/v1/records \
  -H "Authorization: Bearer qehs_live_sk_1A2B3C4D..."

OAuth 2.0 & OIDC

For third-party apps acting on behalf of a user, use the authorization code flow with PKCE. Refresh tokens rotate; the old refresh token is revoked immediately on use.

Authorize URL: https://app.qehsethos.com/oauth/authorize

Token URL: https://app.qehsethos.com/oauth/token

Scopes: records.read, records.write, modules.read, attachments.read, exports.create, admin.users

To register an OAuth app, contact partner-sales or your Customer Success Manager. Self-service app registration is on the Q3 roadmap.

SCIM 2.0 tokens

For Identity Provider integrations (Okta, Entra ID, Google, JumpCloud, OneLogin, Ping, etc.). Generate a SCIM token from /settings/scim and paste into your IdP.

Endpoints: /api/scim/v2/Users and /api/scim/v2/Groups
Full CRUD including PATCH operations for incremental sync.
Group memberships map to QEHS role assignments (owner-configurable).
Rotate the token at any time — the old token is immediately invalidated.

Session cookies

The web UI uses signed session cookies. These are not intended for programmatic use — prefer an API key or OAuth token for integrations. Session cookies are HttpOnly, Secure, SameSite=Lax, and rotate on sensitive operations.