The Sequence REST API uses a versioning system where each API version is denoted by the release date. For instance, the API version titled 2024-01-01 signifies its release on January 1, 2024.

To use a specific version of the API, include the desired version in the Sequence-Version header of your HTTP request. If the Sequence-Version header is missing, the request defaults to the most recent API version.

As an illustration, to access the 2024-01-01 version, the following HTTP request format is required:

Request
GET https://eu.sequencehq.com/api/customers
Content-Type: application/json
Authorization: Basic a2V5OnNlY3JldA==
Sequence-Version: 2024-01-01

Utilizing an unrecognized API version will result in a 400 Bad Request response, accompanied by an error message detailing the mismatch:

Request
GET https://eu.sequencehq.com/api/customers
Content-Type: application/json
Authorization: Basic a2V5OnNlY3JldA==
Sequence-Version: 2017-01-01
Response
HTTP/1.1 400 Bad Request
Content-type: application/json; charset=utf-8

{
  "error": {
    "type": "UnrecognisedApiVersion",
    "message": "No matching API version found. Please make sure the specified API version is valid."
  }
}

All HTTP responses returned by the API will include the Sequence-Version header, indicating the version of the API that was used to process the request. This header is useful for debugging and troubleshooting purposes.

Response
HTTP/1.1 200 OK
Content-type: application/json; charset=utf-8
Sequence-Version: 2024-01-01

​
Pinning API keys to the current version

When creating new API keys, there is an option to anchor these keys to the current API version. This ensures that the keys will always map to the latest API version at the time the API keys were created, irrespective of subsequent releases. When new API versions are released, the keys will continue to function as intended, without requiring any client modifications until the API version that the keys are pinned to is deprecated.

Without pinning, the keys will default to the version indicated in the Sequence-Version header or to the latest version if no version header was sent with the request.

​
Release schedule

New API versions are released periodically, with the frequency of releases determined by the number of new features, enhancements, and bug fixes. The release schedule is not fixed and can vary based on the complexity of the changes being introduced. New versions are only released when we introduce backward-incompatible changes to the API.

All backward-incompatible changes are documented in the API Changelog, which is updated with each new release of the REST API. We recommend that you review the changelog to understand the backward-incompatible changes introduced in each new version of the API.

Backward-compatible changes include:

  • Adding new API endpoints
  • Adding new, optional query parameters to existing API endpoints
  • Adding new, optional request fields to existing API endpoints
  • Adding new response fields to existing API endpoints

Backward-incompatible changes include:

  • Removing API endpoints
  • Removing query parameters from existing API endpoints
  • Removing response fields from existing API endpoints
  • Changing the data type of existing response fields
  • Changing the format of existing response fields
  • Changing the default value of existing query parameters

​
Deprecation policy

When a new version of the REST API is released, the previous version is deprecated. We recommend that you update your application to use the latest version of the REST API to avoid any breaking changes in the future. Deprecated versions of the REST API are supported for at least 60 days after the release of the new version.

​
API changelog

The API changelog provides a comprehensive list of backward-incompatible changes made to the REST API, including new features, enhancements, and bug fixes. The changelog is updated with each new release of the REST API and is accessible in the API Changelog.

AuthenticationChanges