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 fromNameID, 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 useexternalId 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:
- Contact Hyperline through the in-app chat. Specify the account and environment, and provide one user’s current SCIM
id,externalId,userName, and SAMLNameID. Keep the current sign-in mapping until the migration is coordinated. - 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.
- Once the identities are ready, configure your SAML provider to send the exact SCIM
userNameasNameID. Keep the provisioning system’s original UUID inexternalIdand continue addressing SCIM updates using the returnedid. - 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.
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 onlyuserName; it preserves the email and stable identifiers:
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:
Assign roles directly
Use an array of role objects, not an array of strings. Setvalue to an existing role’s exact name or ID in the target Hyperline account:
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 userid 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 SCIMid as the member reference:
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.

