Corporate access authorization API - details

The Corporate Access Authorization API is available for all Clients and enables you to negotiate access to account information and services with Nordea’s corporate customers. During this process the Client submits firstly an access request and subsequently requests for the customer to authorize the access using Nordea issued security credentials. At the end of the process the Client obtains an Access Token which must be used in all subsequent account information or payment initiation service requests.

Nordea corporate customers authenticate using their Corporate Netbank logon credentials and Nordea’s Nordea ID application. This authentication service meets the 2-factor authentication (2FA) requirements of the Payment Services Directive (PSD2) and provides a mechanism where all Clients can secure access authorization to the customer’s account information and payment initiation services.

Changes from the previous version

This is the change log of Corporate Access Authorization API. The topmost item is the latest version and the changes described in it are relative to the previous version which is listed directly below. The current version of the API documentation is 2.8. It is related to Corporate Access Authorization API version 2.   

Version 2.8 

Nordea ID authentication method in offline mode (MTA_OFF) that has been available in the redirect authorization flow has been finally decommissioned.

Version 2.7    

There are two changes implemented lately to the Corporate Access Authorization API:

• Nordea ID authentication method in offline mode (MTA_OFF) that has been available in the redirect authorization flow will be decommissioned in May 2024.

• The agreement number parameter provided when making initial access authorization requests in both redirect and decoupled flow in the Corporate Access Authorization API has been changed from a mandatory to an optional.  

Version 2.6

Consent maximum duration changed to 180 days.

Version 2.5  

Redirect Access Authorization flow updated and Nordea Codes app rebranded to Nordea ID. Terminology aligned across our documentation.

Version 2.4

Introduction of a new endpoint, enabling the revocation of access (or refreshing) token, for example when access authorization has been withdrawn by the customer.

• Revoke token:/corporate/v2/authorize/token/revoke

Version 2.3

Redirect Access Authorization flow introduced for BankID verification in Sweden and Nordea Codes app for all countries, which is accessible using the existing endpoints.

Version 2.2

Version 2.1

Note: The Corporate API Products have mandated a new field for inclusion in the body of Access Authorization requests. Consumers of the Corporate Access Authorization API will need to update their applications to provide the customer’s Corporate Netbank agreement number when making initial access authorization requests. Please see new swagger file definitions here and new postman collection for your use.

Additional mandatory “agreement_number” parameter is added within the body of the POST /corporate/v2/authorize request
One additional access scope “PAYMENTS_BROADBAND” is made available in the POST /corporate/v2/authorize request

Version 2.0

From v2.0 we will now support registered TPP Clients. To fetch account information as a registered TPP, new “ACCOUNTS_PSD2” scope is introduced which can be used with the following endpoint: POST /corporate/v2/authorize

The new version v2 of the API has a mandatory Signature header. All consumers will be required to use certificates (eIDAS or self-signed) for the API after September 14, 2019. We will depreciate the earlier v1 API versions.

The following signature headers are required for all GET requests: “(request-target) x-nordea-originating-host x-nordea-originating-date”.
The following signature headers for all POST or PUT requesta: “(request-target) x-nordea-originating-host x-nordea-originating-date content-type digest”.

Version 1.0

This is the first official version of the Corporate Access Authorization API. Compared to the initial version, the following changes were introduced:
Support for Refresh Token was introduced in the following endpoints: POST /corporate/v1/authorize/token.

Initial Version

Corporate access authorization process implemented Corporate authorize endpoints implemented

How it works

Note: According to the Delegated Regulation, which amends the regulatory technical standards (RTS) since 25th July 2023 maximum consent duration will change from 90 to 180 days.

To be able to access either:

• The customer’s account information via the Corporate Accounts API
• The customer’s payment initiation services via the Corporate Payments API

the Client application needs to obtain an Access Token. The Corporate Access Authorization API can be used to generate the necessary Access Token. The process of obtaining an Access Token requires four actions:

1. Submitting an access request (POST /corporate/v2/authorize)
2. Requesting customer authorization of the access request (PUT /corporate/v2/authorize)
3. Obtaining an authorization code (code) (GET /corporate/v2/authorize)
4. Exchanging the authorization code (code) for an access token (POST /corporate/v2/authorize/token)

The authorization code is a grant from the Customer, it represents the customer’s permission to access their account resources via Nordea’s APIs. The code is acquired – after successful customer authorization – through the Access Status request call . See the request examples below.
Please note that the authorization code is one-time use only and must be exchanged for an Access Token immediately after it has been obtained. The authorization code cannot be reused and will not be required again after exchange for an Access Token. After the authorization code has been successfully exchanged for an Access Token, the authorization flow is complete.

