Authorization API

Identity Service 


API Description

Our Identity APIs use the OAuth 2.0 protocol for authentication and authorization.

Our documentation covers the Authorization API jointly for different user flows. In order to implement Authorization API correctly, you should also check the RFCs connected to the Authorization API, mainly:

To begin, obtain OAuth 2.0 client credentials from the Developer Portal. Then your client application requests an access token from the bank Authorization Server, extracts a token from the response, and sends the token to the banking API that you want to access.

Identity API supports Client credentials grand flow with scope IDENTITY


Basic steps

All applications follow a basic pattern when accessing a banking API using OAuth 2.0. At a high level, you follow four steps:

Step 1. Obtain credentials

Register your application on the Developer Portal to obtain OAuth 2.0 credentials such as a client ID and client secret that are known to both the bank and your application. To register your application visit Applications page from your dashboard and click to button Add Application. Provide application information and select APIs that will be accessed by your application. After saving the application settings OAuth 2.0 client credentials are generated and you can access them in the Auth section of your application.

Step 2. Obtain an access token

Before your application can access private data using a banking API, it must obtain an access token that grants access to the API. A variable parameter called scope controls the set of resources and operations that access token permits. For Identity use  IDENTITY value as a scope.




Content-Type: application/x-www-form-urlencoded

Accept: */*

Cache-Control: no-cache


Accept-Encoding: gzip, deflate, br

Connection: keep-alive

Content-Length: 139 










Step 3. Send the access token to the API

After the application obtains an access token, it sends the token to a bank API in an HTTP authorization header. It is possible to send tokens as URI query-string parameters, but we do not recommend it, because URI parameters can end up in log files that are not completely secure. Also, it is good REST practice to avoid creating unnecessary URI parameter names.