SCIM Provisioning

This is a Cloud-only feature (available in Free and Professional plan).

Seatsurfing supports SCIM 2.0 provisioning so your identity provider can automatically create, update, deactivate, and delete users and groups in your organization.

Supported identity providers include:

• Okta
• Microsoft Entra ID
• Keycloak
• Google Workspace
• Workday
• OneLogin
• PingOne

SCIM provisioning in Seatsurfing is a one-way sync from your identity provider into Seatsurfing. It is intended for user and group lifecycle management only.

What SCIM can do

• Create, update, deactivate, and delete users in your Seatsurfing organization.
• Create, update, and delete groups.
• Add and remove group memberships.
• Reactivate previously deactivated users.

What SCIM does not do

• It does not sync passwords.
• It does not manage spaces, locations, or bookings.
• It does not push changes from Seatsurfing back to your identity provider.
• It does not support SCIM 1.1 or SCIM bulk operations.

Prerequisites

• A Seatsurfing Cloud organization.
• Organization administrator access to Seatsurfing.
• An identity provider that supports SCIM 2.0.
• A dedicated Seatsurfing service account with read/write permissions.

Step 1: Enable SCIM in Seatsurfing

In the Seatsurfing Administration UI, open Cloud Features and enable SCIM provisioning for your organization.

After saving, Seatsurfing shows the SCIM Base URL for your organization. Use this URL in your identity provider's SCIM application.

The SCIM base URL has this format:

https://<your-seatsurfing-domain>/scim/v2/

Step 2: Create a dedicated service account

SCIM authentication uses a Seatsurfing service account API token.

We recommend creating a dedicated service account only for SCIM provisioning:

1. Open the Users section in the Administration UI.
2. Create a new user with the Service Account role, or use an existing dedicated service account.
3. Generate an API token for that service account.
4. Keep the raw token value secure and copy it immediately into your identity provider configuration.

The service account is scoped to its Seatsurfing organization, so all SCIM operations only affect users and groups in that organization.

See also: Administration UI

Step 3: Configure your identity provider

In your identity provider's SCIM application, configure:

• SCIM Base URL: your Seatsurfing SCIM endpoint, for example https://<your-seatsurfing-domain>/scim/v2/
• Authentication method: Bearer token
• Bearer token: the raw API token generated for the Seatsurfing service account

Seatsurfing expects the Bearer token on all SCIM requests, including discovery endpoints such as ServiceProviderConfig, ResourceTypes, and Schemas.

Supported provisioning behavior

Users

Seatsurfing maps the following SCIM user attributes:

SCIM attribute	Seatsurfing field	Notes
id	Internal user ID	Generated by Seatsurfing
externalId	External mapping	Stored for the identity provider reference
userName	Email address	Must be unique within the organization
name.givenName	First name	Optional
name.familyName	Last name	Optional
active	User enabled state	active=false disables the user instead of deleting it

Additional attributes such as phone numbers, locale, timezone, title, addresses, or password fields are accepted when sent by the identity provider, but ignored by Seatsurfing.

Groups

Seatsurfing maps the following SCIM group attributes:

SCIM attribute	Seatsurfing field	Notes
id	Internal group ID	Generated by Seatsurfing
externalId	External mapping	Stored for the identity provider reference
displayName	Group name	Required when creating groups
members[].value	Group membership	Must reference Seatsurfing user IDs in the same organization

Deactivation and deletion

When your identity provider sends active=false for a user, Seatsurfing disables that user account instead of deleting it. If the user is activated again later, Seatsurfing re-enables the same account.

A SCIM DELETE request permanently deletes the corresponding user or group in Seatsurfing.

Compatibility notes

Seatsurfing is designed to work with the request patterns commonly used by the supported identity providers. This includes:

• User lookups by email address or external ID.
• User deactivation via SCIM PATCH.
• Group membership add and remove operations.
• Group synchronization requests that omit members for performance reasons.

Unknown or provider-specific attributes are ignored where possible so that provisioning can continue without unnecessary failures.

Security notes

• Use a dedicated service account for SCIM only.
• Only the service account API token is supported for SCIM authentication.
• Regular Seatsurfing login sessions are not valid SCIM credentials.
• Revoking the service account token immediately breaks the SCIM connection until a new token is configured in your identity provider.

Troubleshooting

If provisioning requests fail, check the following first:

• SCIM is enabled in Cloud Features.
• The configured URL ends with /scim/v2/.
• The Bearer token belongs to a Seatsurfing service account with read/write permissions.
• The service account belongs to the correct Seatsurfing organization.
• The identity provider is sending SCIM 2.0 requests, not SCIM 1.1.

If user provisioning works but sign-in does not, remember that SCIM only manages users and groups. Authentication itself must still be configured separately, for example through Seatsurfing passwords or a supported identity provider login setup.