If you’re an Administrator on Go1, you can provision and manage users and groups in your Go1 portal with SCIM.

When SCIM is configured with your Identity Provider, people in your organization will automatically get a Go1 user account provisioned. It will also keep your members in sync by adding new users to your Go1 portal and removing people that have left your organization.

What you can do using SCIM with Go1

User provisioning and management:

Create and remove users in your portal

Update a user’s profile information including their access level (role)

Assign or update a user’s manager

Group provisioning and management:

Create Go1 groups from Okta permission groups (not supported in Azure)

Add and remove members in a group based on Okta permission groups (not supported in Azure)

For advanced users, please see our developer documentation on the SCIM endpoint for more information.

How to set up provisioning with SCIM

We currently support Okta, Azure and custom SCIM applications via APIs.

Configure your identity provider using the guide below.

Okta SCIM configuration
Azure AD SCIM configuration
SCIM Integration via APIs

For other identity providers, please refer to their respective documentation on how to complete this step.

Prerequisites for SCIM with Go1

Only an Administrator can configure SCIM for a Go1 portal, and you will need administrator access to your chosen identity provider

If you want to use SCIM to modify a user's email address, you must be an Administrator on all portals that user is a member of

If using SCIM APIs, accommodate authentication with portal specific credentials

Supported attributes — SCIM schema reference

For supported SCIM attributes (core user fields, role GUIDs, manager assignments, profile fields, and custom fields), see Supported attributes.

Okta SCIM configuration

Go1's Okta SCIM integration supports the following:

Create and remove Go1 users
Create Go1 groups from Okta permission groups

Add and remove members in a group based on Okta permission groups

Keep user attributes synchronized between Okta and Go1, including name, email addresses and permissions
Users created in Go1 can be provisioned into Okta (matched against existing Okta users or created as new users)
Groups created in Go1 can be imported into Okta

Step 1: Add Go1 SCIM app to Okta

Log in to your Okta Admin Console and click on Applications
Click to Browse App Catalog and search for Go1
Click + Add integration to install the Go1 SCIM app to your Okta instance and follow the setup wizard

Step 2: Configure Go1 SCIM app

In the Go1 SCIM app, select the Provisioning tab and click Configure API integration
Select the checkbox to Enable API integration
Click to Authenticate with Go1 which will trigger an authorisation
Enter your Go1 email address and password and follow the prompts to authorize Okta to access your Go1 users and groups
After you’ve successfully authenticated, click Save

Step 3: Enable provisioning

Under the Provisioning tab, click on To App from the side menu.
Click to Edit and select the checkboxes to enable Okta to Create users, update user attributes and deactivate users in Go1. Click Save.

The Go1 app will show the mapped attributes. This example includes locale, the standard field job_title, and the additional field postal_code:

To map additional fields, follow these Okta instructions.

Okta SCIM troubleshooting

The View Logs page can be useful for viewing what SCIM actions are being run. For each user update there should be two corresponding logs: one for the change being made in Okta, and one to show the change was pushed to the Go1 app.

Ensure the roles assigned to users comply with Go1's permissions here.

Users cannot have both Administrator and Content Administrator roles; in these cases only the Content Administrator role will be applied.

Azure AD / Entra ID SCIM configuration

Go1's Azure SCIM integration supports the following provisioning features:

Create users
Remove users
Keep user attributes synchronized between Azure AD and Go1, including name, email addresses and permissions
Manager assignment and removal

Step 1: Create an app in Go1

In your Go1 account, select Integrations and then Developers, under the main menu in the top right.
Click + Create app to create a new private oAuth application. Choose a name and redirect URI for your app and click to Create application
Keep a record of the new Client ID and Secret generated - you will need these in Step 3.

Step 2: Create an Enterprise Application in Azure AD / Entra ID

In your Azure Portal, go to Azure Active Directory.
Under the Manage section, click on Enterprise applications.
Click the + New application button and choose Create your own application.
Give your application a name, select the Integrate any other application you don't find in the gallery (Non-gallery) option, and click the Create button.

Step 3: Configure automatic user provisioning in Azure AD / Entra ID

