AACSearch / guide
SCIM provisioning
Synchronize organization membership from an identity provider: connect it with a SCIM token, understand what Users and Groups cover, and rotate or revoke tokens safely.
SCIM synchronizes organization membership from an identity provider. It is separate from SSO and from tenant API keys: SSO signs people in, SCIM creates and removes their membership.
Connect an identity provider
Select the organization
Open Settings → SCIM.
Create a SCIM token
As organization owner, create a named SCIM token and copy the returned secret immediately into your identity provider's protected credentials.
Copy the base URL
Displayed in Console (/scim/v2 on the API origin). Authenticate with
Authorization: Bearer YOUR_SCIM_TOKEN, not X-NOVA-API-KEY.
Discover the supported operations
Read ServiceProviderConfig, ResourceTypes and Schemas. Test with a
non-production user and group.
curl https://api.aacsearch.com/scim/v2/ServiceProviderConfig \
-H "Authorization: Bearer $SCIM_TOKEN"Verify: the config answers 200 and lists the supported options below. A
missing or revoked token answers 401.
What the implementation supports
| Feature | Supported |
|---|---|
PATCH on Users and Groups | Yes |
PUT on Users (replace) | Yes |
| Filtering | Yes, up to 200 results |
| Bulk operations | No |
| Sort, ETag, change password | No |
Read this from ServiceProviderConfig rather than assuming full SCIM coverage:
an identity provider that requires a feature in the "No" column needs a
different sync strategy for it.
Users
A SCIM User is a console user plus their membership row in the token's organization. The mapping matters when you configure the provider:
userName/emails— the email that identifies the account.displayName/name— the person's name.externalId— stored so the provider and the platform agree on identity.active— whether the user is a member of this organization.
active is membership, not the account
Deactivating a user removes their membership in the selected organization. It does not delete the person's account, and it does not affect their membership of any other organization. Check the resulting roles and access in Console before enabling automatic provisioning broadly.
GET /Users lists members and supports filtering; POST /Users creates one,
PUT /Users/{id} replaces it, PATCH /Users/{id} changes it, and
DELETE /Users/{id} removes the membership.
Verify: create a test user through the provider, confirm they appear in Console under Team, then deactivate them and confirm the membership disappears while the user's account remains.
Groups
A SCIM Group is more limited than a provider's UI usually suggests: a user's group is their organization role.
GET /Groups and GET /Groups/{id} list them; PATCH /Groups/{id} changes
membership of a role. There is no POST or DELETE for Groups — the set of
roles is defined by the platform, not created by your provider.
Configure the provider to map its groups onto the organization's existing roles, and confirm in Console → Team → Roles that the expected people end up with the expected role.
Operate and revoke
Review recent SCIM activity and the organization audit log. Revoke unused tokens from the SCIM settings page. To rotate:
- Create a replacement token.
- Update the identity provider with it.
- Verify a request succeeds.
- Revoke the old token.
Never paste tokens into tickets, source control or logs. A token is bound to one organization and cannot be used for the tenant API.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
401 on every request | Token revoked, mistyped, or X-NOVA-API-KEY used instead of Bearer | Send Authorization: Bearer <scim_…> |
404 on /scim/v2/... | Wrong origin — SCIM lives on the API origin, not the console | Use the base URL shown in Console |
| Unsupported filter or operation | The provider needs a feature in the "No" column above | Adapt the provider's sync to the supported subset |
| User created but has no access | active false, or the group maps to a role without permissions | Check membership and the mapped role |
Next
- Single sign-on — the authentication half of the same setup.
- Console authentication — sessions, passwords and invitations.
- Console → Organization — roles and the audit log.
Single sign-on
OIDC sign-in for the console, the callback URL to register with your identity provider, requiring SSO for an organization, and where SSO ends — provisioning and authorization live elsewhere.
Limits and quotas
The monthly request quota per plan and what counts against it, rate limits per key scope, the per-session AI allowance, and request size limits.