Skip to main content
Use SCIM to provision users and groups for a SAML connection. Start with Single sign-on and user provisioning to configure the connection and choose how Hyperline assigns roles.

Endpoint and authentication

Copy the SCIM endpoint and bearer token from your connection’s setup assistant. The SCIM token is separate from your Hyperline API key. Sandbox and production use separate connections and credentials; use the endpoint belonging to the account you want to update. The examples below use placeholders for the SCIM domain, connection ID, token, and resource IDs. Replace the entire base URL with the one shown in your setup assistant. Do not send these requests to the Hyperline public API host. Treat returned resource IDs as opaque strings. Preserve the full value, including any provider prefix. URL-encode IDs in request paths, but use their original, unencoded value in JSON bodies.

User fields and SAML mapping

Configure the following fields in your identity provider. Apart from NameID, the SAML column uses the short attribute names; use the full names shown in the setup assistant. For connections configured with the username mapping, set SAML NameID to the same value as SCIM userName. If your identity provider also sends an explicit nameidentifier attribute, keep its value aligned with NameID. Keep the current email address in emailaddress. You do not need a separate Hyperline username. Your SAML identity provider and provisioning service can be separate systems: send the email address in NameID and userName, and retain the provisioning service’s UUID in externalId. You do not need to copy that UUID into the SAML identity provider. The same person can have a resource in each environment. Store returned SCIM IDs per connection, even when the email and externalId are identical across environments.

Existing connections and identifier changes

Existing connections may still use externalId to construct login identities. A connection configuration change affects newly created identities only; it does not migrate users already provisioned with UUID-based identities. Reopening the setup assistant does not migrate those accounts either. Before switching an existing connection to email-based SAML identifiers:
  1. Contact Hyperline through the in-app chat. Specify the account and environment, and provide one user’s current SCIM id, externalId, userName, and SAML NameID. Keep the current sign-in mapping until the migration is coordinated.
  2. Hyperline confirms the connection mapping and migrates any existing identities that need it, preserving their SCIM resource IDs, provisioning identifiers, memberships, and roles. Sandbox and production must be checked separately.
  3. Once the identities are ready, configure your SAML provider to send the exact SCIM userName as NameID. Keep the provisioning system’s original UUID in externalId and continue addressing SCIM updates using the returned id.
  4. Verify sign-in with an existing member and a newly provisioned member. Confirm both can access the expected account with the expected role, and that SCIM updates still reach the existing member.
If you need to reopen the connection’s setup assistant, use Settings > General > Single sign-on > Reconfigure in Hyperline. See Manage your connection for the provisioning settings to review afterward. A later username or email rename also needs coordination before your SAML provider sends the new NameID. A successful PATCH of userName or externalId updates the stored field but does not change the login identity or SCIM resource ID. Restoring a missing externalId means sending its original value, not replacing a UUID with an email address.

Update a user

Send a SCIM PATCH to the existing resource. This example changes only userName; it preserves the email and stable identifiers:
To change the email too, update the primary emails entry explicitly and align the SAML email attribute. Coordinate email changes before the member signs in with the new address.

Repair missing fields on existing users

Enabling a mapping does not backfill older resources. First confirm the connection maps the required attribute; contact Hyperline through the in-app chat if an existing connection drops it. Then PATCH the existing user with the authoritative value from your identity provider. Use the same request format above with the relevant operation: These updates preserve the SCIM resource ID. Never invent a replacement externalId or recreate a user just to fill missing data. Filter by the stored externalId:
Filtered reads can lag behind a successful write. Keep the returned resource ID and retry with backoff; an immediate empty search result is not a reason to create another user. If lookup remains empty or creation returns a conflict, contact Hyperline through the in-app chat before deleting or recreating identities.

Assign roles directly

Use an array of role objects, not an array of strings. Set value to an existing role’s exact name or ID in the target Hyperline account:
Send one role, or mark exactly one entry as primary: true when sending several. Unknown or ambiguous roles prevent the Hyperline member update from being applied; SCIM does not create roles. A direct role takes precedence over group mappings. Replacing roles with [] selects the default role, even when group role synchronization is enabled. Omitting roles leaves the previously stored value in place. Neither operation hands role management back to groups. Contact Hyperline before switching methods; see the role assignment rules.

Assign a manager

Provision the manager through the same connection first. Send the manager’s full returned SCIM user id in the enterprise extension’s manager.value. A raw identity provider user ID, email, or externalId is not a substitute. The manager must also belong to the same Hyperline account and cannot be the user being updated. An unresolved manager can prevent the entire Hyperline member update from being applied, including other supplied fields. Provision the manager, then resend the dependent user’s update. An explicit empty or null manager value clears the assignment. Omitting the field preserves it. See Assign managers through SCIM for configuration and owner exclusions.

Update group membership

Use the user’s returned SCIM id as the member reference:
To remove that member, use this operation in the same PATCH envelope:
A successful group PATCH can return 204 No Content. Read GET /Groups/{id} to check membership: the group collection response can contain an empty members array even when the group has members. Group role assignment requires both user provisioning and group role synchronization to be enabled, with saved mappings. Membership changes then update roles without a new SAML login. SAML group assertions do not replace SCIM group updates. Direct user roles still take precedence; see Configure group mappings.

Verify the Hyperline result

A successful SCIM response confirms the directory accepted the request. Hyperline processes membership changes asynchronously. Check Settings > Team > Members after processing, and View groups > View members in role provisioning for group changes. If the member remains unchanged, confirm the account’s connection and provisioning settings, then check supplied roles and manager references. Correct invalid values and resend the update. Contact Hyperline through the in-app chat with the affected resource ID and request time if it still does not apply. Do not include bearer tokens. Suspension and deletion follow the membership lifecycle rules. In particular, another active identity for the same member in the same connection keeps their membership; account owners are excluded from automatic removal. Separate sandbox and production identities are expected. Do not merge or delete them based on matching email alone.

Connection response limitations

The Auth0-backed SCIM endpoint has the following behavior: