Skip to main content

Change policy

Learn how we communicate key API changes to you

Proactis together with the Proactis API is constantly evolving to cover additional product functionality. By introducing changes to the API, we aim to enhance your API experience by adding new features and functionality.

Do take note that from time to time, we may introduce breaking changes in order to improve the API. Read on to find out how we communicate changes and what types of changes we introduce.

info

All changes to the Proactis API are announced via our changelog and Proactis release notes.

Types of changes​

Changes to the Proactis API can be divided into breaking and non-breaking changes.

A breaking change is a backward incompatible change that may require updating your integration. A non-breaking change is typically a new addition to the API that can be implemented at your own pace and choosing.

Non-breaking changes​

The following changes are normally considered as non-breaking changes.

  • Adding a new endpoint
  • Adding a new optional parameter
  • Adding an optional request header
  • Adding a new response field
  • Adding a response header
  • Changing the order of response fields
  • Changing an error message
  • Fixing an HTTP response code

Breaking changes​

Breaking changes are changes that are not possible to make backwards-compatible.

  • Removing a resource
  • Removing an endpoint
  • Removing a parameter
  • Removing a response field
  • Modifying an endpoint's URI
  • Modifying the name of a parameter or field
  • Modifying required parameters
  • Adding a required parameter
  • Changing the data type of an existing field or parameter
  • Introducing a new validation

Contents