API Breaking Change Policy


Our APIs are continually changing. The vast majority of changes simply add new functionality. In the normal course of business, we may need to release breaking changes that will require API users to adjust their integrations. When we make a breaking change, we will support two versions of the API in production, one with and one without the breaking change, for a period communicated in a Breaking Change Notification. The Breaking Change Notification will be sent to all registered Customer Service Contacts

Examples of Breaking Changes

The following types of changes qualify as breaking changes:

  • Removal of a field.
  • Change of a field from non-mandatory to mandatory.
  • Change of a field name.
  • Addition of new validation rules.
  • Modification of the data type of a field (for example, converting a single object to a list of objects).
  • Reduction in the number of objects returned by responses.

Examples of Non-Breaking Changes

The following changes are not breaking changes and may be made without notice:

  • Addition of a new non-mandatory field.
  • Addition of a new service.
  • Addition of new reports. 
  • Addition of metrics/dimensions to reports.
  • Deprecation of a field without removing it.
  • Change in order of fields in an object, or objects in an array.


The above policy does not apply to alpha and beta services. Alpha and beta services may be changed at any time, without notice.

We may make breaking changes without notice in order to fix material defects, or to comply with legal obligations.

We may throttle requests or disable access to any of our API services if we determine that a customer’s usage of the service poses a risk to the stability of our platform or maintaining our contracted SLAs. In the case where we manually throttle requests or disable access, we will notify all registered Customer Service Contacts.

Was this article helpful?
0 out of 0 found this helpful