API endpoints

The Corporate Access Authorization API has below endpoints:

The first endpoint is used to start the authentication process, the second and third are used to retrieve the access token.

The full process covering how to retrieve the access token by using these endpoints is described below.

Decoupled corporate access authorization flow (Nordea ID)

The access authorization flow, enables Client applications to get access to a corporate customer’s account information and payment initiation services, subject to the customer’s authorization. The Client calls the /authorize endpoint to initiate the flow, during which the customer is directed to ‘sign’ through Nordea’s Nordea ID authentication service, thereby authorizing the Client application’s access. The Client then acquires an access token to use in the Corporate Accounts or Corporate Payments API endpoints.

Note that, each Access Request is assigned, identified and referenced by, a unique access_id. The Client can negotiate multiple Access Requests (perhaps to different purposes even on the same agreement) and access_id is provided to enable them to track the progress of each request.

The authorization framework has several roles

The client is the owner of the client Application which is requesting this access.

Nordea Open Banking platform exposes the APIs, including Authorize, Accounts and Payments endpoints, and integrates in this flow with the Nordea ID authentication service infrastructure to initiate customer authentication and authorization of the client’s access.

The Nordea ID authentication service is a Nordea service developed to allow companies, banks, and governments to authenticate and conclude agreements.

The following diagram illustrates how the flow works:

At a high level, the flow follows these steps:

1. Consent is negotiated and agreed between the Resource Owner and the Client.
2. Request Access (POST /corporate/v2/authorize) is sent by the client to Nordea Open Banking API in order to initiate the Access Request. The client’s request must include the following parameters:
   1. Scope of access required (“ACCOUNTS_BROADBAND”, “ACCOUNTS_PSD2”, “PAYMENTS_PSD2 and “PAYMENTS_BROADBAND” are the scopes supported).
   2. Duration of access required.
   3. Agreement number identifying the Nordea customer agreement being targeted by this access request.
3. Nordea will, in-turn, respond by providing the Access Request reference (access_id). This reference must be used in subsequent API interchanges pertaining to this Access Request.
4. Authorize Access (PUT /corporate/v2/authorize/<access_id>) is sent by the Client in order to secure the Resource Owner’s confirmation of the Access Request. Authorize Access has the nominated Authorizer’s identity for a parameter:
   1. The nominated Authorizer’s identity (a corporate user’s logon ID).
5. Once the first Authorize Access request has been made in step 4 above, the client may proceed to issue a second Authorize Access request, this time specifying the 2nd nominated Authorizer in the body of the request.
   • Note: If one Authorizer has successfully signed the Access Request but a second is required and has not yet been nominated, the Access Request Status will be returned as “PARTIAL”, this indicates to the client that a second Authorizer is required.
   • Authorize Access (PUT /corporate/v2/authorize/<access_id>) request is received from the client app, modifying the existing Access Request in order to include an additional authorizer
6. Upon receiving the Client’s request Nordea will: Initiate authentication of the nominated Authorizer, creating an authentication and signing request at the Nordea ID authentication service. The Authorizer will be asked to authenticate using their credentials and sign that: “You are providing access to Application X for company Y and agreement id nnnnnnnn for a duration of ddddd”.
   1. The remainder of the flow traces steps 5 - 8 of the simple single-Authorizer flow outlined above.
7. The Client should repeatedly poll the Nordea API to obtain updated status of the Access Request until such time as the Authorizer has successfully “signed” the session initiated on the Nordea ID authentication service:
   1. Access Request Status (GET /corporate/v2/authorize/<access_id>) request is received from Client app at Nordea API.
   2. Nordea API will respond with the current status: PENDING, ACTIVE, FAILED, and so on.
8. If the Access Request has been successfully signed an Authorization Code (code) is additionally returned to the Client together with ACTIVE status. The Client can exchange this code for an Access Token.
9. FetchToken (POST /corporate/v2/authorize/token) request is received from Client APP at Nordea API:
   1. The Authorization Code (code) is specified within the body of this request.
   2. Access token is exchanged with Client app

Access authorization process details

In order to receive an access token, the Client and Resource Owner must first agree consent, after which the Client:

