API compatibility and updates
Our API is constantly evolving as we release new features and enhancements.
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.
Updated 6 months ago