Breaking Change policy

Document version: V1.0

Breaking change

A breaking change is a change that may require our partners to make changes to their application(s) in order to avoid disruption to their integration.

The following are a few examples of changes XUND considers breaking:

• Changes to existing permission definitions

• Removing or renaming the URL of an endpoint

• Removal of an allowed parameter, request field or response field

• Addition of a required parameter or request field without default values

• Changes to the intended functionality of an endpoint

• Renaming or changing the type of a field in the response of a published endpoint

• Adding a new or changing an existing validation to an existing resource

Non-breaking change

A non-breaking change is a change that partners' applications can adapt to at their own discretion and pace without disruption.

Despite XUND is aimed to communicate all kind of changes before they are made, we might communicate non-breaking changes after they are already made.

Ensure that your client application is designed to be able to handle the following types of non-breaking changes without prior notice from XUND:

• Addition of new endpoints

• Addition of new methods to existing endpoints

• Addition of new fields in the following scenarios:

  • New fields in responses

  • New optional request fields or parameters

  • New required request fields that have default values

• Addition of a new value returned for an existing text field

• Changes to the order of fields returned within a response

• Changes to the length of data returned within a field

• Changes to the overall response size

• Changes to error messages and error codes

• Fixes to HTTP response codes and error codes from incorrect code to correct code