SCIM provisioning

Last reviewed: 2026-05-24

SCIM 2.0 lets your identity provider (Okta, Microsoft Entra ID / Azure AD, Google Workspace, OneLogin, or any SCIM-compliant IdP) create, update, and deactivate Accedo users automatically — typically driven by the same lifecycle events that govern your other apps (someone joins → Okta provisions; someone leaves → Okta deprovisions). Pair it with SAML SSO for end-to-end identity automation: the IdP owns the user lifecycle, Accedo just listens. SCIM is available on the Standard and Premium plans; on Free the SCIM panel shows an upgrade prompt instead of the token list.

What SCIM does

SCIM (System for Cross-domain Identity Management) is a REST-based protocol your IdP speaks to push user changes into Accedo. Each provisioned action writes the same audit-log row a human admin would, plus a source: 'scim' marker and a tokenId so you can trace any change back to which IdP integration produced it. The supported operations are:

Create user — IdP POST /scim/v2/Users. Accedo creates the account with the role and group memberships supplied in the SCIM payload.
Update user — IdP PUT /scim/v2/Users/:id. Name and email changes flow through.
Deactivate user — IdP DELETE /scim/v2/Users/:id. The user is deactivated, not deleted; sign-off history is preserved.
Create / update / delete group — POST/PUT/PATCH/DELETE /scim/v2/Groups/:id. Group membership changes synced from the IdP feed straight into the same group + auto-assign machinery described in Groups and auto-assign.

Before you start

You need an admin role in Accedo — only admins see Settings → Single Sign-On → SCIM provisioning.
You need an IdP admin who can configure SCIM provisioning on their side. SCIM is typically a separate switch from SAML, even though both live inside the same IdP app.
Each Accedo user that SCIM will manage should be matched to an IdP user via email (case-insensitive). Pre-existing Accedo accounts are linked by email on first SCIM update, not duplicated.
Plan the order of operations: most teams set up SSO first, verify it with a couple of accounts, then turn on SCIM so the IdP starts pushing the rest.

Step 1: Generate a SCIM token in Accedo

The token is the credential your IdP will use to authenticate every SCIM call. Tokens are long-lived (no expiry) and bearer-style, so treat them with the same care as an admin password.

In Accedo, go to Settings → Single Sign-On. The SCIM provisioning panel sits directly under the main SSO form.
Click Generate token. A dialog opens asking for a Token name — give it something that identifies the integration, e.g. Okta production or Entra Dev sandbox. The name appears on the SCIM Tokens table and in the audit log so you can match it back later.
Click Generate. The dialog now shows the plaintext token with a warning banner: This is the only time the token will be shown.
Click the copy icon next to the token. Paste it immediately into your IdP's SCIM-configuration field (see Step 2 below). If you close the dialog before saving the token, you cannot recover it — revoke the new token from the table and generate a fresh one.
Click Done to close the dialog. The new row appears in the SCIM Tokens table with status Active, its created date, and a blank Last used column (which updates on the first SCIM call).

Step 2A: Configure Okta

In the Okta Admin console, open the Accedo SAML app you set up for SSO (or create one — see SSO and SAML first).
Open the Provisioning tab. Click Configure API Integration, then tick Enable API integration.
For Base URL, paste your tenant's SCIM endpoint: https://<your-workspace>.yesaccedo.com/scim/v2. The same hostname your team uses to sign in to Accedo, with /scim/v2 appended.
For API Token, paste the SCIM token you generated in Step 1.
Click Test API Credentials. Okta calls Accedo's SCIM ServiceProviderConfig endpoint and confirms a 200 response. If you see a 401, double-check that you pasted the token without leading or trailing whitespace and that the token is still Active on Accedo's SCIM Tokens table.
Click Save, then under Provisioning → To App tick Create Users, Update User Attributes, and Deactivate Users. Save again.
Assign the app to the users or groups whose lifecycle Okta should push to Accedo. Okta provisions the first batch immediately — watch the SCIM Tokens table's Last used column update and check Users and roles in Accedo to see the new accounts.

Step 2B: Configure Microsoft Entra ID (Azure AD)

