Introduction

Feedback API

Base URL

Feedback API request URLs take the following base path:

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

Authentication and Authorization

Feedback API uses Applixure Authentication Server (AAS) -issued access tokens - or bearer tokens - to authorize all access to the API.

Before you can call the API, you will need to generate those access tokens by authenticating and authorizing yourself - either as a human or as a machine - if doing machine-to-machine communication - against AAS. Once generated, access tokens can be used to call Feedback API for the duration 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 use a dedicated REST client application or library for accessing Feedback API, a way could already exist to specify the bearer token as an authorization primitive.

However, with tools or libraries which do not directly support bearer tokens but allow supplying raw HTTP header values as part of the GET/POST/DELETE request, you have to set the necessary header manually for HTTP requests.

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

Authorization: Bearer

Please note that all access tokens have a maximum lifetime once they have been issued from the Authentication Server, so you need to refresh them periodically to continue having access. Feedback API will reject all requests with a no longer valid access token.

You can read more about OAuth2 Bearer Authentication here.

Data formats

Queries to the Feedback API return JSON formatted data in the response body, except for select endpoints returning binary (image) assets.

Endpoints requiring data in the submitted body expect 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 for the existing endpoints. Ordering of the fields in the JSON objects should also not be expected to stay fixed.

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

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

In case new versions of the API are introduced, Applixure will not guarantee that any new objects introduced in more recent versions of the API 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 the 2XX -range, typically 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, such as formatting of the payload, returned HTTP response code will be in 4XX and 5XX range.

Additional textual description of the nature or reason of the error may be returned as part of the response body as JSON data in error field:

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

Common HTTP error response codes returned from Feedback API are:

HTTP Error CodeCondition
400 - Bad RequestPayload (or URI parameter) supplied to the endpoint was invalid or missing.
401 - Not AuthorizedAccess token is missing, invalid or expired.
404 - Not FoundSpecific API endpoint path was invalid or requested object was not found.
500 - Internal Server ErrorTemporary error in API - retry after a while is recommended.

If condition persist, please be in contact with Applixure support for further assistance.
503 - Service UnavailableAPI or service is temporarily offline - retry after short while is recommended.

If condition persist, please be in contact with Applixure support for further assistance.

Please refer to individual endpoint's documentation in the references documentation for exact error codes for each endpoint.