What is changing?
Indeavor is improving our security! We will be updating and unifying our methods of authentication for interacting with Indeavor APIs via the use of "Client Credentials". Client credentials has been adopted as our new authentication standard and we want to make sure that everyone is receiving the additional security benefits Client Credentials offer.
When
By February 28, 2025
Steps to Migrate to Using Client Credentials
Generating Client Credentials
Make sure you login to Indeavor with the user that will be leveraged within the integration(s). Once you are logged in with the correct user, you will need to navigate to the Roles application. This can be accessed via the Home page, or directly via https://roles.<your environment here>.indeavor.com/credentials
If accessing the roles app via the Home page, make sure you have selected the Client Credentials page via the left side navigation menu.
Within the Client Credentials page, click on the “Create Credential” button at the top of the page.
Give your credential a name. This will be used solely within this page. Only the user that creates the credential will have access to the credentials that have been created. It is important to give each credential their own unique name to distinguish between different credentials that have been generated. It will not be used within the integration or authentication itself.
Once you have created a credential with a unique name, you will then click the Create button.
A client ID and client secret will be produced. It is critical that you copy and paste this client ID and secret to a safe location where your organization has deemed secure. This ID and secret will be leveraged within the authentication step of your integrations.
How to use the Client Credentials once created
When authenticating with Indeavor, user will be making a call to our Identity Service. An Access token will be returned that will be needed in every consecutive API call-- This token is leveraged in exactly the same way as the token users already currently use, so only the authentication call itself needs to change, and no subsequent calls will need to be changed.
The authentication process will require the user to hit Indeavor’s Identity connect call:
POST https://identity.{environment}.indeavor.com/connect/token
For users who have already been using our Identity Service for authentication with Indeavor, the Authorization and Body parameters below will need to be updated. For any users who may have still been leveraging an interop endpoint, the identity endpoint will be new, and all previously used parameters will need to be cleared and replaced with the following parameters.
For use in the authentication call:
If the call is successful, the user should receive the following response:
{
"access_token": "<access token>",
"expires_in": 3600,
"token_type": "Bearer",
"refresh_token": "9C609A055D03B434AB2C0C13A81DE271F31E72F1F9E7F77FFD8D444C3D5C6033-1",
"scope": "algorithms-api callout-api configuration-api constraints-api demands-api displays-api email import-api interop-api
offline_access openid paganini-api profile roles-api rollcall-api settings-api skills-api tasks-api timekeeping-api verdi-api vivaldi-api
workloud-api"
}
The user should take the access token from the response and use it in subsequent calls in their Authorization parameter. While we believe all existing users of our APIs already reuse their access tokens in this way, we recommend double checking that the tokens are being leveraged in subsequent calls properly after beginning to migrating.
Authorization
For use in imports and exports after authorization:
If you have any questions, reach out to support@indeavor.com