Quick start guide

Prerequisites

Before you start, you need:

• A PSD2 licence — you must be authorised as an AISP and/or PISP by your national competent authority.
• eIDAS certificates — a QWAC for transport (mutual TLS) and a QSealC for request signing (detached JWS). Both are required.

There is no sign-up step. Registration is implicit: every API call is validated against your eIDAS certificate and licence, and any licensed TPP has access by default. Your first request registers you automatically.

The sandbox accepts both test and production certificates. To explore it, use the Postman collection on the Test credentials page.

If a request fails while your certificate is valid, email compliance@saltedge.com with the request log (include the X-Request-ID) and we will assist as soon as possible.

Environments

Each environment is selected by the provider code in the URL path — use test_bank for sandbox testing:

Every endpoint path appends to the base URL:

{base_url}/v2/{resource}

# Example: list accounts in the sandbox
GET https://openfinance.saltedge.com/test_bank/api/v2/accounts

The sandbox exposes the same endpoints and flows as production, including SCA.

Your first request

The walkthrough below takes you from nothing to reading account data in the sandbox: create a consent, let the customer authorise it, then call the API. Every request is signed — the Postman collection on the Test credentials page computes the Digest and x-jws-signature headers for you.

1. Create a consent

A consent describes what data the customer allows you to access. The example below requests a global consent: access to all payment accounts with account information and owner name rights.

POST /test_bank/api/v2/consents/account-access
Host: openfinance.saltedge.com
Content-Type: application/json
X-Request-ID: 99391c7e-ad88-49ec-a2ad-99ddcb1f7721
Digest: SHA-256=<digest>
x-jws-signature: <detached JWS>
PSU-IP-Address: 192.168.8.78
Client-Redirect-URI: https://your-app.example/callback

{
  "access": {
    "payments": [
      { "rights": ["ais", "ownerName"] }
    ]
  },
  "consentType": "global",
  "recurringIndicator": true,
  "validTo": "2026-12-31",
  "frequencyPerDay": 4
}

The response contains the consent identifier and the authorisation link:

HTTP/1.1 201 Created

{
  "consentStatus": "received",
  "consentId": "8f19b3a2-4c1d-4e5a-9b0e-6f2d7a913c48",
  "_links": {
    "scaRedirect": {
      "href": "https://openfinance.saltedge.com/test_bank/sca/8f19b3a2"
    },
    "status": {
      "href": "/test_bank/api/v2/consents/account-access/8f19b3a2-4c1d-4e5a-9b0e-6f2d7a913c48/status"
    }
  }
}

2. Send the customer to authorise

Redirect the customer to _links.scaRedirect.href. They authenticate with the bank and approve the consent. In the sandbox, log in with the credentials from the Test credentials page. After authorisation the customer returns to your Client-Redirect-URI.

3. Check the consent status

The consent starts as received and becomes valid once the customer approves it (or rejected if they decline).

GET /test_bank/api/v2/consents/account-access/{consentId}/status
Host: openfinance.saltedge.com
X-Request-ID: 273b2fbd-3e46-4bf4-a4b4-2c54ee1af372
Digest: SHA-256=<digest>
x-jws-signature: <detached JWS>
PSU-IP-Address: 192.168.8.78

HTTP/1.1 200 OK

{ "consentStatus": "valid" }

4. Call the API

With a valid consent, pass its identifier in the Consent-ID header and read the account data.

GET /test_bank/api/v2/accounts
Host: openfinance.saltedge.com
X-Request-ID: 41cbb041-4fbe-4f42-9e4f-9d76e2a5c1f0
Digest: SHA-256=<digest>
x-jws-signature: <detached JWS>
PSU-IP-Address: 192.168.8.78
Consent-ID: 8f19b3a2-4c1d-4e5a-9b0e-6f2d7a913c48

HTTP/1.1 200 OK

{
  "accounts": [
    {
      "resourceId": "3dc3d5b3-7023-4848-9853-f5400a64e80f",
      "iban": "LT121000011101001000",
      "currency": "EUR",
      "name": "Main account",
      "product": "Current account",
      "_links": {
        "balances": {
          "href": "/test_bank/api/v2/accounts/3dc3d5b3-7023-4848-9853-f5400a64e80f/balances"
        }
      }
    }
  ]
}

That is the full integration loop. The same consent authorises balances and transactions; payment initiation follows the same create → authorise → status pattern. Request and response schemas for every endpoint are in the API reference in the sidebar.

Required headers

Three headers accompany every request:

• X-Request-ID — unique UUID per request, used for correlation and support
• Digest — SHA-256 hash of the request body
• x-jws-signature — detached JWS over the request, signed with your QSealC

Depending on the call, additional headers apply:

• PSU-IP-Address — IP address of the customer’s device; required on customer-initiated calls
• Client-Redirect-URI — return URL after authorisation; required when creating consents and payments
• Consent-ID — identifier of a valid consent; required on account and funds-confirmation calls
• Content-Type: application/json — on requests with a body

The exact header set for each endpoint is listed in the API reference. The Digest and x-jws-signature values are computed per request: hash the body, then sign the request with your QSealC private key as a detached JWS. The Postman collection generates both automatically.

Explore next