# Versioning (Must Read) source: https://developer.mastercard.com/mastercard-processing-dispute/documentation/api-basics-section/versioning/index.md As per Mastercard standards, the Mastercard Processing Dispute APIs do not have any versioning in interfaces to ensure backward compatibility and avoid breaking changes. Here is a list of what can be considered breaking and non-breaking changes. | Backwards-compatible (non-breaking) changes | Backwards-incompatible (breaking) changes | |--------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------| | Adding an API interface to an API service | Removing or renaming a service, interface, field, method, or enum value | | Adding a method to an API interface | Changing an HTTP binding | | Adding an HTTP binding to a method | Changing the data type of a field | | Adding a field (optional field or contains default value) to a request message | Changing a resource name format | | Adding a field to a response message | Changing the visible behavior of existing requests | | Adding an output-only resource field | Changing the URL format in the HTTP definition | | Adding a new optional query parameter with a default value (?parameter=value) | Adding a read or write field to a resource message | | Adding an HTTP header field to a request/response message | Modifications (adding or modifying) a value to an enum in a response | | Adding a new error code | Adding a new mandatory field to a request message without setting a field default value | The listed items are not comprehensive. It only indicates what can be considered a breaking or non-breaking change. Alert: You must adhere to these guidelines by writing an application in a way that backward-compatible changes (for example, adding a new field to a response) will not cause errors on your side. Mastercard Processing provides a minimum of 3 months' notice for changes to the APIs.