1. Calls POST /corporate/v2/authorize, passing the required parameters and receiving an access request identifier (access_id).
2. Polls for an authorization code (code) using the access_id.
3. Once the polling succeeds, exchanges the code for the access token and refresh token

Please note that the code is one time use only, code is never used or required again after it is exchanged for an access token After the code is exchanged for an access token, the authorization flow is complete and the Client (application) can start using the API.

Request access

First, the Resource Owner needs to give consent, and then the client starts the process by creating an Access Request:

POST /corporate/v2/authorize

With the following parameters in the body of call:

{
   "scope": ["ACCOUNTS_BROADBAND"],
   "duration":129600,
   "agreement_number": "130474822427"
}

That will return the following:

{
    "group_header": {
        "message_identification": "IseW7LO0_Bs",
        "creation_date_time": "2019-04-23T09:31:51.494Z",
        "http_code": 201
    },
    "response": {
        "access_id": "4f81886c-78c0-4990-a07d-0dd4f4d414b0",
        "status": "CREATED",
        "client_token":<Token>,
        "_links": [
            {
                "rel": "status",
                "href": "/v2/authorize/4f81886c-78c0-4990-a07d-0dd4f4d414b0"
            },
            {
                "rel": "add_authorizer",
                "href": "/v2/authorize/4f81886c-78c0-4990-a07d-0dd4f4d414b0"
            }
        ]
    }
}
 

Payload parameters are described below:

Authorize access

Once the Access Request has been created the Client requests authorization of the request by nominating one or more Authorizers that will sign the request (testable Authorizer identities to access sample data in sandbox are given here). These Authorizers are nominated by calls to the Authorize Access endpoint:

PUT /corporate/v2/authorize/<access_id>

Where the <access_id> is a key from the initiating call that looks like the following:

4f81886c-78c0-4990-a07d-0dd4f4d414b0

and is a {client_token} from the initiating call.

With parameters as shown in this example:

{
   "authorizer_id":"70311198",
}

The call will return the following:

{ 
    "group_header": { 
        "message_identification": "yP6EzKRjarI", 
        "creation_date_time": "2019-04-04T07:51:48.205Z", 
        "http_code": 200 
    }, 
    "response": { 
        "status": "PENDING", 
        "_links": [ 
            { 
                "rel": "status", 
                "href": "/v2/authorize/4f81886c-78c0-4990-a07d-0dd4f4d414b0" 
            } 
        ] 
    } 
}  
 

The payload parameters are:

Polling for authorization code

The Client should repeatedly poll the Nordea API to obtain updated status of the Access Request until such time as the Authorizer has successfully “signed” the session initiated on the Nordea ID authentication service. The Nordea API will respond with the current status: PENDING, ACTIVE, FAILED, and so on.

If the Access Request has been successfully signed an Authorization Code (code) is additionally returned to the Client together with ACTIVE status. The Client can exchange the code for an Access Token.

So, to retrieve an access token, the Client first needs to get the code_, which is done when the Client sends the following request:

GET /corporate/v2/authorize/<access_id>

Where the <access_id> is a key from the initiating call that looks like the following:

4f81886c-78c0-4990-a07d-0dd4f4d414b0

While the Client waits for the authorizer to confirm the authentication request, the response will return a “status”: PENDING

The timeout for the polling is set to 3 minutes on production environment and 2 minutes for testing on sandbox environment. After this time, if the authorizer did not confirm the request, the response will return a “status”: FAILED

Where the authorizer has confirmed the request, the response with return a “status” of either:

• “PARTIAL” indicating a second authorizer needs to corroborate the request
• “ACTIVE” if authorization has been obtained from the Customer and the authorization code (code) can be exchanged for an access token.

If authorization is obtained the response looks like this:

{
         "group_header": {
                "message_identification": "1K4OMoNS3Ps",
                "creation_date_time": "2018-10-18T05:30:54.447Z",
                "http_code": 200
      },
      "response": {
           "status": "ACTIVE",
            "code": "<code>",
      "_links": [
      {
          "rel": "self",
           "href": "/v2/authorize/4f81886c-78c0-4990-a07d-0dd4f4d414b0"
       },
       {
           "rel": "token",
           "href": "/v2/authorize/token"
       }
    ]
  }
}
 

Retrieving access token authorization

After the Access Request has been successfully signed an authorization code (code) is additionally returned to the Client together with ACTIVE status. The Client can exchange this code for an Access Token.
You can get access token by using the /token endpoint in two ways, either by exchanging code or a refresh token.
Each successful response will contain both new access token and new refresh token.

