Prove identity, then operate within scope

Browser session (interactive UI)

After successful login, the API sets an httpOnly, secure session cookie named mjs_access. JavaScript cannot read this cookie, which reduces token theft from XSS.

For unsafe methods (POST, PUT, PATCH, DELETE), send the CSRF token from the session using the X-CSRF-Token header (double-submit pattern). Safe methods such as GET do not require the header.

curl -sS -b cookies.txt -c cookies.txt \
  -H "X-CSRF-Token: <token-from-session>" \
  -X POST "https://<host>/api/v1/integrations/connections" \
  -H "Content-Type: application/json" \
  -d '{"connectorKey":"example","displayName":"Staging link"}'

Passkeys / WebAuthn

Primary interactive sign-in supports passkeys (FIDO2/WebAuthn). Register a passkey from your profile after initial account setup. Phishing-resistant credentials replace password-only flows where enabled.

Optional Kerberos / SPNEGO

When your operator enables enterprise SSO, clients that negotiate SPNEGO receive the same session cookies as standard login. No separate automation token is issued to the browser.

Tenant automation keys (mjt_)

Server-side jobs, orchestration, and infrastructure-as-code should authenticate with tenant automation keys:

Authorization: Bearer mjt_<secret>

Each key carries one or more scopes shaped as <moduleKey>:<READER|OPERATOR|ADMIN>. Wave-1 automation commonly uses integrations:READER, integrations:OPERATOR, and integration_hub:READER.

• Least privilege — grant the minimum scope needed; prefer READER where writes are not required.
• Expiry — set an expiration when creating keys; renew before expiry.
• Rotation — rotate keys periodically and after personnel changes.
• Revoke — delete compromised or unused keys immediately.

curl -sS "https://<host>/api/v1/automation/health" \
  -H "Authorization: Bearer mjt_<secret>"

Managing keys (interactive session only)

Create, list, rotate, and revoke tenant keys through the API while signed in with a browser session (not with an automation key). Required roles: COMPANY_IT_ADMIN, EXECUTIVE, or PLATFORM_ADMIN.

Method	Path	Description
GET	/api/v1/company/api-keys	List keys (prefix and metadata only)
POST	/api/v1/company/api-keys	Create key; full secret returned once
POST	/api/v1/company/api-keys/:id/rotate	Rotate; new secret returned once
DELETE	/api/v1/company/api-keys/:id	Revoke key

Store the secret in a vault or secret manager at creation time. It cannot be retrieved later.

To discover valid module keys and scope levels before creating a key, call GET /api/v1/company/api-keys/allowed-scopes with an interactive session.

Common auth errors

• 401 Unauthorized — missing or invalid session cookie or bearer token.
• 403 Forbidden — identity valid but scope, role, or allowlist denies the route.
• 403 when managing keys with an automation key — key management requires interactive sign-in.

Platform keys (mjs_)

Platform operations keys exist for operator tooling only (for example platform monitoring and alerting channel configuration). They are not for customer tenant automation and are not provisioned through tenant self-service.

Module entitlements

Calling module APIs requires an active tenant entitlement for that module. Scopes on a tenant key cannot bypass licensing; missing entitlement yields authorization failure even with a valid key.