Skip to main content

QRM

QRM user provisioning. Path prefix: /sight/. Role IDs are integers but must be sent as JSON strings — e.g. { "value": "4" }, not { "value": 4 }. Multiple roles per user are supported. Start by calling GET /sight/UserOrganizationRoles to discover available role IDs before creating users. Role IDs are environment-specific — discover them per environment.

📄️Create a User

Idempotent upsert — if a user with the same email already exists, they are updated instead of created. If the existing user is INACTIVE, the upsert also reactivates them. Still returns 201 in both cases. Role IDs are integers but must be sent as JSON strings — e.g. `{ 'value': '4' }`, not `{ 'value': 4 }`. On upsert, `displayName` is preserved from the existing user record. 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 QRM 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.

📄️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 deactivates the user. A PUT whose `userName` differs from the stored email fails the whole request with **400** `invalidValue`. Note: `displayName` is set at creation time and cannot be changed via PUT. Role IDs are integers but must be sent as JSON strings — e.g. `{ 'value': '4' }`, not `{ 'value': 4 }`. 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` deactivates the user (status becomes INACTIVE); the user remains queryable for reactivation. Session invalidation on deactivation follows the product's own behavior — to guarantee immediate session revocation, use `HTTP DELETE`, which revokes the user's active sessions. Setting `active` to `true` on a deactivated user reactivates them; reactivation may return **409** if the organization user quota is exceeded. PATCHing only `roles` on an INACTIVE user updates the roles but does not reactivate. Azure AD `add` operations on the `roles` path are automatically rewritten to `replace` for Entra ID compatibility. Role IDs are integers but must be sent as JSON strings (e.g. `{ 'value': '4' }`, not `{ 'value': 4 }`).

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

RFC 7644 §3.4.3 search. Send a SearchRequest body; results are identical to `GET /sight/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.