For example:

POST /corporate/v2/authorize/token

Payload parameters used in the body of this request are:

In the response you will receive:

• access_token which acts as the short lived key to our other services
• expires_in refers to access token life duration (in seconds)
• token_type is an identifier for the token type, the access token always will have type bearer
• refresh_token which can be used to extend access_token duration

Refresh tokens live as long as consent does but can be used only once.

Exchanging code for an access token

When you want to exchange an authorization code (code) for an access token you need to set grant_type parameter value to authorization_code and include the code value from the GET /corporate/v2/authorize/<access_id> response.

For example:

POST /corporate/v2/authorize/token

The Header includes:

other Header data omitted ```
-H "X-IBM-Client-Id": "<Client ID>"
-H "X-IBM-Client-Secret": "<Client Secret>"
-H "Content-Type": "application/x-www-form-urlencoded"

The request body looks like this:

grant_type=authorization_code
&code=<code>

And the response example:

{
    "group_header": {
        "message_identification": "6nsxN5O-j6U",
        "creation_date_time": "2019-04-16T08:33:39.889Z",
        "http_code": 201
    },
    "response": {
        "access_token": "<access_token>",
        "expires_in": 3599,
        "token_type": "Bearer",
        "refresh_token": "<refresh_token>"
}
 

Exchanging refresh token for a new access token

When you wish to exchange a refresh token for a fresh access token you need to set grant_type parameter value to refresh_token and include the refresh_token value from the previous GET /corporate/v2/authorize/token response. For example:

POST /corporate/v2/authorize/token

The request body looks like this:

grant_type=refresh_token
&refresh_token=<token>

And the response example:

{
    "group_header": {
        "message_identification": "PeuE7L_DgOU",
        "creation_date_time": "2019-04-16T09:06:09.895Z",
        "http_code": 201
    },
    "response": {
        "access_token": "<access_token>",
        "expires_in": 3599,
        "token_type": "Bearer",
        "refresh_token": "<refresh_token>"
    }
}

Sample data

A substantial amount of sample data (accounts and transactions) have been placed in the sandbox environment to allow developers to explore API features/behaviour and test their Client Application functionality. The following Authorizer identities can be used to negotiate the Access Authorization decoupled workflow and obtain access to this sample data:

Redirect corporate access authorization workflow

The redirect corporate access authorization flow enables the Client to get access to a Nordea Corporate customers’ payment accounts, subject to the Resource Owner’s authorization. The Client calls the /authorize endpoint to initiate this flow, from which the customer is directed to authenticate themselves and select accounts if applicable, for which the agreed access should apply. The Client can then acquire an access token to use in the AIS and PIS APIs.

Note: Before initiating this flow, it is assumed the Client will have negotiated consent with the Resource Owner.

The authorization framework has several roles

The client is the owner of the client Application which is requesting this access. It is important to stress that the consent is between the Client and the Resource Owner

The following diagram illustrates how the flow works:

At a high level, the flow follows these steps:

1. Consent is negotiated and agreed between the Resource Owner and the Client.
2. Request Access (POST /corporate/v2/authorize) is sent by the client to Nordea Open Banking API in order to initiate the Access Request. The client’s request must include the following parameters:
   1. Scope of access required (“ACCOUNTS_PSD2”, “PAYMENTS_PSD2” or “ACCOUNTS_BROADBAND” and “PAYMENTS_BROADBAND”).
   2. Duration of access required.
   3. Agreement number identifying the Nordea customer agreement being targeted by this access request.
3. Nordea will, in-turn, respond by providing the Access Request reference (access_id). This reference must be used in subsequent API interchanges pertaining to this Access Request.
4. Authorize Access (PUT /corporate/v2/authorize/<access_id>) is sent by the Client in order to secure the Resource Owner’s confirmation of the Access Request. Authorize Access has the nominated Authorizer’s identity for a parameter:
   1. The nominated Authorizer’s identity (a corporate user’s logon ID).
5. Once the first Authorize Access request has been made in step 4 above, the client may proceed to issue a second Authorize Access request, this time specifying the 2nd nominated Authorizer in the body of the request.
   • Note: If one Authorizer has successfully signed the Access Request but a second is required and has not yet been nominated, the Access Request Status will be returned as “PARTIAL”, this indicates to the client that a second Authorizer is required.
   • Authorize Access (PUT /corporate/v2/authorize/<access_id>) request is received from the client app, modifying the existing Access Request in order to include an additional authorizer
6. Upon receiving the Client’s request Nordea will: Initiate authentication of the nominated Authorizer, creating an authentication and signing request at the Nordea ID authentication service. The Authorizer will be asked to authenticate using their credentials and sign that: “You are providing access to Application X for company Y and agreement id nnnnnnnn for a duration of ddddd”.
   1. The remainder of the flow traces steps 5 - 8 of the simple single-Authorizer flow outlined above.
7. The Client should repeatedly poll the Nordea API to obtain updated status of the Access Request until such time as the Authorizer has successfully “signed” the session initiated on the Nordea ID authentication service:
   1. Access Request Status (GET /corporate/v2/authorize/<access_id>) request is received from Client app at Nordea API.
   2. Nordea API will respond with the current status: PENDING, ACTIVE, FAILED, and so on.
8. If the Access Request has been successfully signed an Authorization Code (code) is additionally returned to the Client together with ACTIVE status. The Client can exchange this code for an Access Token.
9. FetchToken (POST /corporate/v2/authorize/token) request is received from Client APP at Nordea API:
   1. The Authorization Code (code) is specified within the body of this request.
   2. Access token is exchanged with Client app

Access authorization process details

In order to receive an access token, the Client and Resource Owner must first agree consent, after which the Client:

1. Calls POST /corporate/v2/authorize, passing the required parameters and receiving an access request identifier (access_id).
2. Polls for an authorization code (code) using the access_id.
3. Once the polling succeeds, exchanges the code for the access token and refresh token

Please note that the authorization code is one time use only, authorization code is never used or required again after it is exchanged for an access token After the authorization code is exchanged for an access token, the authorization flow is complete and the Client (application) can start using the API.

Request access

First, the Resource Owner needs to give consent, and then the client starts the process by creating an Access Request:

POST /corporate/v2/authorize

With the following parameters in the body of call:

{
   "scope": ["ACCOUNTS_BROADBAND"],
   "duration":129600,
   "agreement_number": "130474822427"
}
 

That will return the following:

{
    "group_header": {
        "message_identification": "IseW7LO0_Bs",
        "creation_date_time": "2019-04-23T09:31:51.494Z",
        "http_code": 201
    },
    "response": {
        "access_id": "4f81886c-78c0-4990-a07d-0dd4f4d414b0",
        "status": "CREATED",
        "client_token":<Token>,
        "_links": [
            {
                "rel": "status",
                "href": "/v2/authorize/4f81886c-78c0-4990-a07d-0dd4f4d414b0"
            },
            {
                "rel": "add_authorizer",
                "href": "/v2/authorize/4f81886c-78c0-4990-a07d-0dd4f4d414b0"
            }
        ]
    }
}
 

Payload parameters are described below:

Authorize access

Once the Access Request has been created the Client requests authorization of the request by nominating one or more Authorizers that will sign the request (testable Authorizer identities to access sample data in sandbox are given here). These Authorizers are nominated by calls to the Authorize Access endpoint:

PUT /corporate/v2/authorize/<access_id>

Where the <access_id> is a key from the initiating call that looks like the following:

4f81886c-78c0-4990-a07d-0dd4f4d414b0

and is a {client_token} from the initiating call.

With parameters as shown in this example:

{
    "authentication_type": "REDIRECT",
    "redirect_uri": "https://example.com",
    "state": "<state>"
}

With the header including:

X-Nordea-Mock-Authorizer-Id: <Authorizer_ID>

The call will return the following:

{
    "group_header": {
        "message_identification": "_Pk7-3ZaCXb4Gujr",
        "creation_date_time": "2021-05-26T11:57:57.782489Z",
        "http_code": 200
    },
    "response": {
        "status": "PENDING",
        "_links": [
            {
                "rel": "redirect",
                "href": "https://api.nordeaopenbanking.com?client_id=Rsf9OPDHmnLy2Sfyr4UF&code_challenge_method=S256&redirect_uri=http%253A%252F%252Flocalhost%253A7002&response_type=code&code_challenge=EyymAbWlAlH3UXvgeKt8b-ZlN2exjNEabkyFgAHckms&scope=openid+ndf+agreement&state=SNEQn3yLkbf5_6aU&nonce=MC6CFf4QkgPhJotXovAXBtDr6fs31WNocHVbEVta"
            },
            {
                "rel": "status",
                "href": "/v2/authorize/8015213c-03b3-4435-8aeb-2dd32e9d6b5c"
            }
        ]
    }
}
 

The payload parameters are:

Polling for authorization code

The Client should repeatedly poll the Nordea API to obtain updated status of the Access Request until such time as the Authorizer has successfully “signed” the session initiated on the Nordea ID authentication service. The Nordea API will respond with the current status: PENDING, ACTIVE, FAILED, and so on.

If the Access Request has been successfully signed an Authorization Code (code) is additionally returned to the Client together with ACTIVE status. The Client can exchange the Authorization code for an Access Token.

So, to retrieve an access token, the Client first needs to get the Authorization code code, which is done when the Client sends the following request:

GET /corporate/v2/authorize/<access_id>

Where the <access_id> is a key from the initiating call that looks like the following:

4f81886c-78c0-4990-a07d-0dd4f4d414b0

While the Client waits for the authorizer to confirm the authentication request, the response will return a “status”: PENDING

The timeout for the polling is set to 3 minutes on production environment and 2 minutes for testing on sandbox environment. After this time, if the authorizer did not confirm the request, the response will return a “status”: FAILED

Where the authorizer has confirmed the request, the response with return a “status” of either:

• “PARTIAL” indicating a second authorizer needs to corroborate the request
• “ACTIVE” if authorization has been obtained from the Customer and the authorization code (code) can be exchanged for an access token.

If authorization is obtained the response looks like this:

{
         "group_header": {
                "message_identification": "1K4OMoNS3Ps",
                "creation_date_time": "2018-10-18T05:30:54.447Z",
                "http_code": 200
      },
      "response": {
           "status": "ACTIVE",
            "code": "<code>",
      "_links": [
      {
          "rel": "self",
           "href": "/v2/authorize/4f81886c-78c0-4990-a07d-0dd4f4d414b0"
       },
       {
           "rel": "token",
           "href": "/v2/authorize/token"
       }
    ]
  }
}
 

Retrieving access token authorization

After the Access Request has been successfully signed an authorization code (code) is additionally returned to the Client together with ACTIVE status. The Client can exchange this authorization code for an Access Token.
You can get access token by using the /token endpoint in two ways, either by exchanging authorization code or a refresh token.
Each successful response will contain both new access token and new refresh token.

For example:

POST /corporate/v2/authorize/token

Payload parameters used in the body of this request are:

In the response you will receive:

• access_token which acts as the short lived key to our other services
• expires_in refers to access token life duration (in seconds)
• token_type is an identifier for the token type, the access token always will have type bearer
• refresh_token which can be used to extend access_token duration

Refresh tokens live as long as consent does but can be used only once.

Exchanging code for an access token

When you want to exchange an authorization code (code) for an access token you need to set grant_type parameter value to authorization_code and include the code value from the GET /corporate/v2/authorize/<access_id> response.

For example:

POST /corporate/v2/authorize/token

The Header includes:

other Header data omitted ```
-H "X-IBM-Client-Id": "<Client ID>"
-H "X-IBM-Client-Secret": "<Client Secret>"
-H "Content-Type": "application/x-www-form-urlencoded"

