Introduction

Workflow API

Base URL

Workflow API request URLs take the following base path:

https://api.workflow.applixure.com/v1/

Authentication and Authorization

Workflow API uses Applixure Authentication Server (AAS) -issued [OAuth2] access tokens - or bearer tokens - to authorize all access to the API.
This means that before you can use the API, you will need to generate those access tokens by way of authenticating and authorizing yourself - either you as a human or you as a machine if doing machine-to-machine communication - against AAS. Once generated, access tokens can then be used to call Workflow API for the period of the token's validity.

Please refer documentation for AAS for more information on authenticating and generating access tokens.

📘

How to use OAuth2 access tokens?

If you are using a dedicated REST client application or library to access the Workflow API, a way to specify a bearer token to use as an authorization primitive could already exist.

If you use tools that do not directly support bearer tokens but allow supplying raw HTTP header values as part of the GET/POST/DELETE request, you must set the necessary header manually for the HTTP request.

With Bearer Authentication, your access token is provided as part of the Authorization HTTP header line in the following format:

Authorization: Bearer

Please be aware that all access tokens have a maximum lifetime once they have been generated from the Authentication Server. It's your responsibility to periodically refresh them to continue having access. Workflow API will reject all requests with an access token that is no longer valid.

You can read more about OAuth2 Bearer Authentication here.

Data formats

Queries to the Workflow API returns JSON formatted data as payload.

Endpoints requiring data in the submitted body expects JSON formatted data.

Backwards and forwards compatibility

From time to time, Applixure may add new fields to the existing objects returned from the API, add new API endpoints or add new optional parameters to the existing endpoints. Also, the ordering of the fields in the JSON objects should not be expected to stay fixed.

As these potential changes can be considered backwards compatible changes, any consumer of the Workflow API is expected to implement parsing accordingly.

We will not make any backwards-incompatible changes to existing APIs, such as removing already-established attributes. However, if such changes are deemed necessary, a new version of the API will be introduced.

If new versions of the API are introduced, Applixure does not guarantee that any new types of objects introduced in those versions will be backported into older - still active - versions of the API.

Error handling

For all normal successful API responses the returned HTTP response code will be in 2XX range, normally 200 (OK) status, with or without additional response body data in JSON format, depending on the endpoint.

In case of a technical error in processing the request or a logical error in the call, the returned HTTP response code will be in 4XX and 5XX range, depending on the error type. Additional textual description of the nature or reason of the error may be returned as part of the response body as JSON in error field:

{
  "error": "Specified account does not exist"
}

Some common HTTP error response codes returned from Workflow API are: