Salt Edge developed an API platform - Open Banking Gateway that allows financial institutions to get instant access to customers’ bank accounts in Europe and beyond for account information and payment initiation purposes, via a single API.

Open Banking Gateway includes the following components:

  • Account Information API enables authorized TPPs to access all PSD2 AISP channels, available in the EU and beyond, via one API, to aggregate their customers’ account data.
  • Payment Initiation API helps authorized third parties (including banks) to securely initiate payments via PISP channels.
  • Data Enrichment Platform transforms raw transaction data into actionable insights:
    • Transaction Categorization API for assigning a category to personal and business transactions.
    • Merchant Identification API for determining the exact place where the transaction took place and providing detailed info on the identified merchant.
    • Financial Insights - a report generated based on bank data using complex algorithms, provides institutions with financial behaviour profiles of their potential customers.
  • Salt Edge Partners Account Information API allows institutions to securely connect to PSD2 channels in the EU, without having their own licence and eIDAS certificate.
  • Salt Edge Partners Payment Initiation API aims to make payment providers as simple as a cURL for any company that does not need to get a PSD2 Payment Initiation Service Provider license.

Data types

All of the responses returned by Open Banking Gateway are in the JSON format. The description of the data types encoded in a JSON response is below.


A boolean value true or false


A date in the YYYY-MM-DD format


A date in the ISO-8601 format


A value corresponding to a real number using the double-precision representation


A value corresponding to a 64-bit unsigned integer number


A string representing a JSON object (please refer to the RFC 4627 for more information)


A UTF-8 compatible sequence of characters


A boolean value true or false


A date in the YYYY-MM-DD format


A date in the ISO-8601 format


A value corresponding to a real number using the double-precision representation


A value corresponding to a 64-bit unsigned integer number


A string representing a JSON object (please refer to the RFC 4627 for more information)


A UTF-8 compatible sequence of characters



All sensitive data is encrypted using 2048-bit keys, which allows us to set a secure environment for the client. None of the sent credentials are saved within the system as plain text, and are always encrypted using an asymmetric encryption algorithm. If there is something wrong with the client’s data, WrongRequestFormat error will be returned.

We are continuously monitoring Salt Edge API, securing it from malware attacks, and constantly updating the security layers of our infrastructure. Salt Edge offers you a stable and attack-proof environment where you can keep all your credentials intact, and hidden from a potential attacker.


We recommend you to check the Salt Edge SSL certificate fingerprint on every connection.


For live clients absolutely all requests should be signed. For the clients with other statuses, it is optional:

  • If the signature headers aren’t sent, the request will be performed without any signature validations;
  • If the signature headers are sent, the request signature will be verified.

Before all, the clients who use API key of type service should provide their public key by inserting its content in the keys.

The private key should be securely stored on your server.

In case of possible security breach, the private key should be regenerated and the public key should be updated in your profile.

Signature headers

For a better understanding of how to adapt the corresponding headers in your application, take a look at the sample applications for platforms such as:

The following headers are required for your request to be considered signed:

  • Expires-at - request expiration time as a UNIX timestamp in UTC timezone. We suggest to use +1 minute from the current time. The maximum value is 1 hour from now in UTC, otherwise ExpiresAtInvalid error will be raised;
  • Signature - base64 encoded SHA256 signature of the string represented in the form Expires-at|request_method|original_url|post_body|sha256_of_uploaded_file| - 5 parameters concatenated with a vertical bar |, signed with the client’s private key.

The fields request_method, original_url, post_body and sha256_of_uploaded_file from the Signature header represent:

  • request_method - uppercase method of the HTTP request. Example: GET, POST, PATCH, PUT, DELETE, etc.;
  • original_url - the full requested URL, with all its complementary parameters;
  • post_body - the request post body. Should be left empty if it is a GET request, or the body is empty;
  • sha256_of_uploaded_file - the uploaded file digested through SHA256 algorithm. Should be left empty if it is a GET request, or no file uploaded.

