We take backwards compatibility seriously, and will make every effort to avoid breaking changes across the platform.
In the unfortunate case where a breaking change can not be avoided, these will be announced well in advance, enabling a transition period for affected integrations.
A breaking change is assumed to be:
- Renaming a parameter (request/response)
- Removing a parameter (request/response)
- Changing a parameter type (request/response)
- Renaming a header (request/response)
- Removing a header (request/response)
- Application of stricter validation rules for request parameters
- Reducing the set of possible enumeration values for a request
- Changing a HTTP response status code
The following are not assumed to be a breaking change and should be considered when integrating with FlipPay:
- Addition of optional new parameters in request
- Addition of new parameters in response
- Addition of new optional headers in request
- Reordering of parameters in response
- Softening of validation rules for request parameters
- Increasing the set of possible enumeration values
In the case of non-breaking changes, a transition period may not be provided, meaning the possibility of such changes occurring must be considered when integrating with FlipPay.