- What it is
- SCIM endpoints
- Configure (step by step)
- Authentication
- What gets synced
- Auditing
- Troubleshooting
- Related
What it is
qlture implements a SCIM 2.0 server: we are the Service Provider, and your identity provider (IdP) is the client. This means creating, updating, and deactivating users (and groups) in qlture happens automatically, driven by your directory. No more inviting people one by one and forgetting to remove those who leave.
Compatible with Microsoft Entra ID, Google Workspace, and Okta.
flowchart LR
I["Your IdP<br/>Entra · Google · Okta"] -->|SCIM 2.0| Q{Action}
Q -->|Create / update| U[User in qlture]
Q -->|active = false| D[Deactivate + end sessions]
Q -->|Groups| G[Synced groups]
classDef hl fill:#c6ff00,stroke:#c6ff00,color:#070a0e;
class U hl
SCIM endpoints
The IdP talks to the Base URL shown in the dashboard under the Tenant URL (SCIM) field; copy it with the Copy button. Beneath it sit the protocol’s standard resources: /Users, /Groups, /ServiceProviderConfig, /ResourceTypes, and /Schemas.
Configure (step by step)
In the dashboard, under Settings → Provisioning (TENANT_ADMIN access):
- Click Generate token. qlture creates a bearer token in the format
scim_<...>. - Copy the token now, because it is shown only once. We store only a hash (SHA-256); it cannot be recovered later.
- In your IdP, register the provisioning application with:
- Tenant URL / Base URL: the URL shown in the dashboard (Copy button).
- Secret Token: the
scim_...token you copied.
- Set the default role for provisioned users (the default is
COLLABORATOR). - Enable provisioning at the IdP and run a test sync.
The token is shown only at generation. If you lose it, rotate — generate a new one and update the IdP. Rotating invalidates the previous token immediately.
Authentication
Each tenant has its own bearer token. We store only its SHA-256 hash; the plaintext token appears once, at generation. On each request from the IdP, we resolve the tenant by the hash and update the last-sync timestamp — which you can see in the dashboard.
What gets synced
The mapping between SCIM attributes and the qlture model:
| SCIM attribute | Field in qlture |
|---|---|
userName / emails |
email (key) |
name.givenName + familyName / formatted / displayName |
name |
active |
status (false → deactivates and ends sessions) |
enterprise extension → department |
department |
title |
position |
externalId |
external user reference |
| Groups | qlture group collection |
Key points:
- Provisioned users come in as
COLLABORATORby default (configurable), with no password, so they authenticate via OTP in the agent or via SSO. - Setting
active: falseat the IdP deactivates the user in qlture and kills active sessions at that same moment (soft delete — history is preserved). - Provisioning respects your plan’s user limit.
- Groups from the IdP become groups in qlture, ready to segment campaigns.
The PATCH operation covers both ways IdPs send active (with and without path) and is case-insensitive, so Entra, Google, and Okta all work with no tweaks.
Auditing
Every provisioning operation is recorded in the tenant’s audit log: scim.user.provision, scim.user.update, scim.user.deprovision, and scim.token.rotate. You get full traceability of who was created, changed, or offboarded — and when.
Troubleshooting
The IdP gets an “empty request” error or a 400 when creating users.
IdPs send Content-Type: application/scim+json. qlture already handles this correctly — if you’re running your own environment, make sure that content type is accepted before the JSON parser.
The sync “works” but no one shows up. Check the default role and the plan’s user limit. Users beyond the limit are not created.
I need to change the token. Use Rotate in the dashboard. The old token stops working immediately; update the secret in the IdP.
Related
- SSO — manager authentication. Combine SSO (login) + SCIM (lifecycle).
- Getting started — roles and provisioning.
