We’ve introduced idempotency support for all POST endpoints via the X-Idempotency-Key request header. This helps prevent duplicate processing in case of retries or network issues.
Repeated requests with the same key and identical body will return the original response.
Responses now include an X-Idempotency-Status header (processed or replayed).
A 400 error is returned if a reused key is sent with a different request body.
This makes retrying requests safer and more predictable — especially useful in distributed or unreliable environments. More details can be found at the guides.
This release includes adding an attributes field to the Client model. The attribute field is a key-value map that can store any additional metadata you'd like to link to the client. There are some reserved keys for each service provider.
Here are the client attributes details of creating a client Client Create API
This release includes adding an attributes field to the Account model. The attribute field is a key value field where additional information to be stored regarding the account can be sent. For example, a key-value whose key is account type and value is salary can be sent. Here, account type indicates the key, while salary is a value that holds the type value of this account. The attribute field is a field that can be sent when calling the Create Account API.
Here are the account attributes details of an account Account Create API
This release includes a new Webhook for incoming transfers. Below, you'll find the details about new additions that have been included in this release.
A new type of webhook for Incoming Transfers: incoming-transfer-updated-webhook
If the incoming transfer is updated for any reason after it passes to the completed status, this webhook is sent. In this case, a new field called operationType is added under the webhook. This field indicates the operation for which this update was made. Incoming Transfer Webhooks
This release includes Open Banking EU APIs and changes for Open Banking GB APIs. Details about the modifications are included below.
Open Banking EU: In this context, all Open Banking APIs (GET, LIST, APPROVE, REVOKE, REJECT) have also become accessible to tenants in countries affiliated with the European Union. You can access it using the following links:
Open Banking GB: In this context, the Permission list is added to the consent object for accounts scope in GET and LIST APIs response payload. You can access the example response payload: Open Banking GB GET APIOpen Banking GB LIST API
We are replacing House Accounts by a new concept called Organization accounts. You can access them via backoffice and Platform API. Please refer to new Bank Accounts & Transaction Accounts docs for more details on the account structure. They are created for your specific needs by IF Team while your instance is setup.
Transactions on organization accounts are handled using the existing transaction APIs. Therefore, you'll see an addition of owner field on all transaction models and a couple of minor changes on the models based on the transaction type.
All list transaction APIs have a filter by owner option. Ideally, these APIs should return all data regardless of the value of owner. However, to be able to backward compatible we have to set clientas the default value for now. We expect all of our customers to send clientfilter parameter explicitly as soon as possible. After that, we can drop the default value and all list transaction APIs start to list client & organization transactions by default.
Currently, Confirmation of Payee (CoP) service of Pay.UK is the only supported integration. CoP service can be consumed from one of Clearbank, Modulr, Railsr or Tell Money.
We are excited to announce the recent launch of the Integrated Finance Cards API Card API Guide. Integrated Finance customers now have the opportunity to access a comprehensive suite of card issuing and processing features, seamlessly integrated with core banking and compliance capabilities.
