Error codes

Caller is not authenticated.

Remedy: Sign in (UI) or attach a valid Bearer token (API).

Tenant resolver couldn't match the caller's email to a TenantUser row.

Remedy: Have your workspace admin invite this email address before signing in.

The tenant is configured CREDENTIALS_ONLY — SSO is blocked at the IdP layer.

Remedy: Sign in with email + password, or ask an admin to enable SSO on the tenant settings.

The Azure AD account is disabled in the directory.

Remedy: Have IT re-enable the account in Entra ID and try again.

The action requires a fresh step-up proof. The response body's `purpose` field tells you which ceremony to start.

Remedy: Call `/api/auth/step-up/challenge-options` with the given purpose, complete the WebAuthn or TOTP ceremony, then retry the original request with `X-StepUp-Token`.

The provided step-up token is malformed, expired, or doesn't match the action's purpose.

Remedy: Re-run the step-up ceremony — see the `reason` field for detail (SIGNATURE_INVALID / EXPIRED / PURPOSE_MISMATCH / …).

The `purpose` is not one of the closed STEP_UP_PURPOSES enum values.

Remedy: Use one of: PAYROLL_SEAL, PAYROLL_TRANSMIT_ACH, ERASURE_FINALIZE, EQUITY_GRANT_COSIGN, … (see the API reference).

The viewer has no enrolled factor that satisfies this purpose's policy (e.g. only TOTP enrolled but purpose is phishing-resistant).

Remedy: Enroll a passkey at /account/security or ask your admin to relax the policy.

The factor you tried to use is not acceptable for this purpose (commonly: TOTP used for a passkey-only step-up).

Remedy: Use the required factor type — usually a passkey for money-movement actions.

Tenant MFA policy requires MFA for this user, so they can't disable it.

Remedy: Have an admin remove the requirement first, or use a passkey if `acceptedFactors = {WEBAUTHN}`.

Removing this factor would leave the user with zero verified factors while the tenant requires MFA.

Remedy: Enroll an additional factor or generate recovery codes before removing this one.

Tenant `acceptedFactors = {WEBAUTHN}` — TOTP devices can be removed but the user must have a passkey first.

Remedy: Enroll a passkey at /account/security before removing your TOTP device.

The SCIM filter expression failed to parse or used an unsupported operator.

Remedy: Stick to the operators in /developers/scim — eq / ne / co / sw / ew / gt / ge / lt / le / pr with and/or/not.

A required attribute is missing or malformed (e.g. POST /Users without userName).

Remedy: Make sure userName + (optionally) emails[].value are present in the payload.

A unique constraint would be violated (rare — POST /Users is idempotent and returns 200 instead).

Remedy: Read the response body for the existing resource and PATCH it instead of POSTing again.

Convention used by customer apps when our signature didn't verify.

Remedy: Confirm your verifier reconstructs `${timestamp}.${rawBody}` exactly (no JSON re-stringify) before HMAC-SHA256.

The tenant network policy denied this request.

Remedy: Connect from a permitted IP, ask an admin to add your CIDR, or have an admin enable adminBypass for emergency access.

Server refused to enable ALLOWLIST with zero rules and adminBypass=off — would lock out the workspace.

Remedy: Add at least one CIDR rule, or keep adminBypass on.

The CIDR string didn't parse as a valid IPv4 or IPv6 range.

Remedy: Use the canonical form: `203.0.113.0/24`, `2001:db8::/32`, or a bare address (treated as /32 / /128).

An identical CIDR is already in this tenant's rules.

Remedy: Look up the existing rule and edit its label instead of re-adding.

The tenant's WebAuthn attestation policy refused the enrollment.

Remedy: Use a permitted authenticator (see the `reason` field — ALLOWLIST_NO_MATCH / SYNCED_PASSKEY_DENIED / PLATFORM_AUTHENTICATOR_DENIED).