API Credentials

Before you can begin building your integration you will need a set of API Credentials for the sandbox environment. A set of API Credentials comprise of a Client ID and a Client Secret. You will need both of these to authenticate to our infrastructure before calling individual API endpoints. Our Global Support Team will manage the issuance of API Credentials for both the sandbox and production environments. An example set of API Credentials is shown below.

Client ID: XYGVCSBS8GKEKA7DM6F8VHMNUHILICAXFSXRX4M5C4XNFBVSIIA
Client Secret: EQA1U2NWRMIAIHADC1VUKDAKZOHFHRTK0GHTRXZITEBSG9D0KJG

Please Note: API Credentials are specific to the environment for which they are issued. API Credentials issued for the sandbox cannot be used in production and vice-versa. Once your integration has been approved by the API Review Process, we will issue you with a new set of API Credentials for our Production environment.

Scope of API Credentials

API Credentials are issued on a per application/integration basis. This means if you have developed multiple (unique) integrations each one will require its own set of API credentials and undertake an API Review. This enables our Global Support Team to monitor API usage and identify an individual integration should an issue be detected.

Once your integration has been approved and you have received a set of production API credentials you can market your integration to the entire Actionstep client base. You do not need any additional API credentials for each Actionstep client you sign up to your integration. It is the unique combination of your API Client ID and Client Secret, plus the Actionstep user's login credentials that uniquely identify a user of your integration to Actionstep.

Data Sovereignty Compliance and Regulations

If you are building a global integration please ensure you follow all relevant data sovereignty rules and regulations for the jurisdictions in which you operate, e.g. GDPR for the UK. Your integration must not transfer personally identifiable information from one jurisdiction to another if local data sovereignty rules and regulations expressly prohibit this. Please ensure your integration is fully compliant with any applicable data sovereignty rules and regulations.