SCIM provisioning overview

SCIM provisioning lets your identity provider (IdP) create, update, and deactivate Celigo users for you. Instead of inviting each person by hand and remembering to disable them when they leave, you connect your IdP to Celigo once, and the IdP pushes every change from then on. A new hire has the access they need before their first sign-in, and a departing user loses access — including the tokens their tools are holding — as soon as the IdP deactivates them.

Celigo supports SCIM 2.0 for both kinds of users in an account. Workspace users are the people who sign in to integrator.io to build and run integrations. End users are the people who reach your MCP servers from AI clients such as Claude and Cursor and never sign in to integrator.io. Each kind has its own SCIM configuration, and neither one touches the other's records.

This article explains when SCIM provisioning is the right choice, how the two configurations differ, how Celigo matches and updates users, how tokens work, and what Celigo records. For the setup steps, see Provision workspace users with SCIM or Provision end users with SCIM.

Access SCIM provisioning settings

Go to Account , and then select Security. Use the Security settings on the left to access the following SCIM provisioning settings:

• Workspace users, select SCIM provisioning under Company.
• End users, select Authentication under End users, open an identity provider, and find its SCIM provisioning section.

Key concepts

Workspace user — A person who signs in to integrator.io to build, run, and monitor integrations. Workspace users have an account-wide access level and no groups.

End user — A person who reaches your MCP servers from an AI client such as Claude or Cursor and never signs in to integrator.io. End users get access through end-user groups, end-user roles, and direct MCP server assignments.

SCIM configuration — One enabled SCIM endpoint in Celigo, with its own base URL and its own pair of tokens. An account has one workspace configuration and one configuration per external identity provider.

SCIM token — The bearer token your identity provider presents on every request. A token authenticates for one configuration only.

IdP-sourced membership — A group membership or role assignment that came from an identity provider rather than from an administrator working in Celigo. SCIM reconciles these and leaves the rest alone.

When to use SCIM provisioning

Without SCIM, a workspace user exists only after someone invites them, and an end user exists only after an invitation or a first sign-in through the IdP. Access changes wait for an administrator or for the next sign-in, and offboarding depends on someone remembering to disable the account. Use SCIM provisioning in the following situations:

• People need access before their first day. Your IdP creates the Celigo user when you assign the person to the Celigo application, with the access level or group memberships you mapped. Nobody sends an invitation, and nobody waits for a first sign-in.
• A departing user has to lose access the same hour, tokens included. An MCP client keeps working on a refresh token for weeks after someone's IdP account is disabled, because it never needs to sign in again. A workspace user's personal access tokens work until someone revokes them. When your IdP deactivates the person, Celigo disables them and revokes those tokens.
• Access should follow your directory. Map a workspace user's account-wide access level to a directory attribute or an IdP group, and a promotion or a team change reaches Celigo on the next push. Push end-user group memberships from the IdP, and MCP server access follows.
• Auditors ask how access was granted and removed. Every SCIM change lands in the Celigo audit log with source SSO, alongside changes made manually.
• You manage more people than you want to invite by hand. Past a few dozen users across several teams, keeping Celigo in step with the directory becomes a recurring task. SCIM removes it.

Skip SCIM in the following two cases:

• Your team is small and you have no IdP. Invitations are enough, and Celigo credentials work for both user types.
• You have end users only, and JIT provisioning plus group sync covers you. Together they create people at first sign-in and refresh their groups at every sign-in. They can't create anyone before they sign in, they work only with IdPs that send group names in the token, and they can't revoke a departing user's MCP tokens. See SCIM, JIT provisioning, and group sync.

Differentiate user types and configurations

Workspace users and end users are separate user types with separate access models, so each has its own SCIM configuration and its own base URL. A person who is both a workspace user and an end user in one account is a single user record with a membership of each kind. Each configuration manages only its own membership, so deactivating one leaves the other active. Profile fields such as the name belong to the shared record, so a value set through one configuration is kept by the other. Configure both if you want the IdP to manage both.

How SCIM provisioning works

Your IdP is the client and Celigo is the server. You give the IdP two values from Celigo, the base URL and a SCIM token. Whenever something changes, the IdP sends the change to that URL and presents the token. Celigo never calls your IdP. How soon a change arrives depends on the IdP — Okta pushes as changes happen, and Microsoft Entra ID pushes on its provisioning schedule, which Microsoft documents as about every 40 minutes.