In the Entra admin centre, open the Accedo enterprise application. Under Manage click Provisioning → Get started.
Set Provisioning Mode to Automatic.
Expand Admin Credentials. For Tenant URL paste https://<your-workspace>.yesaccedo.com/scim/v2. For Secret Token paste the SCIM token from Step 1.
Click Test Connection — Entra verifies the credentials against Accedo's SCIM endpoint. A green check means you can save.
Click Save. The default attribute mappings (userPrincipalName → email, givenName, surname, etc.) work out of the box; only adjust them if your directory uses non-standard attribute names.
Under Provisioning → Settings, set Scope to either Sync only assigned users and groups (recommended for the initial roll-out) or Sync all users and groups. Set Provisioning Status to On and click Save.
Entra runs the first sync within ~40 minutes (it is intentionally batched). For an immediate push, expand Provision on demand and pick a single user to sync — handy for verifying the integration before letting the full job loose.

Step 2C: Configure Google Workspace

Google's SCIM provisioning is set up under the same custom-SAML app that handles SSO (see the Google Workspace section of SSO and SAML).

In the Google Admin console go to Apps → Web and mobile apps and open your Accedo SAML app.
Open the Auto-provisioning section and click Configure auto-provisioning.
For the Access token, paste the SCIM token from Step 1. For the Endpoint URL, paste https://<your-workspace>.yesaccedo.com/scim/v2.
Click Continue. Google validates the credentials by hitting the SCIM ServiceProviderConfig endpoint; a successful check lets you proceed.
Map attributes — Google's defaults (primary email, given name, family name) cover Accedo's required fields. Adjust only if you use custom attributes.
Pick which organisational units or groups are in scope, save, and turn provisioning On. Google syncs on a 1-hour schedule; use the Provision now link on a single user to push immediately while you're testing.

Verifying the sync

After the IdP runs its first batch, walk through this checklist in Accedo:

Open Settings → Single Sign-On → SCIM provisioning. The Last used column on your token's row should show today's date — that confirms the IdP authenticated successfully.
Open Users. The new users provisioned by the IdP should appear with the correct names and emails.
Open Activity Log (Standard plan and above). Set the Source filter to From SCIM; you should see one row per provisioned user, all with the SCIM badge and your token's friendly name in the tokenId field of the expanded panel. CSV export honours the same filter if a compliance reviewer needs a record.

If a sync of 150 users produced only 148 SCIM rows, the missing two are either already-existing Accedo accounts that SCIM no-op'd (same email — matched, not created) or rows the IdP marked as failed. Cross-check the IdP-side provisioning log to confirm which.

Rotating and revoking tokens

Treat SCIM tokens the way you treat any long-lived API credential — rotate when an admin who handled the integration leaves, when you suspect leakage, or on a schedule that matches your security policy. The flow is intentionally simple:

Generate a fresh token (same Step 1 procedure). Give it a name that includes the date or a generation tag — e.g. Okta production — 2026 rotation.
Update your IdP to use the new token. Test the connection.
Once the IdP is confirmed running on the new token, return to Settings → Single Sign-On → SCIM provisioning, find the old token's row, and click Revoke. The confirmation dialog explains that revoking immediately blocks the IdP from making further SCIM calls with that credential; existing provisioned users are not affected.

Revoked tokens stay in the table with status Revoked so the audit trail remains intact — you can see when each historical credential was active.

Common pitfalls

Token pasted with whitespace. Some IdP UIs leave a trailing space when you paste; the SCIM endpoint then rejects every request with 401. Re-paste carefully and re-test.
Wrong base URL. The SCIM base is /scim/v2 (singular path), not /scim or /api/scim. Use your workspace's main hostname.
Email mismatch with existing accounts. If the IdP releases jane.doe@corp.com and Accedo already has jdoe@corp.com, SCIM creates a new account rather than updating the old one. Align the addresses before turning provisioning on, or accept the duplicate.
Provisioning scope too broad. Especially with Entra and Google's sync all users options — you can flood Accedo with hundreds of accounts you did not mean to. Start scoped to a single group and broaden once verified.
Free-tier 403. If the panel shows the upgrade nudge instead of the tokens table, your tenant is on the Free plan; upgrade to Standard or Premium to use SCIM.