Data types

All of the responses returned by Salt Edge API are in the JSON format. The description of the data types encoded in a JSON response is below.

true or false

a boolean value


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

true or false

a boolean value


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, they will be notified with a specific message.

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.

HTTP Public Key Pinning (HPKP)

Salt Edge returns a Public-Key-Pins header in all of its responses. Modern browsers like Chrome and Firefox already use it to validate the public key of Salt Edge certificate. Additionally, you can use this header to validate the certificate on your backends during API consumption. For more information see

Bug Bounty Program

Salt Edge truly believes that collaborating closely with experienced security researchers from across the globe is an essential part of identifying and mitigating security vulnerabilities in Salt Edge infrastructure. Therefore, Salt Edge is happy to reward the researchers that have identified original and previously unreported vulnerabilities.

If you believe to have found a security vulnerability, we encourage you to visit our Bug Bounty Program.


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, service clients should provide their public key by inserting its content in keys and secrets page.

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


Windows complete package .exe installer

Ubuntu Linux

apt-get install openssl

Mac OS X

Install via Homebrew: brew install openssl


Windows complete package .exe installer

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 diagramm below:

Headers diagramm v5

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 2 types of access to Salt Edge API - 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 the 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 \


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.

Clients Dashboard

As a client, it’s possible to let others access your Salt Edge API dashboard. For this, you first have to create those users, so they, in their turn, can access the information provided by the interface.

In the creation form, you will see a field, describing user’s roles. The roles and their meanings are as follows:

  • Access connections(logins) - see the connections(logins) list;
  • Manage connections(logins) - refresh/reconnect/delete a connection(login);
  • Access customers - see customers list;
  • Manage customers - delete a customer;
  • Access invoices - see invoices list;
  • Manage invoices - pay an invoice;
  • Access company info - see client profile data, address;
  • Manage company info - update client profile data, address;
  • Access secret data - see client secrets, public key;
  • Manage secret data - generate new client secrets, update public key, destroy all data (being test|pending);
  • Access callbacks - see client’s callback URLs;
  • Manage callbacks - update client’s callback URLs;
  • Access teammates - see the team behind your client;
  • Manage teammates - add, edit and delete teammates;
  • Access providers stats - see each provider’s availability and last error;
  • Access accounts - see accounts list and details;
  • Access transactions - see transactions list and details;
  • Access all tickets - see and interact with support tickets created by all teammates (otherwise, only personal tickets can be accessed);
  • Access payments - see the list of Payments in the Dashboard;
  • Manage payments - manage Payments;
  • Generate reports - generate and download Activity Reports.

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

Client Provider Keys

Account Information Services Support

Salt Edge now supports Account Information Services channels, which can be used with PSD2 and Open Banking compliant APIs. The connection to such a provider is possible only if you create a Provider Key (set of credentials) for it. In this case, the API keys for Providers are provided and controlled by you. The number of keys is restricted to 1 per provider. After you create the key, the provider will be accessible as an usual provider.

Salt Edge now supports eIDAS Certificates. Learn more.


To integrate your App’s individual keys with a Financial Provider (ASPSP in PSD2 terms), follow these steps:

  • Visit Provider Keys page of your Client Dashboard, select a provider you want add your client keys for, read the instructions and complete the form. You can see all the available providers by going to the New tab on the same page;

  • Proceed by visiting the Connect page and search the provider you just created the key for. It will have a small subscript below the provider name stating that this provider is accessed via YOUR_CLIENT_NAME;

  • The rest of the process is exactly the same as with usual providers.

API Connect - Salt Edge Connect

In case of using API Connect instead of Salt Edge Connect, it should be ensured that the code handles the new provider’s field nature - dynamic_select, with its options dynamically generated and sent in an Interactive callback.


For the purpose of testing individual keys Salt Edge has developed the following list of Fake providers:

  • fake_client_xf - requires a username and password (embedded);

Sample key:

client_id: "fake_client_id",
client_secret: "fake_client_secret"
  • fake_oauth_client_xf - asks for authorization (OAuth redirect);

Sample key:

client_id: "fake_client_id",
client_secret: "fake_client_secret"
  • fake_interactive_client_xf - asks for a fake SMS code in addition to username and password (embedded).

Sample key:

client_id: "fake_client_id",
client_secret: "fake_client_secret"

To see these providers in API or Salt Edge Connect, don’t forget to set include_fake_providers parameter as true on connection(login) create/reconnect or connect session create/reconnect.
All of the providers that are supported in this mode have _client_ in their provider code.
In case your Provider isn’t supported by our API, please fill this form and we’ll integrate it in due time.

eIDAS Certificates

Salt Edge API supports only soft issued eIDAS certificates.

For the purpose of identification, ASPSPs(Account Servicing Payment Service Providers) and TPPs(Third Party Providers) shall rely on using eIDAS (electronic Identification, Authentication and trust Services) Certificates for electronic seal and/or for website authentication. Identifying themselves is mandatory for all TPPs that wish to get access to ASPSP’s sandbox, live API, and/or to non-dedicated channel.

eIDAS Certificates are provided by Qualified Trust Service Providers (QTSPs) who are responsible for assuring the electronic identification of signatories and services by using strong mechanisms for authentication, digital certificates, and electronic signatures.

There are two types of eIDAS Certificates:

  • Qualified Website Authentication Certificates (QWAC) - identification at the transport layer. QWAC is similar to SSL/TLS with Extended Validation used in Internet for the same purpose. It is used for website authentication, so that ASPSPs and Third Party Providers (TPPs) can be certain of each other’s identity, securing the transport layer. TPP should present its QWAC client certificate towards an ASPSP. The ASPSP can choose between using the ASPSP QWAC server certificate or just an existing SSL/TLS certificate to receive the TPP’s identification request.

  • Qualified Certificate for Electronic Seals (QSEAL) - identification at the application layer. It is used for identity verification, so that transaction information is protected from potential attacks during or after a communication. This means that the person receiving digitally signed data can be sure who signed the data and that it hasn’t been changed.

To create eIDAS certificate in Salt Edge system, you should accomplish the following steps:

  1. Go to client dashboard.

  2. In client dashboard go to Account > eIDAS Certifcates

  3. Choose certificate type you want to create (QWAC or QSEAL) and press Generate CSR.

  4. Fill the form and click generate. Download generated CSR. (Private key that will be generated on this step is kept securely, so no one has access to it).

  5. Send CSR to QTSP (you can get test certificate, or buy production certificate)

  6. Get certificate from QTSP

  7. Go to Account > eIDAS Certifcates and press edit on previously created record.

  8. Insert received certificate in PEM format into form and press update.

  9. Choose certificate that you want to use for identification, press edit and mark it as active.

Your Account

While using Salt Edge API, your application can have one of the several statuses, each with its limitations.


Upon registration, your application has the Pending status. You can only access the fake providers (Account Information | Payment Initiation), and use up to 10 fake connections(logins). 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(logins), 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 real bank account data through Salt Edge API, please access the request test access page and fill in the form. When done, press the “Request Test Access” button.

In the Test status, your app can already use real providers, but it’s still limited to 100 connections(logins).

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. Test the API integration to ensure that everything works properly with both fake and real providers. Contact us at any time with the feedback.

b. Get in touch with our sales team to sign the NDA and Service Agreement.

c. We will need to evaluate the integration of Salt Edge API 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.

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

e. 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 Salt Edge API 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(logins), 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.

Salt Edge API Access Terms

Data Volume Fetching Limits

Salt Edge API was developed to provide real time access to End Users’ financial or other data available from the End User’s Financial Institution. Access to the Salt Edge 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) fetch of new data from any Financial Institution per day 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.

Data Volume Limits

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

  • categorization request to the Saltedge 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 Salt Edge API, go here.

Mobile SDKs

Salt Edge supplies a set of SDKs that can be used to build mobile and desktop apps. Right now we have the following libraries:

Note that this guide uses Salt Edge Connect as the interface for the users to connect to their bank accounts. If you’d like to use the REST API to connect, you can consult the full Reference or the documentation of the corresponding SDK.

1. Sign up for Salt Edge

Go to the Sign up page and sign up for a Salt Edge account. You will need to give your app a name, provide us with an email and a password you will use to authenticate to the admin page.

2. Follow the instructions supplied with the SDK

Each of the SDKs provides a description of how to set up the SDK, integrate it, and start fetching the customer data. Please refer to the corresponding README files.

The SDK also provides a sample app and the instructions as how to run the app.

Guide for Clients Support

on how to handle issues of API integration

Nature of errors

Error class: Invalid Credentials

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

  • 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 contract number or password.
  • 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 member number or password.
  • 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 registration number.
  • Invalid password or sms.
  • Invalid personal code.
  • Invalid phone number.
  • Invalid phone number or password.
  • Invalid PIN.
  • Invalid PIN or PASSWORD.
  • Invalid PIN or TOKEN.
  • 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.
  • Wrong answer to secret question.
  • Wrong answer to secret question or invalid token.
  • Wrong answers to secret questions.
  • "%{field} must contain no 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 user must sign in to his Online Banking and check whether he is asked to: update his personal data (e-mail, phone number, etc.), give his 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 his 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.

You cannot access the application.

Note: The user should confirm the interactivity, usually from another app (banking app).

Consent has expired.

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

Provider does not recognize your credentials.

Note: The user must check his credentials within online banking.

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

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

Invalid login or account blocked.

Note The user must check his credentials again or contact the provider’s representatives as his account has been blocked to be accessed on other devices.

Provider asked to update your contact data.

Note: The user must access his online banking and update his personal data (phone number, email, address).

The password is blocked.

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

PIN too short.

Note: PIN must be either be checked or updated.

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. He/she should retry refreshing and performing the interactive authentication as 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. He/she should retry refreshing and performing the interactive authentication as 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.

Error class: Provider Unavailable

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

  • check whether he can access his 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 his password, login, interactive step, etc.,

User is already logged in or maybe logged out abnormally.

Note: The user must make sure he either ended the session correctly, or whether he still has a 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 user must check whether their accounts have been activated or available within the interface.

To continue working in the ‘Internet bank’ system, you should pay the bill for the use of the system.

Note: The user must pay the internet banking bill to the provider before he continues accessing his data.

Provider is disabled.

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

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 his logon process due to inactivity.

Request to provider timed out.

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

Too many requests.

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

Provider unavailable, try again later.

Note: The user must check whether he can access online banking or whether it is under maintenance.

Error class: Provider Error

Any error message under this class shall be submitted 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 now he is 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).

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/Login 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/Login 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/Login 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/Login 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/Login id
  • Account/card id to which such transactions belong
  • Specify which made_on date is the expected one


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 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 OAuth providers that support App2App?

This happens when the application opens the connect window in a web view inside the app. When the PSD2 provider finishes authorizing the user, they redirect 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(login) refresh work?

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

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

Are the connections(logins) automatically refreshed?

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

  • Connection’s(login’s) daily_refresh attribute has the true value;
  • The connection’s(login’s) status is set to active;
  • Connection’s(login’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(login) will be updated according to the time specified in refresh start time in the local time of the country the connection(login) belongs to.

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

By default, all Salt Edge API clients can use Salt Edge Connect for quick and easy API integration into their app or service. API Connect allows the clients to perform connection(login) 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 API Connect 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 Salt Edge API?

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 Salt Edge API. 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 Salt Edge API 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.