RSC

RSC user provisioning. Path prefix: /rise/. Role IDs are UUIDs. Multiple roles per user are supported. Invitations are auto-accepted on create, so users surface as ACTIVE immediately; a PENDING user (auto-activation failed) is invisible to GET (list and by-id) but can still be removed via DELETE /rise/Users/{id}. Start by calling GET /rise/UserOrganizationRoles to discover available role IDs before creating users. Role IDs are environment-specific — discover them per environment.

📄️Retrieve User Organization Roles

Returns the role catalog for this product. Default page size is 500. Role IDs are environment-specific — discover them again when moving between pre-production and production.

📄️Retrieve a specific User Organization Role

Retrieve a specific User Organization Role

📄️Retrieve Users

Returns SSO-provisioned users for the tenant ecosystem. PENDING users (invitation not yet accepted) are not returned — neither in this list nor via `GET /rise/Users/{id}` (404). A pending invitation can still be removed via `DELETE /rise/Users/{id}`. Default page size is 500 when no pagination parameters are provided.

📄️Create a User

Idempotent upsert — if a user with the same email already exists, they are updated instead of created. Still returns 201 in both cases. On upsert, `displayName` is **not** modified — the existing user's value is preserved and the value in the request body is discarded. On production, a successful POST may send a first-access email; users created via this API are SSO-only and cannot log in with username/password. There is no SCIM-side API to check delivery or re-send it — use the RSC product UI for re-sends. A POST without at least one role returns **400** (the error message contains the word 'role'); the request has no effect and no first-access email is sent. Troubleshooting — if a user you provisioned is absent from both the GET list and `GET /rise/Users/{id}` (404), the invitation may still be PENDING (activation failed). Remove the pending invitation with `DELETE /rise/Users/{id}` (204) and re-create the user via POST.

📄️Retrieve a specific User

Retrieve a specific User

📄️Replace a User

Full replacement of a user resource. Updates `active` status and `roles`. **Always send `active` explicitly** — a PUT that omits `active` is treated as `active: false` and permanently removes the user. Note: `displayName` is set at creation time and cannot be changed via PUT. Email addresses (`userName`) are immutable post-creation — to change a user's email, delete and re-create.

📄️Update a User

Supported paths: `active`, `roles` — only these produce observable changes. Operations on non-persisted attributes (`displayName`, `externalId`) return a silent 200 no-op; an operation changing `userName` fails the whole request with 400 `invalidValue` (including any other operations batched in it); unknown or miscased paths (e.g. `Roles`) fail 400 `invalidPath`. Send `active` changes and `roles` changes as separate PATCH requests — combined in one request, the deactivation wins and the role change is silently discarded (the 200 response echoes the old roles). Email addresses (`userName`) are immutable post-creation — to change a user's email, delete and re-create. Setting `active` to `false` removes the user from RSC (deletion). Reactivation by `active: true` is not supported — re-create the user via POST. PATCHing `active: true` against a previously-deleted RSC user returns **404** (detail `Resource: <id> wasn't found`), not a friendly 'not supported' message. Azure AD `add` operations on the `roles` path are automatically rewritten to `replace` for Entra ID compatibility.

📄️Delete a User

Permanently removes the user from RSC. There is no reactivation path — re-create the user via `POST` if needed.

📄️Search Users (POST alternative to GET with filter)

RFC 7644 §3.4.3 search. Send a SearchRequest body; results are identical to `GET /rise/Users` with the same `filter`. Note: the response `itemsPerPage` echoes the requested `count`, not the number of resources actually returned. **Warning:** a request body sent with a Content-Type other than `application/scim+json` or `application/json` is not parsed, and the request does NOT fail — it returns an unfiltered list of ALL users. Always set a supported Content-Type on `.search` requests.