API compatibility and updates

Non-breaking changes

At TrueLayer, we consider the following types of changes non-breaking:

• Adding new resources to the API
• Adding new HTTP request methods to an existing resource
• Adding new fields to an existing response object or webhook
• Adding new variants to discriminated union request types
• Making an existing optional field on a response object required
• Making an existing required field on a request object optional

Furthermore, these types of changes are considered non-breaking, if they don't change the behaviour of existing integrations:

• Adding new optional fields to an existing request object, if the default behaviour remains unchanged
• Adding new variants to discriminated union response types, if they get returned as the result of a new flow or request field, and the previous behaviour remains unchanged

Breaking changes

We try to avoid breaking changes as much as possible. If the necessity for a breaking change arises, we pledge to inform all clients well in advance of the change to provide sufficient time to adjust their implementation.

Compatibility with previous major versions

We do not recommend mixing functionality from different major versions of our API (e.g. Payments API v2 and Payments API v3), as they are not explicitly designed to be interoperable.

Client libraries

Our client SDK libraries are generally kept up-to-date with the latest changes to our API.

While there can be some delay incorporating non-breaking changes, we aim to always release corresponding client library updates alongside breaking API changes.