As we continue to provide new features via Radius APIs to our customers, there could be occasions when we have to do a breaking change to roll out something better that may require you to adjust your integration.
This page explains what changes qualify as breaking changes to our Radius APIs. It also gives examples of changes that do not qualify as breaking change.
- Removal of a field
- Change of a field from non-mandatory to mandatory
- Addition of new validation rules
- Modification of the data type of a field
- Change in the URL of the resource
- Change the method used to access a resource
- Change in response codes returned by endpoints
- Removal of a look-up value from an existing look-up value field
When we introduce a breaking change into our Radius APIs, we will support two versions of the API in production, one with and one without the breaking change, for 90 days. Also, we will notify Radius APIs users of these changes and how to correctly reach each version during the breaking changes period.
Examples of NON BREAKING CHANGES
The following types of changes do not qualify as breaking changes. Please note that this list is not exhaustive; these are just some examples of non-breaking changes.
- Addition of a new non-mandatory field (both GET and PUT End points)
- Change of a field from mandatory to non-mandatory
- Addition of look-up values in an existing look-up field
- Deprecation of a field without removing it
- Change in order of fields in an object, objects in an array, and so on
- Change in the order of search results provided by our match end points because of improvements in address matching algorithm.