The request body looks like this:

grant_type=authorization_code
&code=<code>

And the response example:

{
    "group_header": {
        "message_identification": "6nsxN5O-j6U",
        "creation_date_time": "2019-04-16T08:33:39.889Z",
        "http_code": 201
    },
    "response": {
        "access_token": "<access_token>",
        "expires_in": 3599,
        "token_type": "Bearer",
        "refresh_token": "<refresh_token>"
}
 

Exchanging refresh token for a new access token

When you wish to exchange a refresh token for a fresh access token you need to set grant_type parameter value to refresh_token and include the refresh_token value from the previous GET /corporate/v2/authorize/token response. For example:

POST /corporate/v2/authorize/token

The request body looks like this:

grant_type=refresh_token
&refresh_token=<token>

And the response example:

{
    "group_header": {
        "message_identification": "PeuE7L_DgOU",
        "creation_date_time": "2019-04-16T09:06:09.895Z",
        "http_code": 201
    },
    "response": {
        "access_token": "<access_token>",
        "expires_in": 3599,
        "token_type": "Bearer",
        "refresh_token": "<refresh_token>"
    }
}

Sample data

A substantial amount of sample data (accounts and transactions) have been placed in the sandbox environment to allow developers to explore API features/behaviour and test their Client Application functionality. The following Authorizer identities can be used to negotiate the Access Authorization redirect workflow and obtain access to this sample data: