Clerk SCIM provisioning: let the customer's IdP create and suspend users

TL;DR: Manual user management does not scale past the first enterprise deal. SCIM lets the customer's identity provider push user lifecycle events into Clerk: creates, updates, suspensions, and group membership sync, with no tickets to your support team. Set up the enterprise SSO connection for the customer's org first. Enable SCIM provisioning on the connection in the dashboard.

SCIM provisioning from the customer's IdP

The order

1. Set up the enterprise SSO connection for the customer's org first. SCIM rides on the SSO connection; there is no standalone SCIM setup.

2. Enable SCIM provisioning on the connection in the dashboard.

3. Clerk generates a SCIM base URL and a bearer credential for the connection. Hand both to the customer's IdP admin to enter in their provisioning settings (Okta, Entra ID, and friends all speak SCIM).

4. The IdP starts pushing: user creates, profile updates, suspensions, and group membership changes, which sync into the Clerk organization.

5. Test with a small pilot group in the IdP before the customer points their whole directory at it.

What you get

• Deprovisioning that actually works. When the customer disables a user in their IdP, the suspension propagates and the user loses access instead of lingering until someone remembers to remove them.

• Group sync into org membership, so the customer's team structure maps to your org without manual role assignment per hire.

The traps

• SCIM suspension is not the same as your app's own deactivation logic. If your database keeps a separate active flag, sync the SCIM-driven state into it via the membership webhooks, or the two systems disagree about who is active.

• The bearer credential Clerk generates is long-lived. Treat it like the secret it is: the customer stores it in their IdP, you never log it, and you rotate it if it leaks.

• Group-to-role mapping is a design decision, not automatic magic. Decide which IdP groups map to which Clerk roles before the first sync, and write the mapping down where both teams can see it.

Checklist

• A deprovisioned test user cannot sign in and cannot use an existing session within your session-revocation expectations.

• Your audit log records SCIM-driven changes distinctly from manual ones, so a confused customer admin can tell what the IdP did versus what a human did.

When to use this

• This covers exactly what the title says: Clerk SCIM provisioning.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Clerk; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Clerk behavior.

Verified against Clerk's enterprise connection model: SCIM provisioning is enabled on the SSO connection, Clerk issues the SCIM base URL and bearer credential for the customer's IdP, and the IdP drives user creates, suspensions, and group membership sync into the organization.