Automate user lifecycle with SCIM 2.0 - create, update, and deprovision workspace members from your IdP.
SCIM 2.0 keeps Meridian membership in sync with your IdP: people join with the right role on day one and lose access the moment they leave - no manual cleanup.
Service accounts are never managed by SCIM (they're not humans).
Meridianhttps://api.meridian.dev/scim/v2Authenticate with a SCIM bearer token - generated in Settings → Security → SCIM. The token is workspace-scoped and shown once.
| Operation | SCIM call | Effect |
|---|---|---|
| List users | GET /Users | Read members (paginated) |
| Create user | POST /Users | Invite with mapped role |
| Read user | GET /Users/:id | Fetch one member |
| Update | PATCH /Users/:id | Attribute/role change |
| Deactivate | PATCH /Users/:id (active: false) | Revoke access |
| Groups | `GET | POST /Groups` |
| SCIM attribute | Meridian field |
|---|---|
userName | email (login identity) |
name.givenName / name.familyName | name |
active | membership enabled/disabled |
groups[] | role mapping via group rules |
Settings → Security → SCIM → Enable - copy the bearer token.
In Okta's Meridian app → Provisioning: paste the base URL + token, enable Create Users, Update Attributes, Deactivate Users.
Push Okta groups; assign each a Meridian role under SCIM → Group mappings. Members of meridian-developers become developer, etc.
Assign a test user → confirm they appear in Members with the mapped role. Unassign → access should revoke within seconds.
| Symptom | Likely cause |
|---|---|
401 on SCIM calls | Token revoked/expired - regenerate in settings |
User created but viewer | No group mapping matched - check group push |
| Deactivation didn't revoke | IdP sent active: true patch later - check provisioning logs |