A customer asks “do you support SCIM?” in the middle of a deal. If you have to Google it, you’ve already lost a week. Here’s the shortest useful explanation.
The problem SCIM solves
Without SCIM, onboarding a 500-employee customer goes like this: their IT admin exports a CSV from Okta, you import it into your app, then every time they hire or fire someone, someone opens a support ticket. After a few months the user lists drift — terminated employees still have access, new hires wait 48 hours, and nobody trusts the data.
SCIM (System for Cross-domain Identity Management) is the standard protocol for making this automatic. The customer’s IdP pushes user lifecycle events (create, update, delete, group changes) to your API in real time.
The shape of it
SCIM is REST + JSON. You expose a few endpoints:
POST /scim/v2/Users — create a user
GET /scim/v2/Users/:id — fetch one
PATCH /scim/v2/Users/:id — update (typically enable/disable)
DELETE /scim/v2/Users/:id — delete (often soft)
GET /scim/v2/Groups, etc.The payloads follow a standardized schema (schemas array, userName, emails, active, groups, etc.). Authentication is usually a bearer token that the customer configures in their IdP.
What makes it annoying
- Every IdP interprets the spec slightly differently. Okta sends full PUTs for updates; Azure AD sends sparse PATCHes. You need to handle both.
- Soft-delete vs hard-delete matters for compliance. Most customers want “deactivate, don’t purge.” Your schema should support both.
- Pagination and filtering have a SCIM-specific syntax (
filter=userName eq "jane@acme.com") that you have to parse. - Groups are where bugs hide — nested groups, role mapping, and ensuring the same user in multiple groups doesn’t get duplicated.
The product positioning
Customers don’t ask for SCIM because they love the spec — they ask because they want “zero-touch onboarding.” Frame it that way in your pricing and docs: “automatic user provisioning and deprovisioning” sells better than “we support SCIM 2.0.”
And be honest: SCIM is typically an add-on, not a base-tier feature. Pricing per enterprise connection is the norm (we charge $199-300/mo per connection). That reflects the real operational cost of maintaining a working integration per customer IdP variant.