API Versioning

The API version name is based on the date when the API version was released. For example, the API version 2026-02 was released in February 2026.

Breaking changes

We define breaking changes as any change that could potentially break an integration. We will provide advance notice before releasing breaking changes. Breaking changes include:

Removing an entire operation

Removing or renaming a parameter

Removing or renaming a response field

Adding a new required parameter

Making a previously optional parameter required

Changing the type of a parameter or response field

Removing enum values

Adding a new validation rule to an existing parameter

Changing authentication or authorization requirements

Any additive (non-breaking) changes will be available in all supported API versions. Additive changes are changes that should not break an integration. Additive changes include:

Adding an operation

Adding an optional parameter

Adding an optional request header

Adding a response field

Adding a response header

Adding enum values

To ensure a minimum of breaking changes after introducing a new endpoint, a new endpoint will go through each of the states developing, testing, and released as part of a phased roll-out. API changes won't be deemed breaking until after the endpoint has reached the released state.

Specifying an API version

The API version must be specified whenever you make a request to the API. The version is set via the X-API-Version HTTP header, i.e.

A status code of 400 is returned along with a descriptive error if the header is not included in the request. Likewise, if the specified API version doesn't exist or is no longer available.

Breaking changes#

Specifying an API version#

Breaking changes

Specifying an API version