SCIM API
System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems. There are out-of-the-box solutions for SCIM provisioning in Wrike with OKTA, OneLogin, and Azure AD, covered in detail in the linked Help articles. This page addresses custom SCIM provisioning via API.
It can be used to:
-
Provision new users into Wrike.
-
Provision/update user attributes.
-
Deactivate/delete users in Wrike.
-
Works only on Enterprise-level subscription.
-
Sync is one way only - from IDP to Wrike.
-
User group sync is not supported.
-
User passwords are not stored in Wrike. If user is created via SCIM on an account without SAML SSO, the user will need to use password reset page to create a password.
-
Search is supported only by email address.
-
Wrike uses email address as a username. Upon provisioning or integration Wrike will search for a valid email in userName or emails to use as login.
Note
Because ways of SCIM implementation across different Identity Providers differ a lot (such as error messages, actions that are and aren't supported across different IdPs, etc.), IdP-specific aspects of SCIM functionality and error messages should be investigated by your IdP administrators and in close cooperation with them. Troubleshooting and consulting on the specifics of SCIM implementation in different Identity Providers is outside of Wrike Customer Support scope of work.
-
You must have an account with Enterprise subscription and be an Administrator with the rights to "edit names and emails, add/remove people from groups, export a user list, deactivate and delete individual user accounts", "Configure advanced security settings" and "Grant/revoke admin rights" enabled.
-
Add approved domains. Only users from approved domains will be automatically provisioned to Wrike.
-
Generate a permanent API token.
-
In Apps & Integrations, get your account’s SCIM URL from the SCIM tab of OKTA, OneLogin or Azure AD card.
-
You can use Postman to use our pre-made environment and calls collection. To prepare a Postman environment, download and import:
-
Wrike SCIM calls collection for Postman: Wrike SCIM.postman_collection.json
-
Download and import Wrike SCIM environment, add your base URL + permanent token: Wrike_SCIM_API.postman_environment.json
-
-
List integrated users - GET {{base_url}}/Users - returns a JSON with the information about existing account users that are SCIM-integrated. These are users that were created via invitation and then linked with POST /Users call, AND users that were provisioned via SCIM right away. If you created some users manually and haven't yet integrated them with call #2, they will not show up in the JSON.
-
Get integrated user - GET {{base_url}}/Users/ - add user ID to receive a JSON with the information about that user, for example GET {{base_url}}/Users/KUAH4WFR where KUAH4WFR is the API ID of the user.
-
Search integrated users using eq filter - GET {{base_url}}/Users?filter=userName eq "jerome.chef@scim.test" - searches user by full primary email address.
-
-
User creation - POST {{base_url}}/Users + properly formatted request body (sample request body with explanation find below) - creates a user with attributes specified via request body.
-
User attribute replacement - PUT {{base_url}}/Users/{{user_id}} + a properly formatted request body (sample request body with explanation find below) - re-writes all user attributes according to the request body. This call can be used to update user type and deactivate/activate user.
-
User attribute patch - PATCH {{base_url}}/Users/{{user_id}} + a properly formatted request body (sample request body with explanation find below) - nearly the same, with a difference that request body contains only attributes to be updated and their new values.
-
User deletion - DELETE {{base_url}}/Users/{{user_id}}.
This is a sample request body for creating a user / linking existing user / updating user attributes:
*userName, primary and secondary emails:
-
userName field is mandatory.
-
Emails (primary and non-primary) are optional; there can be as many emails in this block as needed.
-
If there IS NO primary email in the body of request, userName is added as user's primary email address in Wrike.
-
If there IS a primary email in the body of request, it is used as user's primary email address in Wrike.
-
If there are emails in emails and none of them is marked as primary, then userName is added as user's primary address in Wrike and others are added as secondary emails.
**Available locales and what they are:
Here's a sample request body to patch user attributes:
Wrike - SCIM integration allows to define user types of SCIM-linked users on provision or update requests with the help of wrikeUserType parameter.
The accepted values for wrikeUserType attribute corresponding to the default user types are "Regular", "External" and "Collaborator" (capitalised or not).
The link to default user types remains active even if the default types were renamed/modified (e.g. if "Regular user" was renamed to External - request with “Regular” value will be linked to the same user type).
The values for default user type IDs are as follows:
-
Owner: -1
-
Admin: -2
-
Regular: -3
-
External: -4
-
Collaborator: -5
A more robust and reliable method is to refer to user types by their API UIDs - so please always prefer this method. UIDs can be retrieved using one of the following methods:
-
with GET /user_types method in Wrike API.
-
from the response to CREATE, GET or PATCH methods for existing users.
-
Wrike Support team can provide you the user types UIDs from your account following a request from the account owner or admin.
Important
Please note that the attribute name.formatted cannot be patched using the PATCH method. Its value is generated automatically based on name.familyName and name.givenName user attributes.