In the Azure app created, select the Provisioning tab.
Set the Provisioning Mode to Automatic.
Under the Admin Credentials section, Azure will default the Authentication method to Bearer Token, instead set to OAuth2 Client Credentials Grant and input the following:
1. Tenant URL: https://gateway.go1.com/version/2022-07-01/scim
2. Client ID and Secret token: The values generated in Step 1
3. Token Endpoint: https://auth.go1.com/oauth/token
Click Test Connection to ensure Azure AD can connect to Go1. If the connection fails, ensure your Go1 account has Admin permissions and try again. Once the connection test is successful, at the top of the settings window click Save.

Step 4: Configure attribute mappings

In your Azure app, select Provisioning. Under Mappings, select Provision Microsoft Entra ID Users.
Add Go1-specific target attributes
Before mapping Go1 fields that aren’t already listed, add them to the target attribute list:
1. At the bottom of the page, select Show advanced options, then select Edit attribute list for customappsso.
2. Add the Go1 target attributes you want to use, then select Save before leaving the page.
For example:
- urn:ietf:params:scim:schemas:extension:Go1Account:2.0:User:managers — String field — User schema
- urn:ietf:params:scim:schemas:extension:Go1StandardField:2.0:User:job_title — String field — User schema
Only add attributes supported by your Go1 portal that you want Microsoft Entra ID to manage. For details about supported Go1 attributes, see the Supported attributes section.
Under the Target Object Actions, make sure to only select Create and Update.
Under Attribute Mappings, configure the attributes you need. To set the user's Platform Language in Go1, map preferredLanguage to locale, as shown in this example:

Configure user attribute mappings
Only map attributes supported by your Go1 portal that you want Microsoft Entra ID to manage. If an attribute is unavailable or greyed out, check whether it is already mapped. If it isn’t, return to Edit attribute list for customappsso, add the target attribute, save, then return to the mapping page.

The following default mappings are normally unnecessary unless they have been specifically configured for your Go1 portal. Remove them to avoid sending unintended data:
- facsimileTelephoneNumber
- Join(" ", [givenName], [surname]) mapped to name.formatted
- mobile
- physicalDeliveryOfficeName
- postalCode
Go1 derives name.formatted from the user's given and family names, so it can’t be set independently.

NOTE: When first setting up the SCIM user provisioning and de-provisioning connection, it is generally safer to avoid enabling the "delete" action. This prevents accidental mass deactivation of users in Go1 when the attribute mapping is not configured correctly. After verifying that the mapping works correctly, you can enable the delete action to support full lifecycle management.

NOTE : externalId recommendation
Mapping the IdP's immutable user ObjectID to externalId is recommended if external_user_id is not already in use for other purposes (e.g. LMS integrations, reporting). This gives Go1 a stable identifier that remains reliable even if the user's email address changes.
Under Users and Groups, click + Add user and select a limited test group or representative test user to provision first.
Test provisioning before enabling it for a wider group
1. Use Provision on demand to test a representative user, including their name, email address, language, manager, and any profile fields you mapped.
2. Confirm that the user record in Go1 has the expected values and role.
3. Review Provisioning logs in Microsoft Entra ID for each test action.
4. If you need de-provisioning, enable the delete action after verifying the mappings. Confirm that deactivation behaves as expected for the limited test scope before expanding it.
5. Once the results are correct, set Provisioning Status to On and click Save.
Saving starts the initial synchronization cycle for users and groups defined in Scope. The initial cycle takes longer than later cycles, which occur approximately every 40 minutes while the Azure AD provisioning service is running. Keep the assignment scope limited until you’ve confirmed the setup works as expected.

Azure AD / Entra ID SCIM troubleshooting
1. In the Azure app, from the sidebar, go to the Monitor section.
2. Select Provisioning logs to see what SCIM actions have been run.

Azure AD / Entra ID provisioning cycles generally run every 40 minutes, so there may be delays before changes in Active Directory appear for users and groups in Go1. The initial synchronization may take longer than later cycles.