An example of the string that is to be used to generate the signature looks as follows:

  • GET string example: 1413802718|GET||;
  • POST string example (without file): 1413802718|POST||{"data":{"identifier":"my_unique_identifier"}};
  • POST string example (with file): 1413802718|POST||{"data":{"identifier":"my_unique_identifier"}}|6979a174280bdf7319940c59fabbd2b8|.

RSA keys generation instruction

1) Install openssl package

Mac OS X

Install via Homebrew: brew install openssl

Ubuntu Linux

Apt-get install openssl

Mac OS X

Install via Homebrew: brew install openssl

Ubuntu Linux

Apt-get install openssl

2) Create the RSA Key Pair

For Mac OS X and Ubuntu Linux:

  • Type in the command line:

    openssl genrsa -out private.pem 2048
    openssl rsa -pubout -in private.pem -out public.pem

For Windows:

  • After the package has been installed, a folder with name: OpenSSL-Win32 should appear at the install path.

  • Next, open a Command Prompt and change your current directory to this folder by typing:

    cd C:\OpenSSL-Win32\bin, where C:\OpenSSL-Win32 should be replaced with the install path.

  • Then you can generate RSA keys by typing:

    openssl genrsa -out private.pem 2048
    openssl rsa -pubout -in private.pem -out public.pem

then follow the instructions that appear afterwards.

The pseudocode to generate the signature

base64(sha256_signature(private_key, "Expires-at|request_method|original_url|post_body|sha256_of_uploaded_file|"))

Headers example:

Expires-at: 1413466421
Signature: 0o6LgMnlG7FX5tWLoKd6V5jlktodP8I/3vWqh1pOZvPgMn/WPq5YqZWPc0teey135RO2muFThcvuZJtcbaUje1UWFHyWhTh89guHJ47pgBB7w0LMkRw3XskEsafEUZketeTY/NtyeU7ETHHm2Tlw8IJho+gk51Rtp7JJPanw2OZG/6BElFcL0qGs4ohTmJUKKsdI1eo5jseFqF+sX0T4dRYqL7ebhDCD8YsYdsZ9zxlX88+YtUQnEqGbswOH4saGaQNH9NjxST2NS8MFtCU7uwZGybBk4i0l1wtbTJwfgaa+yb2L7l0ltIgxZFJzQOShpVOgI+o8fUg31lOblmMVkpyvXJ/n5Ed2u0nA1yMWkQUPpu03Xkh2RG7qbBOEq6+A374OnhUDwi5TUqYrY89paPwq/A7z2lc56Q84T+NrSLdi0x0aejpp6Cn90Yqpbs04dIio579+KyLm/8XoZ4p9k7vz6vTpDITyTAc93/KHnqeT1hTp7AWMaxuGfEI361fyZLDzkSvnHq4QzMkJOKhPELxSji99dm0LCSZpUiUhTTU3G09LvLBCEFLvbGJzxlO7NgqOGVPMlEc4fJqzU/jrTfkodn4DtzaOJghlXynithKIUBAkpNY9QGPOQIMvcbOZfhilm+bjWuYeNpeALvbqY3ONcibHLjc8ItAVMzORSFg=


For more information about the Expires-at and Signature headers, see Signature page of the guides.

All of the resources queried through the API are protected by 4 different headers, on different levels of security, as shown on the diagram below:

App ID and Secret

The App-id and Secret headers should be passed in with every request. Keep in mind that you can obtain these keys on your API keys page.

Here’s an example request listing all the countries that the API currently supports.

Services and Apps authentication

There are 2 types of access to Open Banking Gateway - as a service or as an app. The type of access is set up by the type of the API key that you are using while accessing the API:

  • service - intended to be used by backends, all the API endpoints are available

  • app - intended to be used by Applications without a backend. Some endpoints for this type of Secret are not available, because mobile applications can be easily compromised/reverse engineered, hence there are security constraints in place to mitigate this

Customer secret

In order to create connect_sessions, connections and oauth providers, your app should pass the Customer-secret header inside the request, so the API can identify which customer the entity belongs to.

