SCIM provisioning reference

The protocol surface RoundUp exposes to an identity provider — for the person configuring a connector, or reviewing one.

Technical reference · SCIM 2.0 (RFC 7643 / 7644)

At a glance

Endpoints

Each identity provider has its own base path. A center's token is only valid on the base path of the provider that issued it.

Discovery endpoints are served on each base path and require the same credential as any other call: /ServiceProviderConfig, /ResourceTypes, /Schemas.

Authentication

Every request carries Authorization: Bearer <token>. The token is an HMAC-signed assertion of a single center's identifier, so each request resolves its own tenant with no shared credential store to look anything up in.

Tokens are minted fresh each time a director opens the provisioning screen rather than stored, so re-reading that screen is how a token pasted somewhere wrong gets rotated. A token is scoped to one center and one provider; it cannot reach another center's records.

There is no OAuth flow on the JumpCloud path — no authorization endpoint, no token endpoint, no client credentials. ServiceProviderConfig reports the scheme as oauthbearertoken, which is SCIM's name for bearer-token authentication, not an indication that OAuth is in use.

Supported operations

ServiceProviderConfig

User attributes

Required. userName — the only hard requirement. A create without it, and without a primary entry in emails, returns 400 invalidValue.

Whatever occupies userName must be an email address, because that is how a provisioned user is matched to a RoundUp staff account. A non-email userName with no emails array creates a SCIM record that never becomes a staff account — a silent half-success worth avoiding.

Everything else is discarded — not stored, and absent from the read-back. That includes phoneNumbers, addresses, title, userType, locale, timezone, photos, ims, nickName, profileUrl and preferredLanguage. A connector that writes one of these and reads it back will not find it.

Deactivation

Setting active to false — or issuing a DELETE — disassociates the person from that center:

• their membership of the center is removed, ending access to rosters, family contacts, photos, messages and billing;
• live sessions are revoked, including on a shared classroom tablet;
• their identity record and any memberships at other centers are left intact;
• their history stays and stays attributed — incident reports, check-ins and medication logs are licensing records the center must keep.

It is not a delete, a soft delete, a suspension or a lock. Nothing is retained in a blocked state, and there is no unlock path — re-provisioning creates the membership again.

The center owner cannot be deprovisioned over SCIM; that request is refused with 400, so removing the wrong person in a directory cannot lock a center out of its own account.

Errors

Uniqueness is scoped per provider, not per center: a staff member already provisioned by a different directory does not make this one's create fail. A connector reads a 409 as "provisioning is broken" and stops, so the scope matters.

Limits and omissions

• No Group resource. Assigning a directory group to the application still scopes who is provisioned — the group itself is simply not created as a resource here.
• No password syncing. A password attribute is discarded. RoundUp passwords are set by the staff member through their own invitation and cannot be read or set by anyone else.
• No bulk, sort or ETag support.
• Filtering returns at most 200 results per page.

More: All director guides