SCIM provisioning

SCIM (System for Cross-domain Identity Management) lets your identity provider - Okta, Microsoft Entra ID, or Google Workspace - automatically create, update, and remove Sencai organization members whenever you make the equivalent change there, instead of managing membership by hand in Sencai.

Note

SCIM provisioning needs a paid organization, but not a particular size of one - every paid plan includes it. See Organization plans. It’s a separate setup step from single sign-on - you can use SCIM provisioning with or without SSO enforcement turned on.

Generating the endpoint and token

Go to Settings → Integrations → SCIM Provisioning (/gravity/settings/integrations/scim). An Owner or Admin can:

1. Copy the SCIM Base URL shown at the top of the page (https://app.sencai.space/api/v1/scim/v2) - this is what you paste into your identity provider’s SCIM connector configuration.
2. Select Generate New Token, optionally giving it a label so you can recognize it later (for example, “Okta production”).
3. Copy the token immediately from the confirmation dialog. It’s shown exactly once - Sencai never displays it again after you close that dialog, and there’s no way to retrieve a lost token, only to revoke it and generate a new one.

Each token expires automatically 90 days after it’s created, and can be revoked at any time from the same page. Use the token as an HTTP Bearer credential (Authorization: Bearer <token>) in your identity provider’s SCIM configuration.

The page includes collapsible setup instructions for Okta, Microsoft Entra ID, and Google Workspace, covering where each provider’s admin console asks for the base URL and bearer token.

Note

Google Workspace has no native SCIM configuration screen for custom applications - provisioning there goes through Admin Console → Apps → Web and mobile apps → Add custom SAML/SCIM app, or a custom integration against Google’s own Cloud Identity SCIM API. If you only need directory data flowing into Sencai (not provisioning triggered from Google), see Workspace directory instead - it doesn’t require a custom SCIM app.

What syncs

A SCIM user maps directly onto a Sencai organization member:

SCIM attribute	Sencai field
userName	Email address
name.givenName / name.familyName	First name / surname
active	Whether the account is disabled

A user your identity provider creates or updates through SCIM gets the role asserted on their own user record, not always Member:

• If your IdP sends role information for the user - Entra’s roles attribute is the primary path, though groups is read too, since some providers push it there instead - and it names a role your organization uses (however that group is named), that’s the role they get, up to Admin; SCIM can never provision someone as Owner.
• If nothing is asserted at all, they’re added as Viewer - the safest default, not Member.
• If the assertion names Auditor specifically, the person is provisioned as Viewer instead, and a request is filed for your organization’s billing owners to approve - an Auditor seat adds a line to your invoice and isn’t granted without that. See Access requests for how that request is handled today.

Change a provisioned user’s role afterward from the organization’s Members tab if they need different access - see Roles & permissions.

Groups

Your Sencai organization corresponds to a single SCIM group, matching your organization’s overall membership - Sencai doesn’t support provisioning multiple separate groups through SCIM today. Adding a user to that group adds them to your organization as Viewer - a group-membership change carries no role of its own, because the group is your organization. A role asserted on the user’s own record (see above) is applied when your IdP next creates or updates that user; removing them from the group removes their membership.

Caution

Deleting the group from your identity provider doesn’t just remove a grouping - it archives your entire Sencai organization. Only do this intentionally, and never as part of routine group cleanup in your IdP.

Deprovisioning behavior

When your identity provider deactivates or removes a user (typically by setting active: false, matching how most providers signal offboarding through SCIM), that person’s Sencai account is disabled - they can no longer sign in. Their existing organization membership record and any resources they created (instances, runbooks, and similar) are not deleted; a disabled account simply loses access. An Owner or Admin can still see and manage what they owned from the organization’s Members tab and the relevant resource lists.

Testing and troubleshooting

Most identity providers offer a “Test Connection” step when you save the SCIM configuration (see the per-provider instructions on the SCIM page) - run that first to confirm the base URL and token are both accepted before turning on automatic provisioning.

• 401 / authentication errors - the token may have been revoked or expired (90-day limit); generate a new one and update your identity provider’s configuration.
• A newly provisioned user can’t be found in the organization’s Members list - check that your identity provider’s assignment actually completed (some providers queue provisioning on a schedule rather than immediately); the SCIM token page itself doesn’t show a live sync log.
• A user was removed from your IdP but can still sign in - confirm they were fully deprovisioned/deactivated in your identity provider, not just unassigned from an app tile; Sencai only reacts to the provider’s own SCIM update.

What’s next

• Single sign-on - connect Entra ID or Google Workspace for authentication
• Roles & permissions - what each role can do
• Organizations & teams - managing members directly