SCIM 2.0 Provisioning
PurpletGo exposes a SCIM 2.0-compliant endpoint that your identity provider (IdP) can call to push deprovisioning events directly into PurpletGo. When your HR or IT team deactivates a user in Okta, Azure AD, or JumpCloud, PurpletGo automatically creates an offboarding record - eliminating the need to manually initiate offboarding in two systems.
How it works
- HR deactivates an employee in the IdP (or the HRIS pushes the change to the IdP via its own sync).
- The IdP calls PurpletGo's SCIM endpoint with a
PATCH User(settingactive: false) or aDELETE Userrequest. - PurpletGo creates an offboarding record in the
notice_periodstage, with separation typetermination, using whatever employee details it already has on file. - If an automation rule is configured to trigger on record creation, it fires immediately - for example, notifying HR or assigning a checklist.
DELETE User does not delete anything from PurpletGo. It's treated exactly like a PATCH with active: false - it creates (or reuses) the offboarding record. Nothing about the employee's history is removed, and if an offboarding is already in progress for that person, PurpletGo won't create a duplicate.
SCIM provisioning creates offboarding records; it does not itself revoke access. Access revocation is handled by PurpletGo's identity integration during the it_revocation stage. See Integrations for details.
Generating a SCIM bearer token
Open SCIM settings
Navigate to Settings → SCIM Provisioning and click Generate Token.
Copy the token
The token is shown once. Copy it immediately and store it in a secrets manager. If you lose it, you must generate a new token, which invalidates the old one.
Note the SCIM base URL
Your SCIM base URL is displayed on the same page. It follows the format:
https://app.purpletgo.com/scim/v2/
This URL and the bearer token are the two values you will enter in your IdP.
Rotate your SCIM bearer token if you suspect it has been compromised. All active SCIM calls will fail until you update the token in your IdP configuration.
Configuring your IdP
Open your Okta application
In the Okta Admin Console, navigate to Applications and open the application that represents PurpletGo (create one if needed using the SCIM template).
Enable SCIM provisioning
Go to the Provisioning tab and click Configure API Integration. Enable the integration and paste the SCIM base URL and bearer token.
Enable deprovisioning
Under To App settings, enable Deactivate Users and optionally Sync Password. Ensure Push Groups is configured if you use group membership to trigger offboarding.
Test the connection
Click Test API Credentials. Okta will call the SCIM /ServiceProviderConfig endpoint. A green checkmark confirms the connection.
Assign the application
Assign the application to the user groups whose deprovisioning should trigger PurpletGo offboarding records.
What gets populated
When your IdP provisions a user (POST /Users), PurpletGo stores it as an org_employees record with these fields:
| Field | Source |
|---|---|
The primary entry in emails, falling back to userName | |
| Name | displayName, falling back to name.formatted, falling back to givenName + familyName |
| Title | title |
| Department | department |
| Employee ID | externalId (falls back to id if externalId isn't sent) |
A second provisioning call for the same email address updates that same record instead of creating a duplicate - PurpletGo matches on email per organization.
When the offboarding record is later auto-created (via PATCH or DELETE), it's pre-filled from whatever is already on the org_employees row at that point, not from a fresh SCIM payload. Fields PurpletGo doesn't have - like manager - aren't captured through SCIM at all and can be filled in manually from the offboarding record.