• Email is the matching key. Celigo reads the SCIM userName, or the primary email, and lowercases it. If no Celigo user has that email, Celigo creates one. If one does, Celigo uses the existing record.
• Celigo adopts existing users instead of duplicating them. A workspace user you invited earlier, or an end user who was invited or created by JIT provisioning, becomes SCIM-managed the first time the IdP pushes them. Nothing is removed and re-added, and a pending invitation counts as accepted.
• Profile fields fill blanks only. Celigo sets the name, time zone, and company from the SCIM payload only when the Celigo field is empty. A value someone already set, in Celigo or through another IdP, stays. The same person can belong to several Celigo accounts, and one account's IdP must not overwrite what another set.
• Celigo reconciles access from the IdP's view. For workspace users, each push that carries accessLevel sets the account-wide access level. For end users, each push that carries a groups list replaces the group memberships that came from the IdP with that list — including when the list is empty, which removes every IdP-sourced membership. A push with no groups attribute leaves memberships unchanged. Memberships an administrator added directly in Celigo stay either way.
• Deactivation disables the user and keeps the record. When the IdP deactivates someone, Celigo disables their membership in the account and revokes their tokens. The record, its access level, and its memberships stay, so a reactivation from the IdP restores them.
• Deleting is not deactivating. SCIM never deletes a user or a group. If the IdP sends a delete request, Celigo rejects it with 501 Not Implemented and changes nothing — the person is not deactivated either.

SCIM, JIT provisioning, and group sync

This comparison applies to end users only. Workspace users do not support just-in-time (JIT) provisioning; without SCIM, they must be created via invitation. SSO controls how workspace users sign in, but it does not create user records.

For end users, one external identity provider can run all three mechanisms at once. They write to the same IdP-sourced group memberships and never touch memberships added directly in Celigo, so running them together doesn't create competing sources.

Turn on group sync alongside SCIM. If a push is delayed, or your IdP's provisioning cycle hasn't run yet, memberships still refresh at sign-in, and both mechanisms converge on the IdP's current groups.

What Celigo records

Celigo writes every SCIM change to the account audit log with source SSO. There is no separate SCIM source — SCIM pushes and SSO sign-ins share the SSO value, so an entry's Source tells you an identity provider was involved and the entry itself tells you what changed. Because the IdP made the change and nobody was signed in, the entry's User is the account owner. To review SCIM activity, go to Account > Audit log and filter the Source column by SSO. Celigo records the following events with source SSO:

• Creating a user, adopting an existing one, and each later update, with resource type User.
• Disabling or re-enabling a user, recorded as the disabled field changing.
• A workspace user's access level changing, with the old and new values.
• Creating an end-user group, and adding or removing a member.
• An attempt to deactivate or change the account owner, recorded on the field scimOwnerOperationIgnored with the value deactivate (ownership changes require transfer) or accessLevel:<value> (ownership changes require transfer). Celigo writes one entry per ignored operation.

Celigo doesn't keep a SCIM request log. To see what the IdP sent and what Celigo answered, use the IdP's own provisioning log.

Nothing in the Users lists marks a person as SCIM-provisioned, and nothing on a group membership or a role assignment shows whether the IdP or an administrator added it. The audit log holds that history.

Supported identity providers

Celigo accepts SCIM 2.0 from any identity provider that can push to a custom SCIM endpoint. Celigo isn't listed in the Okta Integration Network or the Microsoft Entra application gallery, so in Okta, Microsoft Entra ID, and OneLogin you create a generic SCIM 2.0 application and point it at the base URL. Okta and Microsoft Entra ID need that provisioning application to be separate from the one that signs people in, for both user types. Auth0 has no SCIM application to create — it pushes users through an Event Streams Action that you deploy in your tenant. Google Workspace can't push to a custom SCIM endpoint at all.

Endpoints and supported features

Celigo publishes a SCIM 2.0 service under the base URL of each configuration.

Your identity provider calls these endpoints under the base URL. You never call them yourself.

/Schemas describes the Celigo attributes for that user type, so an identity provider that reads schemas can offer accessLevel or roles in its attribute mapping. Microsoft Entra ID doesn't read schemas for a non-gallery application, so you add those attributes by hand there.

DELETE isn't implemented on any endpoint. Celigo answers a delete request with 501 and changes nothing.

Celigo reports these through /ServiceProviderConfig, so an identity provider that reads the endpoint adjusts on its own.

A lookup on any attribute other than userName, externalId, or a group's displayName, or with an operator other than eq, fails.

What SCIM never changes

Regardless of what your IdP sends, SCIM never changes the following:

• Email. It is the matching key. Celigo rejects a push that changes an existing user's email, and the IdP shows the push as failed. To change someone's email, change it in Celigo first, then in the IdP.
• Memberships and grants made in Celigo. For end users, SCIM manages only the group memberships it sourced from the IdP; direct memberships and direct MCP server assignments stay. For workspace users, SCIM sets the account-wide access level and never writes per-integration grants.
• The account owner, on the workspace configuration. SCIM can list the owner but can't deactivate them or change their access level. Those requests succeed from the IdP's point of view and change nothing. The end-user configuration has no exempt user. See Provision workspace users with SCIM.
• Memberships of the other user type. The workspace configuration writes the workspace membership only, and an end-user configuration writes the end-user membership only, even when one person holds both and the two share one record.
• Anything permanently. SCIM disables users. It never deletes them.

Limits

• Workspace users have no groups. Group provisioning applies to end users only. Leave group provisioning off in the IdP application that feeds the workspace configuration.
• No per-integration access for workspace users. accessLevel accepts administrator, manage, monitor, and none. To give someone specific integrations only, provision them as none and grant those integrations in Celigo.
• End-user roles must exist first. SCIM assigns existing end-user roles by exact name and never creates one. Create end-user roles through the Celigo REST API before you map the attribute. See Provision workspace users with SCIM.
• No capability set assignment. SCIM pushes group memberships, not capability sets. Assign capability sets from the group's own configuration or from the capability set's Access tab. See Create and manage capability sets on MCP servers.
• No bulk requests, sorting, ETags, or password changes. Each user or group change is one request.
• Lookups match one attribute exactly. Celigo finds users by userName, and end users also by externalId. It finds groups by displayName. Set your IdP's matching attribute to userName.
• Exact, case-sensitive group names. Finance doesn't match finance. On a group push, Celigo ignores a renamed displayName and keeps syncing members to the existing group under its original name, so rename the group in Celigo too. Renaming a group in Celigo breaks the match for memberships sent on a user's groups attribute until the names agree.
• One identity provider per end user. An end user already managed by one identity provider's SCIM configuration can't be claimed by another. The second push fails with a conflict error.
• The IdP owns active. If you disable a SCIM-managed user in Celigo, the next push that carries active: true, which many IdPs send on every update, re-enables them. Deactivate people in the IdP.
• Rate limits apply per source IP address. When your IdP sends too many requests at once, Celigo throttles the extra requests and the IdP retries them. A large initial synchronization takes longer than its size suggests.
• Per-environment configuration. A token generated against one environment can't provision users into another, so a sandbox token doesn't work against production.
• Account API tokens aren't revoked. Deactivating a workspace user revokes the personal access tokens that person created in the account. API tokens belong to the account, not to a person, and stay active.
• Verification emails. When SCIM creates a membership for a person whose email address isn't yet verified with Celigo, Celigo sends the standard Verify your email address email. If the workspace and end-user configurations each create a membership for the same unverified address, each create sends one.

Frequently asked questions

Can one SCIM application in my IdP manage both workspace users and end users? No. Each configuration has its own base URL and tokens. Create one SCIM application per configuration.

What happens to users I already invited? The first time the IdP pushes a person who already exists in Celigo, Celigo adopts the existing record and applies the IdP's access level or memberships. Nothing is duplicated and nothing is removed.

Does SCIM change how people sign in? No. Workspace users sign in through your account's SSO as before. End users sign in through the identity provider as before, or with Celigo credentials if their domain isn't routed to an IdP. SCIM decides who exists and what they can reach, not how they authenticate.

Can I still invite users and edit them in Celigo? Yes. Invitations keep working for anyone the IdP doesn't manage. You can also edit a SCIM-managed user's access level or groups in Celigo, but the next push overwrites what the IdP controls. Make those changes in the IdP.

Does deactivating an end user sign them out of their MCP client? It revokes the access and refresh tokens the client holds for this account, so the next call or token refresh fails. The person can't sign in again until the IdP reactivates them.

Why did a group appear in Celigo that I never created? Your IdP pushed a group name that didn't match an existing end-user group, and Celigo created it. The new group has no MCP servers, so it grants nothing until you assign some.

Which IdP-side change deletes a Celigo user? None. Removing someone from the SCIM application deactivates them and keeps the record. Deleting the person in the IdP doesn't deactivate them either. To delete a user, do it in Celigo.

Learn more

• Provision workspace users with SCIM
• Provision end users with SCIM
• Troubleshoot SCIM provisioning
• Set up single sign-on (SSO) for an account
• Manage user roles & permissions to an account
• View or download your audit logs