While we do not impose any limitations or constraints on how you build your integration project we do offer some overarching guidelines we would appreciate you follow to ensure a smooth API Review and transistion to production. These guidelines are designed to ensure the smooth running of our infrastructure for you as well as all our other customers.
Before embarking on your integration we would like to bring to your attention the following key points:
The Actionstep API is a user-centric API. This means all activity performed by an authorizing user is performed under that user's security context and logged in the user's session activity log.
We use exactly the same data security model across the whole of Actionstep. A user of your integration (after authenticating to Actionstep) gains no more or less permissions and visibility to data than they do using Actionstep's web or mobile interfaces.
Please DO NOT use the System Administrator account for API access.
We do not provide any special kind of system account for API access. The Actionstep API is a user-centric API with all API activity logged against the user.
Please do not attempt to share access tokens between users. Each access token includes user-specific information which is validated on each request.
API access is not available to Actionstep Express systems.
The richness of data stored in the Actionstep database means you can treat Actionstep as just another online resource that you can access at anytime merely by executing an API call. What this means essentially is that if you want to link to data held by Actionstep you only need to store a reference to it rather than copying (duplicating) the data to store in your own database. Actionstep is not suitable for data synchronisation projects due to the way we mark data records as having been modified. The use of timestamp fields for data synchronisation cannot be relied upon to indicate data modification has taken place.
As highlighted above the Actionstep API is a user-centric API. However, we recognize there are valid use-cases where data operations are not required on a per-user basis, for example, a background worker process used to synchronize data between two applications. For such a use-case we recommend adding an additional licensed User through which all API traffic can be routed. The advantage of this approach is the data access permissions granted to the API User can be set based on the needs of the consuming application. In addition all API traffic will be logged against the API User in the Session Activity Log and therefore auditable.
Many of our customers pull data from Actionstep to import into a business analytics platform such as Microsoft's Power BI Platform, analyze data in Microsoft Excel, or to produce a business dashboard. If your project is similar in nature we ask you to follow these guidelines:
Only return the data values you require rather than all data values (i.e. use our sparse field sets when making API calls).
Make use of the extensive filtering options available to restrict the size of datasets returned.
For daily bulk data exports please run these overnight in your particular geo region to minimise the impact on our other customers during normal business hours.
Do not perform real-time polling activites, for example, returning all matters every minute.
Does your integration scale with increasing volume of data without any negative performance implications?
Are you making best use of sparse field sets and filtering options to reduce the volume of data retrieved?