Wise Platform APIs evolve over time as we add features and expand coverage. This guide explains how Wise Platform versions its APIs, what types of changes you can expect within a version, and how to choose which version to use.
This versioning policy does not currently apply to webhooks or sensitive card details endpoints. We will update this policy once these endpoints have been migrated to this versioning scheme.
Wise Platform uses global, calendar-based versioning (CalVer). Versions are shared across the API (rather than versioning each endpoint independently) and released on a quarterly basis.
Versions are named by year and quarter, for example:
2026Q32026Q4
Wise Platform versioning is URL-based, meaning you select a version by including it in the endpoint request path.
Example: /2026Q3/auth/jose/response/public-keys
Wise Platform makes the Latest and Active versions of the API available for production and publishes documentation for these versions in the API reference.
| Version type | Description |
|---|---|
Latest | The generally available (GA) version that is recommended for production.
|
| Active | Prior released versions with continuous support until they are sunset (see Deprecation and sunset policy for details). |
Wise Platform versions are released quarterly.
Each quarter, the Latest version updates to the the next version in the sequence. For example, on 1 October 2026 the Latest version will move from 2026Q3 to 2026Q4. This new Latest version will include any major and breaking changes added to the API, which will be documented in the changelog along with any necesary migration guidance.
The 2026Q3 version remains an active, supported version.
Wise classifies changes as either breaking or non-breaking.
A breaking change is any change that requires you to modify your integration to keep it working as originally intended.
Examples include:
- Removing or renaming a field.
- Changing a field’s type or meaning.
- Introducing new required parameters.
- Removing or fundamentally changing an endpoint.
- Behavioural changes that alter expected outcomes for the same request.
Breaking changes require updating your request URLs to that version and are only introduced when the Latest version is updated at the start of each quarter.
Wise may introduce additive, backward-compatible changes within the Latest version at any time. These changes will not increment the API version number.
Examples include:
- Adding new fields to responses.
- Adding new optional request parameters.
- Adding new endpoints/resources.
Design to be resilient to additive changes so that newly-added fields do not break parsing or validation.
Wise supports each active version until such time as we determine it needs to be deprecated.
At this time, there is no set time frame for how long a version will remain active. However, we have no plans right now to sunset any currently supported versions.
To avoid disruption to your integration, any plans to sunset versions will be communicated well in advance.
Ahead of sunsetting a version, Wise will provide notice at least 6 months in advance via:
- Email to partner contacts.
- The developer changelog.
Wise Platform is continuously evolving as we offer new features and coverage to our API customers.
It's important to us that our partner integrations are not adversely affected by changes and we endeavor to uphold these standards as part of our company's mission of transparency. We are regularly reviewing our policies to make sure we're delivering the best possible developer experience.