Changes & versioning

Our goal is to keep the API backwards-compatible for as long as possible. If breaking changes must occur, they are announced here, and all integrators are notified by email in advance.

Backwards-compatible changes

The following changes can happen at any time, without notice. Make sure your integration tolerates them:

• adding new API endpoints;
• adding new optional parameters to existing API requests;
• adding new properties to existing API responses;
• adding new webhook types;
• making existing parameters optional;
• changing the order of properties in existing API responses;
• fixing bugs that made an endpoint unusable (HTTP 500 errors).

📘

Build tolerant clients

Ignore unknown properties when deserialising responses, and do not rely on property order.

Breaking changes

The following changes are considered breaking, or backwards-incompatible, and are always announced in advance:

• renaming or removing an endpoint;
• renaming or removing a parameter of API requests;
• renaming or removing a property of API responses;
• changing the format of a parameter of API responses (e.g. integer to float);
• making validation of a parameter more strict (e.g. making it required);
• returning a different HTTP status code.

Changelog

Announced and past breaking changes are listed in the Changelog.