Connection secret

Since an app should be able to query information only about the connections it created, requests that query or modify connections should be signed with a Connection-secret header.





Sample Request

curl -v -H "Accept: application/json" \
        -H "Content-type: application/json" \
        -H "App-id: $APP_ID" \
        -H "Secret: $SECRET" \
        -X GET \
curl -v -H "Accept: application/json" \
        -H "Content-type: application/json" \
        -H "App-id: $APP_ID" \
        -H "Secret: $SECRET" \
        -H "Customer-secret: $CUSTOMER_SECRET" \
        -H "Connection-secret: $CONNECTION_SECRET" \
        -X GET \

Rate limits

Open Banking Gateway uses an array of safeguards against bursts of incoming traffic to help maximize its stability. Applications which send many requests in quick succession may see error responses that show up as status code 429.

The table below outlines specific endpoints and their corresponding rate limits:

HTTP MethodURLRequests per second

Response payload

  "error": {
    "class": "RateLimitExceeded",
    "message": "Rate limit of 5 requests/s per IP was exceeded for this endpoint."
  "request": {}


Any incompatible changes to the API will result in incremented versions of the API, which will change the resource URLs.

At some point, the current version will be announced as Deprecated and you will have 12 months to switch your applications to a newer version of the API. All clients will be notified of any deprecation in the API.

New fields can be added to the current API version, at any time without preliminary warning with subsequent documentation added afterward. However, already documented fields cannot be modified or removed. Please rely solely on them.

Client Dashboard

As a client, it is possible to let others access your Open Banking Gateway application. For this, you have to create users, so they, in their turn, can access the information provided by the interface.

If the same email address is used for registering to different applications (Account Information API, Partner Program), then all the applications will be accessed from the same interface by switching between the applications:

In the creation form, you will see a field, describing the roles and their meanings:

Client user roles:

  • Custom - Has custom roles assigned;
  • Finance - Best for accounting people, who can access and handle billing information and payments;
  • Support - Best for employees who regularly respond to end-customers queries related to bank connections;
  • Developer - Best for developers or people using Salt Edge API first hand;
  • Administrator - Best for business owners and company administrators;
  • Owner - Has all the available roles;

Action Roles:

  • Manage customers - delete a customer;
  • Access payments - see the list of Payments in the Dashboard;
  • Manage payments - manage Payments;
  • Access connections - see the connections list;
  • Manage connections - refresh/reconnect/delete a connection;
  • Access accounts - see accounts list and details;
  • Access transactions - see transactions list and details;
  • Access Application/Company info - see client profile data, address;
  • Manage Application/Company info - update client profile data, address;
  • Access Keys & Secrets - see the Keys & Secrets of the application;
  • Manage Keys & Secrets - create, update and delete the Keys & Secrets ;
  • Access callbacks - see client’s callback URLs;
  • Manage callbacks - update client’s callback URLs;
  • Access invoices - see invoices list;
  • Manage invoices - pay an invoice;
  • Access eIDAS Certificates - see eIDAS Certificates;
  • Manage eIDAS Certificates - create, update and delete eIDAS Certificates;
  • Access Open Banking Certificates - view Open Banking Certificates;
  • Manage Open Banking Certificates - create, update and delete Open Banking Certificates;
  • Access teammates - see the team behind your client;
  • Manage teammates - add, edit and delete teammates;
  • Access Customer Reports - see the generated Customer Reports;
  • Manage Customer Reports - generate, download and delete Customer Report;
  • Access Availability (providers) Stats - view Availability Stats (Global Stats and Application’s Stats);
  • Manage Activity Report - download Activity Report for the range of 1 year or up to 1000 records.;

When a client is created, only the account owner can cancel client profile and destroy data.

Your Account

While using Open Banking Gateway, your application can have one of the several statuses, each with its limitations.


Upon registration, your application will have Pending status. You can only access the fake providers (Account Information | Payment Initiation), and use up to 10 fake connections. When you perform an action that is not permitted for pending clients, we respond with a ClientPending error.

When your app is not in Live status, you can also destroy data, which lets you destroy all the customers with their corresponding connections, accounts and transactions.

In order to upgrade the status from Pending, you have to:

We will examine your application and upgrade it to the Test status in two business days.


In order to retrieve live bank account data and initiate payments through Open Banking Gateway, please access the request test access page and fill in all the requirements. When done, press the “Request Test Access” button.

In the Test status, your app can already use live providers, but it’s still limited to 100 connections. Also, the clients that have eIDAS certificates with PISP role can test live providers.

When you are ready to transfer to a limitless usage, use the instructions from the Live section below. Note that all of the data will be preserved, but you can also destroy it if you wish to start with a clean slate.

In order to become Live, the client application should use HTTPS for all API callbacks.


a. In case you have any feedback, please contact us via Help Desk

b. We will need to evaluate the integration of Open Banking Gateway on your side for all the platforms the Salt Edge service will be available on (e.g. web, Android, iOS, etc.). We suggest referring to the Before going Live guide and the Development Requirements and Guidelines. We recommend submitting the implementation for review at least 7 days before the planned production release date.

c. When you are compliant from both legal and technical perspectives you’ll be able to request the Live Access.

d. Review and add any missing teammates (e.g. finance team for invoicing purposes, support team to access the dashboard, etc.).

The Live status allows the application to use Open Banking Gateway without any restrictions.

In Live status, you will not be able to see all of your accounts’ and transactions’ details in your dashboard.


Your application will have the Restricted status if the payment hasn’t been received. While in this status, your application is in a read-only state, hence it cannot create or reconnect connections, refresh them, or create new connect_sessions.


In case of any non-compliance with Terms of Service or Before going LIVE guide, we will contact you to solve the issues. When several attempts to contact the client fail or if any of the non-compliances are not fixed within two days time, the application will be transferred to the Disabled status. In this status, all API requests will return a ClientDisabled error.

Data Volume Limits

Account Information API

Account Information API has been developed to provide real time access to End Users’ financial or other data available from the End User’s Financial Institution. Access to the Account Information API is subject to the following data fetching limits:

  • up to two (2) fetches of new data from any Financial Institution per second (7,200 per hour);
  • limited to one (1) automatic fetch of new data from any Financial Institution per day per End User;
  • manual refreshes are limited by next_refresh_possible_at attribute when fetching new data from any Financial Institution per End User;
  • if there is a failure to fetch or retrieve new data from a Financial Institution, Client is allowed to make up to two (2) additional attempts to retry fetching new data for the associated End User per day. Retried fetches are subject to the same limitations on fetching calls per second set forth in the first paragraph;
  • Salt Edge gives Client the option to enable automatic fetching of new data per each End User’s connection to a Financial Institution. Salt Edge’s standard automatic fetching time starts at 2AM and ends at 6AM in local time of the capital of the country where the Financial Institution is located. In certain cases, the automatic fetching time is from 2AM to 6AM UTC.

Payment Initiation API

Payment Initiation API has been developed to provide the end-customers the possibility to pay from the account of their choice, using their familiar banking authentication methods. Access to the Payment Initiation API is subject to the following data fetching limit:

  • up to two (2) attempts to initiate a Payment Transaction with respect to any Payment Account held by any ASPSP per second (7,200 per hour).

Data Enrichment API

This Section applies to Client if Client is using the Transaction Categorization API separately. The Transaction Categorization API has been developed to provide real time categorization of Transaction Data. Accessing the Transaction Categorization API is subject to the following limits:

  • categorization request to the Transaction Categorization API must not exceed one hundred (100) Objects;
  • up to two (2) requests of categorization of Transaction Data per second (7,200 per hour).

To learn more about Terms of Service using Account Information API, go here.

Guide for Clients Support

on how to handle issues of API integration

Request ID

Each request that is processed by Salt Edge API has an unique request_id assigned to it. Specifying request_id when discussing any issues with Salt Edge Support Team will allow to debug the problem much faster.

It is returned in API in several places:

  1. as header X-Request-Id on every HTTP response:

    $ curl -i --location --request GET '' \
    --header 'App-id: FILTERED' \
    --header 'Secret: FILTERED'
    HTTP/1.1 200 OK
    X-Request-Id: 5dd33824-a713-468c-9371-0f80e1b732a1
  2. as part of any error:

      "error": {
        "class": "ConnectionNotFound",
        "message": "Connection with id: '111111111111111111' was not found.",
        "documentation_url": "",
        "request_id": "313b4518-10d4-4c15-a18e-34ddd583ebdf"
      "request": {
        "connection_id": "111111111111111111"

Nature of errors

Error class: Invalid Credentials

Upon receiving any of the error messages from below of “Invalid Credentials” error class, the users have to double-check the credentials within their Online Banking:

  • Account is not verified.
  • Consent is not valid.
  • Direct Connect is not activated for your account.
  • Invalid Access Number.
  • Invalid Access Number or password.
  • Invalid account number.
  • Invalid agency number.
  • Invalid account, agency or password.
  • Invalid account or agency.
  • Invalid authentication code.
  • Invalid Banking ID and/or password.
  • Invalid captcha.
  • Invalid Card Number.
  • Invalid Card Number or Password.
  • Invalid contact option.
  • Invalid contract number.
  • Invalid CPF.
  • Invalid Customer Number.
  • Invalid Customer Number or Password.
  • Invalid Date.
  • Invalid date format.
  • Invalid email.
  • Invalid credentials format.
  • Invalid ID-card entered.
  • Invalid identification code.
  • Invalid ID or PIN.
  • Invalid login.
  • Invalid login option.
  • Invalid login or keyword.
  • Invalid login or OTP.
  • Invalid login or password.
  • Invalid login, password or token.
  • Invalid membership number.
  • Invalid memorable info.
  • Invalid memorable info or password.
  • Invalid OTP.
  • Invalid password.
  • Invalid password or answer to secret question.
  • Invalid password or sms.
  • Invalid personal code.
  • Invalid phone number.
  • Invalid phone number or password.
  • Invalid PIN.
  • Invalid PIN or PASSWORD.
  • Invalid security code.
  • Invalid security code or password.
  • Invalid security image.
  • Invalid sms.
  • Invalid token.
  • Invalid user code.
  • User code or PIN not correct.
  • Invalid user id.
  • Invalid user id or password.
  • Invalid user id or pin.
  • Invalid username.
  • Invalid username or password.
  • Invalid username or pin.
  • Invalid User-Number.
  • Invalid User-Number or Password.
  • Unable to access your bank account. Please log in to verify your bank credentials.
  • Your PayPal merchant account has been restricted. Contact your PayPal account manager for resolution.
  • Wrong answer to secret question.
  • Wrong answer to secret question or invalid token.
  • Wrong answers to secret questions.
  • "%{field} must contain not more than %{number} characters."
  • "%{field} must contain at least %{number} characters."

Instructions for specific error messages of “Invalid credentials” error class:

Provider asked to perform an action. Please, log in to your web client.

Note: The users must sign in to their Online Banking and check whether they are asked to: update personal data (e-mail, phone number, etc.), give consent (Read and Agree to the Terms and Conditions), close a notification (going paper-free), etc.

Access declined. Please contact your bank’s customer service.

Note: In some cases, the provider blocks the user’s access due to suspicious activity. In this case, the user should contact the provider’s representatives and inform them of the following issue.

Provider asked to activate your Online Banking client. Please, log in to your web client.

Note: Users usually do not activate the Online Banking before establishing a new connection from a TPP. Upon this error, please make sure the user has activated Online Banking first.

The user is blocked. Please contact your bank’s customer service.

Note: The user must contact the provider’s representatives for assistance.

Consent has expired.

Note: The user must perform a reconnect and give consent again.

Provider does not recognize your credentials.

Note: The user must check the credentials within Online Banking.

“%{field} must contain exactly %{number} characters.”

Note: The user must either check the credentials again or change them according to the message (right length and characters).

Invalid login or account blocked.

Note The user’s account has been blocked in order to be accessed from other devices. They must check the credentials again or contact the provider’s representatives for assistance.

Provider asked to update your contact data.

Note: The user must access Online Banking and update personal data (phone number, email, address).

The password is blocked.

Note: The user must change the password within the bank’s interface as it is an action requested by the provider.

Password too short.

Note: The password must be updated.

Login too short.

Note: The login must be updated.

Provider asked to change password.

Note: The password must be updated.

Memorable word login option not activated.

Note: The user must activate the following option within the provider’s interface (specific for GB providers).

“%{field} should contain only numbers.”

Note: The user either must check or change the following field according to the message.

Invalid credentials for OFX providers

The providers which have OFX in their code, are integrated via a new interface Quicken Direct Connect (OFX). In order to connect the account, the user should activate Quicken Direct Connect for the Online Banking (additional fees may be applied) and receive a new pair of credentials, which should be used while authenticating. If all the above works, the user should connect once again from the app using the same credentials.

Error during the Interactive authentication

Invalid Interactive Credentials

Note: The user has failed while performing the interactive authentication, i.e. has not confirmed the access from the mobile application, has entered the wrong One-time password, SMS, Token, etc. Refresh and interactive authentication are expected.

Interactive Adapter Timeout

Note1: The user has failed to perform the interactive authentication in time, i.e. has exceeded the time to confirm the access from the mobile application, has not entered the One-time password, SMS, Token, etc. within the requested timeframe. Refresh and interactive authentication are expected.

Note 2: If the bank has changed any of the interactive options (removed or added any new), then please report this issue to our Customer Care team and we will investigate accordingly.

Wrong option value(s).

Note: the client does not handle the dynamic_select field correctly.

  • In the case of a dynamic_select field, the appropriate callback is sent to your app.
  • This callback from Salt Edge includes interactive_fields_options, which you need to present to the user.
  • Clients should return to us one of the options we sent them.
  • More information about Interactive Callbacks

Error class: Provider Unavailable

Upon receiving the “Provider Unavailable” error, the users must:

  • check whether they can access their Online Banking;
  • make sure that the provider is not having maintenance work.

Specific error messages:

Account blocked. Please, contact your provider.

Note: The user must contact the provider’s representatives for assistance.

Provider does not have any account records available at this time.

Note: The provider is not able to return any information for the user’s accounts at this very moment.

Provider asked to update your account settings.

Note: The user must update the password, login, interactive step, etc.,

User is already logged in or maybe logged out abnormally.

Note: The user shall make sure that the session has ended correctly, and there is no other session running.

Provider could not complete access. Please, try again later.

Note: The provider was not available at the moment the user tried to connect due to various reasons.

Internal provider error, try again later.

Note: The provider is not available for various reasons. The user should try again later.

Provider is having some maintenance work. Please, try again later.
No active accounts were found. Please, contact your provider.

Note: The users must check whether their accounts have been activated or available within the interface.

Provider is disabled.

Note: The provider is not available anymore. Therefore, new connections can not be established neither old ones can be accessed.

Provider’s agency is currently not available.
Session closed, due to another active session. Try again later.

Note: The user has another session running on another device for the following provider. The provider cannot be accessed from two devices simultaneously.

The user session has timed out. Please restart the logon process.

Note: The user must restart the logon process due to inactivity.

To continue working in the ‘Internet bank’ system, you should pay the bill for the use of the system.
Request to provider timed out.

Note: The user took too long to connect to the provider and the session has ended. They must try again.

Too many requests.

Note: The user exceeded the number of requests per day for the following provider. They must refresh/reconnect the next day.

Provider unavailable, try again later.

Note: The users must check whether they can access Online Banking or whether it is under maintenance.

Error class: Provider Error

Any error message under this class shall be submitted via Client Dashboard Help Desk or at

Error class: Server Error

You have already used these credentials to connect with this provider

The user has already created a connection to the same provider and is now trying to add the same accounts, authenticating with the same credentials.

The user should either reconnect the existing connection or delete it and create a new one.

How to report issues

General rules

1. Include all the user reports per provider in one ticket (NOT several ones). The ticket shall be submitted via Client Dashboard Help Desk or at

Note 1: If the provider’s availability is decreasing and the number of reports from users keeps increasing, keep track of the users list on your end and report only one issue. Such issues are generic and once the fixes are applied, they work the same way for all the users.

Note 2: If there are several different issues for the same provider, eg. ProviderError and Wrong balance, then send two reports, one for each issue.

Note 3: If the same user has connected more providers and encounters issues with more than 1 provider, then send separate reports, one for each provider issue.

2. Send the report in a well-read and fixed structure

Subject line: Provider_name: (Generic nature of the issue)

Issue description: Offer as many details as possible so that the development team started working on the issue in due time. Below, please find the recommended structures of the issue per case.

Specific issues

Duplicated transactions

When the transactions duplicate, please specify as many details as possible. Suggestion of how to structure the report:

  • Connection_id
  • Account id to which the duplicates pertain
  • Transaction ids of duplicates / the amounts and dates of the duplicates
Missing account(s)/cards

Suggestion of how to structure the report:

  • Connection_id
  • Account/card nature
  • Account/card name
  • Any useful information that will help us detect and fetch the missing account/card (eg. the location within the bank’s interface)
Missing transactions

Suggestion of how to structure the report:

  • Connection_id
  • Account/card id to which the missing transactions belong
  • Transactions amounts and made_on dates
  • Any useful information that will help us detect and fetch the missing transactions
Wrong balance amount/sign

Suggestion of how to structure the report:

  • Connection_id
  • Account/card id to that has wrong balance/balance sign
  • Specify which amount/sign is the expected one
Wrong transaction made_on date

The user shall make sure the made_on date of the transaction fetched to the financial app coincides with the one from the Online Banking, not Mobile Banking.

Suggestion of how to structure the report:

  • Connection_id
  • Account/card id to which such transactions belong
  • Specify which made_on date is the expected one

Common Issues

Session lost error in Connect

Salt Edge Connect supports being embedded in an iframe. However, it is highly not recommended as it may result in Session lost error.

If a provider is authorizing via a redirect (thus, either has the mode=oauth or mode=api with an interactive redirect), Connect will redirect to the bank’s login page inside an iframe.

However, it may not work because a lot of banks restrict being in an iframe via X-Frame-Options or Content-Security-Policy headers. Such providers have the supported_iframe_embedding=false. In order to check that, please verify the provider’s attributes using show provider route.

  • Thus, providers with supported_iframe_embedding=false should be opened in a separate browser window instead of being opened in an iframe.
  • On the contrary, if a provider has the supported_iframe_embedding as true, it should allow being embedded in an iframe.

Generate token for Fio Banka

Here you will find instructions how to obtain an integration key (token) in Fio Bank’s user environment. This integration lets you read future transactions as well as already posted ones.

During the setup, you can select a date from which the transactions are retrieved.

WARNING : Fio Banka makes available only already recorded transactions, therefore, it takes usually 1-2 days before the transaction appears in the application.

We recommend you to log into online banking using a desktop computer (laptop) - the appearance of the control interface will respond to our instructions and help avoid possible compatibility problems on mobile devices.

  • Log into Online Banking Fio and click on “Settings” in the upper right corner
  • In the settings menu, select the “API” icon
  • Select the account you want to integrate and click on the “Add a new token”
  • Copy the generated token to a text file or clipboard
  • Set the token to “Only monitor the account”, give it a name and specify its validity (after expiration it will be necessary to generate the token again)
  • Click on “Send”.

Generate token for TransferWise

  • Log into your TransferWise account.
  • On the menu on the left click on API tokens.
  • Scroll down and click on API tokens.
  • Click on Add new token.
  • Give your token a name or description and select Read only, click on Create token.
  • To reveal the token click on Reveal Key.


How much time is it expected to fix the interactive providers?

The interactive providers require 2FA authentication for security reasons. Therefore, for interactive (MFA) connections, the Resolution Time may be indefinite as it depends on the end-user’s activity and amount of iterations needed to restore full functionality.

I changed my mobile phone. How do I reset the MFA for my Salt Edge Client Dashboard?

Contact us via Client Dashboard Help Desk or at and let us know about this issue. We will reset your MFA and send you the instructions to follow afterwards.

How to change the status of the client (pending/test/live/restricted)?

Two options are advised:

How to handle Redirects to support App2App?

This happens when the application opens the Connect window in a web view inside the app. When the PSD2 provider finishes authorizing users, it redirects them back to the redirect_url we pass them. It eventually opens in the user’s browser, which does not share cookies with the web view inside the app. This affects apps that use Salt Edge Connect or the Partners API to connect to OAuth providers that support App2App.

A solution for this case would be to open the Salt Edge session in the web browser as opposed to a web view.

These are some guidelines you can rely on for both iOS and Android:

How often shall I sync all my data with Salt Edge?

Salt Edge regularly updates all the data in the system, that is why we recommend synchronizing your data with the data Salt Edge provides you.

Our data is being updated on the following basis:

  • countries - rarely, maximum once per day;
  • currencies - rarely, maximum once per day;
  • currency rates - everyday, at 12:00 UTC;
  • categories - updated only on a new API version release;
  • providers and provider fields - new providers are added frequently, but the providers or their fields are updated rarely (around 10 changes per month, mostly on bank interface update). We recommend updating the providers and their fields once a day.

What is your pricing policy?

Salt Edge takes a personalized approach to each and every client. To get a quote, please contact our Sales team.

How does connection refresh work?

Automatic data refresh works for every connection, except the ones that satisfy any of these conditions:

  • If there was an error introducing your client’s credentials to connection (InvalidCredentials) - in this case the connection will be set as inactive (due to the old credentials being wrong);
  • If less time than shown in provider.refresh_timeout (usually 1 hour) passed between the updates;
  • If the connection’s credentials have not been saved (store_credentials flag is set to false);
  • If the provider.mode field is set to file.

Are the connections automatically refreshed?

Salt Edge regularly updates all the connections that satisfy the following conditions:

  • Connection’s daily_refresh attribute has the true value;
  • The connection’s status is set to active;
  • Connection’s provider_mode is set to any value except file;
  • The automatic_fetch attribute of the last attempt has the true value;
  • The last stage of the attempt has the name of finish.

If these conditions are met, the connection will be updated according to the time specified in refresh start time in the local time of the country the connection belongs to.

I encountered “ActionNotAllowed” error. What should I do?

By default, all Open Banking Gateway clients can use Salt Edge Connect for quick and easy API integration into their app or service. Direct API allows the clients to perform connection actions directly via the API. Access to these routes requires the client to adhere to high security standards, as it involves handling of sensitive customer information. Access to the Direct API routes is subject to manual review and activation and is granted to the ISO 27001 certified parties, registered AISPs and PISPs, as well as selected companies adhering to leading industry security requirements.

Please contact your Salt Edge account manager or sales representative you are in touch with at for further assistance.

Who owns the financial institutions logos appearing in the Open Banking Gateway?

Salt Edge does not own the marks, brands and/or logos of the various financial institutions (banks, e-wallets, payment system providers) that appear in the Open Banking Gateway. We only display them for Salt Edge clients’ convenience and ease of use. Such marks, brands and/or logos are the property of their respective owners and are used for identification purposes only. Their display in the Open Banking Gateway is not sponsored by the respective owners, and does not imply any product or service endorsement by, or affiliation with, Salt Edge. The use of these marks, brands and logos is at Salt Edge clients’ own risk, who are solely responsible for obtaining any applicable permission or authorization from the respective owners. Salt Edge does not make any representation or warranty, express or implied, with respect to such marks, brands and/or logos and expressly disclaims any responsibility or liability arising therefrom.