202603 API Version
This release reflects our continued commitment to regulatory compliance, developer experience, and a more capable verification system.
Authentication
⚠️ JWT authentication removed
JWT token authentication is no longer supported. All API requests must now be authenticated using an API Key. This change aligns with regulatory requirements that mandate each request to be signed on the client side.
Previous API versions continue to support JWT authentication, but we strongly encourage you to migrate to API Key authentication at your earliest convenience.
Account Holder Verifications
Verify by account holder name
It is now possible to verify account holders by name as a fallback mechanism when the destination bank does not support verification by identifier.
Name-based verification is not used by default. It is only triggered when identifier-based verification cannot be completed, ensuring it is used as a last resort rather than a primary method.
To enable this fallback for your account, please contact us. Note that name-based verification may incur additional charges.
⚠️ Simplified and forward-looking payload
The request and response payloads have been redesigned with two goals in mind: making field names more meaningful and consistent, and laying the foundation for supporting additional verification types in the future.
Request
| Before | After | Notes |
|---|---|---|
destination | account | Better reflects what the field represents |
taxid | identifier | taxid is no longer supported. The new identifier field is designed to accommodate multiple identifier types |
recipient | name | Renamed for clarity |
Response
| Before | After | Notes |
|---|---|---|
counterparty | account | Aligned with the request schema |
counterparty.name | name | Moved to root level, consistent with the request |
| – | identifier | Now included in the response, mirroring the request |
| – | verification_attribute | Indicates which field was used to perform the verification |
provider | – | Removed |
error.reason | - | Removed |
Error messages within the error object have also been reviewed and better categorised.
Webhooks
API version derived from API Key
When creating a webhook, the api_version parameter is no longer accepted. The API version is now automatically derived from the API Key used in the request, consistent with how versioning works across the rest of the API.
| Before | After | Notes |
|---|---|---|
api_version | – | Removed |
Reminder about how we version the API
Each version of the API is explicitly linked to an API Key. When a client wishes to start using a newer version, they must generate a new API Key associated with that version. This ensures clear version isolation and allows clients to migrate gradually and safely across versions without affecting their existing integrations. Webhooks are versioned the same way. A webhook is always tied to the API version of the API Key used to create it, which means you can run a fully functional parallel setup — new API version, new webhooks — before committing to the switch. Migrating to a new version without service disruption
Generate a new API Key for the target version. Update your integration to use the new API Key and adapt to any payload or behavioural changes introduced in the new version. Create your webhooks using the new API Key — they will automatically be associated with the new version. Run both versions in parallel and validate that everything works as expected. Once you are confident, stop using the old API Key and decommission the associated webhooks.
Note: You can have API Keys for more than one version active at the same time. This allows you to keep your existing integration running while testing or migrating to a newer version — with no disruption to your current workflows.