This page is a summary of all API v2 exclusive features, meaning the features that are available only in API v2, but not in API v1. API v2 contains both technical improvements over API v1, as well as additional functionality. If you want to upgrade from API v1 to v2, see https://documentation.finapi.io/access/api-v2-migration-guide.
Access to a variety of additional banks (API v2 covers all banks of API v1, but not vice versa).
Retrieval of pending (not yet booked) transactions (currently available only for certain banks, but we are constantly extending the bank coverage for this). See:
Additional data for transactions/pending transactions that is not included in API v1 (e.g. the
Possibility to configure the preferred consent type for XS2A communication. See:
Retrieval of the full set of a bank’s existing interfaces, with their AIS availability (account download) and PIS availability (payments/standing orders). See:
(in API v1, currently, unsupported interfaces are implicitly hidden. Also, API v1 contains only a flag for AIS availability, but not for PIS availability).
Automated bank-side consent deletion upon deletion of a user, bank connection, account, or interface (in API v1, this has to be done manually via additional API calls).
Definition of bank-specific payment constraints per bank interface (
BankInterface.paymentConstraints), so that customers can enforce those constraints upon payment creation to avoid payments getting rejected by the bank.
more exclusive functionality coming soon…
All deprecated services and fields from API v1 are gone, so the API is easier to understand and there is no risk of implementing against deprecated functionality.
“null” fields (i.e. fields without any value) are no longer contained in the response body, which reduces the network traffic and improves response times (API v1 returns all fields even when they are “null”)
Date and date-time fields are properly typed according to the OpenAPI standard (“date” and “date-time” types), which allows OpenAPI code generators to translate such fields into the respective types of your chosen programming language, including the correct timezone. (in API v1, such fields are returned as regular “string” types and must be converted into the proper date/date-time objects manually).
Improved authorization security: API v2 requires that authorization-related data is passed in the Authorization header or request body (API v1 allows passing such data as a query parameter, which is not recommended). See:
No more code generation issues with the term “interface”: API v1 used this term for a lot of fields, but since it is a reserved keyword in some programming languages, it caused issues with generated SDKs. API v2 instead uses the term “bankingInterface”.