Versioning and changes
What can change under you, and what cannot.
The API is versioned in the path. This documentation describes v1.
Changes we may make without notice#
These are additive and safe for a well-built integration:
- Adding a new endpoint.
- Adding a new optional request field.
- Adding a new field to a response object.
- Adding a new value to a list that is already open-ended, such as a new payment method code.
Build tolerantly. Ignore response fields you do not recognise rather than failing on them, and never assume the full set of method codes is fixed. An integration written this way is unaffected by everything in the list above.
Changes we treat as breaking#
- Removing or renaming a field.
- Changing the type or meaning of an existing field.
- Removing an endpoint or a status value.
- Making an optional field required.
Breaking changes ship as a new version path. v1 continues to work while it is supported.
Notice and deprecation#
A breaking change ships as a new version path. When a version is superseded, we give at least 90 days' notice before it is deprecated, and continue to support the superseded version for at least 12 months from that notice, unless a security or regulatory obligation requires a shorter window. Notice periods and the support window are also stated in your commercial agreement, which prevails.
Following changes#
Every change to this documentation is recorded in the changelog, with the date and the version it applies to.
Maly Tech Ltd. This guide is provided for information. Where it differs from your signed agreement, the agreement applies.