The connection test fails: Confirm that OAuth2 Client Credentials Grant is selected, the portal-specific Client ID and Secret are correct, and the Go1 administrator has access to the portal.
An attribute can’t be selected: Check whether it is already mapped. If not, add and save it through Edit attribute list for customappsso, then return to the mapping page.
A field doesn’t update in Go1: Check the target attribute path and extension namespace. An unrecognized field may be ignored without an error response.
A manager doesn’t appear: Confirm that the manager is mapped to urn:ietf:params:scim:schemas:extension:Go1Account:2.0:User:managers, then test the user with Provision on demand.
User changes are delayed: Review Provisioning logs. Microsoft Entra ID runs recurring provisioning cycles, and the initial synchronization can take longer than later cycles.

If you need help, contact Go1 Support with the relevant Microsoft Entra ID provisioning-log entry and the affected user’s identifier.

Supported attributes

All attributes listed here are accepted on write (PATCH/PUT) and returned on read (GET) unless noted otherwise.

A machine-readable schema definition is available at https://api.go1.co/scim/Schemas — no authentication required.

Core User — urn:ietf:params:scim:schemas:core:2.0:User

Attribute	Mutability	Notes
`userName`	readWrite	Unique per portal. Used as the login identifier. Typically the user's email address.
`name.givenName`	readWrite	First name.
`name.familyName`	readWrite	Last name.
`displayName`	readOnly	Derived from `givenName + " " + familyName`. Cannot be set independently.
`emails[].value`	readWrite	Multiple email addresses supported. One must be `primary: true`.
`emails[].primary`	readWrite	Exactly one primary email required at all times.
`active`	readWrite	Set to `false` to deactivate the user.
`locale`	readWrite	Sets the user's Platform Language in Go1. For example, `en-au`.
`password`	writeOnly	Accepted on creation only. Never returned.
`externalId`	readWrite	Maps to `external_user_id` in Go1. Optional. See recommendation below.
`roles[].value`	readWrite	Role GUID. See role GUID reference below.
`roles[].display`	readOnly	Human-readable role name e.g. `"Learner"`.
`groups[].value`	readOnly	Group membership is returned but cannot be managed via SCIM users — use the SCIM Groups endpoint instead.

Role GUIDs

Role GUIDs are static across all portals and environments. Use the GUID in roles[].value when assigning roles.

Role	GUID
Learner	`rol_01G3PZS7NZ0CF95J340P55FSZH`
Manager	`rol_01G3PZS7NZBW04V44QBM48PP0C`
Content administrator	`rol_01G3PZS7NXC78RP57SG0EXD0Z5`
Administrator	`rol_01G3PZS7NCBKB170TEP3CC2BBH`

Manager — urn:ietf:params:scim:schemas:extension:Go1Account:2.0:User

Attribute	Mutability	Notes
`managers`	readWrite	Preferred manager attribute. Array of manager identifiers — each element can be an email address or Go1 account ULID (`acc_…`). Supports multiple managers. On GET, returns an array of email addresses.

The enterprise:manager attribute (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User) is also accepted for backwards compatibility, but Go1Account:managers is preferred and takes priority when both are present.

Profile fields — urn:ietf:params:scim:schemas:extension:Go1StandardField:2.0:User

Attribute	Notes
`job_title`
`job_level`
`department`
`division`
`city`
`state`
`country`
`phone`
`gender`
`industry`
`start_date`	ISO 8601 dateTime e.g. `2024-01-01T00:00:00Z`

Custom fields — urn:ietf:params:scim:schemas:extension:Go1AdditionalField:2.0:User

Portal-specific custom fields can be synced using this extension. Use your actual field name in the attribute path — for example:

urn:ietf:params:scim:schemas:extension:Go1AdditionalField:2.0:User:cost_centre urn:ietf:params:scim:schemas:extension:Go1AdditionalField:2.0:User:employee_id

Field write behaviour

Immutable fields — attempting to PATCH id, meta, or name.formatted returns 400 Bad Request.

All other unrecognised fields — silently ignored. The request succeeds and no error is returned. If a field is not being saved, the most likely cause is an incorrect attribute path or extension namespace.

SCIM user provisioning and de-provisioning