SSO and SCIM

Connect your identity provider so people sign in with your directory instead of a password, and optionally have accounts created and removed automatically.

• SSO — OIDC or SAML 2.0. Advanced and above.
• SCIM 2.0 provisioning — Professional and above.

Both are configured under Settings, and both have been validated against Microsoft Entra ID and Okta. The integration is provider-agnostic; anything speaking standard OIDC or SAML should work.

Before you enable SSO

If your company already has people signing in with passwords, set the allowed email domains on the connection.

Without that, an existing password account is refused when your identity provider tries to link to it. This is a deliberate guard: without it, any identity provider asserting an email address could claim an existing account. Accounts created by SSO, and users who have never had a password, are unaffected.

SAML

The service provider metadata is published per company at:

/api/v1/auth/saml/{companyID}/metadata

Point your identity provider at it rather than transcribing endpoints by hand.

Two things worth knowing about how login is hardened:

• Assertions are single-use. A validated assertion ID is claimed for at least as long as it is valid, so a captured assertion cannot be replayed.
• The ACS endpoint accepts a cross-site POST from your identity provider by design, and is exempt from CSRF protection for that reason.

SCIM

Provisioning uses a per-company bearer token issued from the dashboard, against the standard SCIM 2.0 endpoints under /scim/v2.

Setting a user active=false, or deleting them, deactivates the account here and revokes their sessions. That is the property that makes SCIM worth wiring: offboarding in your directory ends access here without anyone remembering to do it.

GOTCHA: Microsoft Entra ID sends active as the string "True"/"False" rather than a JSON boolean. We coerce it before validation, so no workaround is needed on your side — but if you are debugging against a strict SCIM validator of your own, that is why it disagrees.

What downgrading does

SSO and SCIM are login and data paths, so we do not switch them off underneath you. Downgrading gates the ability to change the configuration, not the ability to sign in — disabling SSO on a company whose users have no passwords would lock out everyone with no way for them to fix it.

The exception is a sales-granted trial of a higher plan. When that reverts, credentials the restored plan does not entitle are revoked — SCIM tokens, API keys, webhook endpoints and ATS connections. SSO configuration is deliberately excluded from that revocation, for the lockout reason above.