PARTIAL and PENDING statuses (Corporate Access Authorization): FAQ

Corporate Authorization API

API Reference - Corporate Access Authorization API

Q:

One of our users experiences a problem with the following API response:

{"group_header":{"message_identification":"27adf6432d12345a","creation_date_time":"2022-12-28T08:12:34.573971Z","http_code":200},"response":{"status":"PARTIAL","_links":[{"rel":"self","href":"/v2/authorize/12345ad9-132e-1234-8c56-a4afc13bd1cb"},{"rel":"add_authorizer","href":"/v2/authorize/12345ad9-132e-1234-8c56-a4afc13bd1cb"}]}}

What extra steps should be performed to get the final status of the authorization?

A:

In order to finalize the authorization you need to add a second authorizer. The proper way of usage should be:

• Add the first authorizer and confirm in the app
• Poll for status - get PARTIAL
• Add the second authorizer and confirm in the app
• Poll for status - get ACTIVE

Please refer to:

Access authorization process details/Polling for authorization code (Corporate Authorization API)

Get status of the authorization process: GET /corporate/v2/authorize/{access_id}

Note: The user has a "Two together" authorization role active in Nordea Corporate Netbank. Alternatively, the user can have his role changed to "Alone" so he can authorize by his own. If needed, contact details for Corporate Netbank can be found here:

Nordea Corporate Netbank contacts

Q:

When the first ‘Confirm authorization’ request has been made:

PUT /corporate/v2/authorize/<access_id>

we make a second one for the authorizer 2, but we get the response: “No additional authorizers required.” Why is that?

A:

You're trying to authorize the second user before the first one has performed the authorization. You have to wait for the authorizer 1 to sign before you can trigger the authorizer 2.

Q:

Yes, that is correct. The second request is sent as soon as the status PARTIAL is returned from the API - directly after the first authorization request has been sent (even though it has not been signed yet). How to keep track on whether the first authorizer has signed or not?

A:

Refer to our documentation - especially step no 7 (about polling the status):

Decoupled corporate access authorization flow (Nordea ID)

Q: 

We send the request:

PUT /corporate/v2/authorize/<access_id>

and directly after that (while waiting for the first user to sign) making the request:

GET /corporate/v2/authorize/{access_id}

and then we get the status PARTIAL, no matter if the first authorizer has signed the request or not. Are we not supposed to get PENDING status when we make the “get status” request?

GET /corporate/v2/authorize/{access_id}

A:

If one authorizer successfully signs 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.

Q: 

I want to verify the order in which the requests should be made:

• Start an authorization flow by requesting:

• Request for the authorizer 1 to sign:

PUT /corporate/v2/authorize/<access_id>

• Poll for status (whether the authorizer 1 has signed or not)

GET /corporate/v2/authorize/{access_id}

• Status PENDING should be returned until the authorizer 1 has signed
• When the authorizer 1 has signed, the status should be changed to PARTIAL
• Make the request for the authorizer 2 to sign
• Continue polling for status:

GET /corporate/v2/authorize/{access_id}

• When the authorizer 2 has signed - status ACTIVE is returned.

Is that order correct? Are we not supposed to poll for status PENDING to know if the authorizer 1 has signed or not? And then when we get the status PARTIAL, make the request for authorizer 2 to sign?

A:

The order is correct. Additionally, if two "signatures" are required (according to Corporate Netbank Agreement) and even if only one request was sent (i.e. for the authorizer 1), the logic of application infer PARTIAL automatically, so PENDING will not be available in this context.

Q:

When the request for the authorizer 1 to sign has been made, how will we know when to send the request for the authorizer 2 to sign? Should we just wait for two minutes to send the second request?

A:

There is no precise state indicating user's signing state. From the client perspective PARTIAL covers both: waiting for signing or already signed (by the authorizer 1). When the authorizer 1 will not sign (after established time period, i.e. 3 min) - then polling returns FAILED. When only one signed - then PARTIAL. When both will sign - then ACTIVE.

Q:

When authorizer 1 has signed, is there a time limit for how long authorizer 2 can wait until he needs to sign? For example: if authorizer 1 signs today, can authorizer 2 signs tomorrow or will this fail?

A:

A time limit for both authorizers is set to 3 minutes. Please refer to:

Q:

When two authorizers need to complete the authorization flow, do we need two different access_ids when sending PUT requests?

PUT /corporate/v2/authorize/<access_id>

A:

No, the nominated authorizers need to complete the authorization flow (authorize access) within the unique access_id acquired by requesting:

Q:

In the sandbox environment, we're implementing the Corporate Authorization API v3. We downloaded the Postman collection file from:

Swagger and Postman files (Nordea API Market Resources)

Our flow is as follows: 

Firstly, the "Request access" works, which returns the access_id and client_token. These two parameters are subsequently used in the next API call, "Authorize access", which returns a status. To retrieve the authorisation status, a subsequent GET API call is made, which should return ACTIVE.

However, in our case, it consistently returns "status":"PENDING". This is the issue we're facing. It functions correctly in Postman but not when configured in our code.

Request:
HTTP Method: GET
Request URL: 
https://api.nordeaopenbanking.com/corporate/v3/authorize/747c1c7c-***-f486658ebed0
Headers:
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer eyJjdHkiOiJKV1QiLCJlbmMiOiJ***.7okqMinohXc9w66X_y1xEA
X-IBM-Client-Id: 8059ad***c9d
X-IBM-Client-Secret: ***
X-Nordea-Originating-Date: Fri, 09 Jan 2026 09:44:49 GMT
X-Nordea-Originating-Host: api.nordeaopenbanking.com

Response:
Http Code: 200
Response Body: 
{"group_header":{"message_identification":"e5805412dbd9e2572dc39f46f077bd44","creation_date_time":"2026-01-09T08:44:49.33454501Z","http_code":200},"response":{"status":"PENDING","_links":[{"rel":"self","href":"/v3/authorize/747c1c7c-***-f486658ebed0"}]}}

A:

You need to use one of the Authorizer IDs from the list available in our API documentation:

Sample data (Corporate Authorization API v3)

Q:

We're implementing Corporate Access Authorization API v2 for Payment Track & Trace Premium API. In the following decoupled sandbox flow we encounter the issue in Step 3:

✅ Step 1: Request Access Authorization: POST /corporate/v2/authorize
- Status: 201 Created
- Successfully receives access_id and client_token
- Includes agreement_number: 130474822200

✅ Step 2: Authorize Access: PUT /corporate/v2/authorize/{access_id}
- Status: 200 OK
- Authorization request sent successfully
- Status: PENDING
- Using test authorizer ID: 70311198 (decoupled flow)

❌ Step 3: Poll for Authorization Code: GET /corporate/v2/authorize/{access_id}
- Status: 200 OK (status remains "PENDING")
- Issue: Authorization status stays "PENDING" for multiple polling attempts (2 seconds apart)
- Eventually status changes to "FAILED"
- Never receives authorization code

REQUEST DETAILS:
----------------
Step 1 Request:
POST https://api.nordeaopenbanking.com/corporate/v2/authorize
Body: {
"scope": ["PAYMENTS_BROADBAND"],
"duration": 129600,
"agreement_number": "130474822200"
}
Response: 201 Created with access_id and client_token

Step 2 Request:
PUT https://api.nordeaopenbanking.com/corporate/v2/authorize/{access_id}
Headers: Authorization: Bearer {client_token}
Body: {
"authorizer_id": "70311198"
}
Response: 200 OK, status: "PENDING"

Step 3 Request (repeated polling):
GET https://api.nordeaopenbanking.com/corporate/v2/authorize/{access_id}
Headers: Authorization: Bearer {client_token}
Response: 200 OK, status: "PENDING" (never changes to "ACTIVE")

A:

The test authorizer from Step 2: 70311198 is not a part of the agreement from Step 1: 130474822200. To check relations between agreements and authorizers, please use:

GET corporate/v2/authorize/users

Q:

Is this a proper decoupled sandbox "Two together" authorization flow for the agreement 130474822200? 

• POST /corporate/v2/authorize to get access_id and client_token
• PUT /corporate/v2/authorize/{access_id} with the first authorizer_id 70312662 and that client_token – returns status PENDING
• GET /corporate/v2/authorize/{access_id} until the status becomes PARTIAL
• Second POST /corporate/v2/authorize (same body) to get a new client_token
• Second PUT /corporate/v2/authorize/{access_id} (access_id from the first POST) with the second authorizer_id 70313004 and the new client_token - this returns 403 with "Missing access token or token does not authorize requested action."

A:

No, it is not. The correct flow should be as follows, excluding the second POST /corporate/v2/authorize request:

• POST /corporate/v2/authorize to get access_id and client_token
• PUT /corporate/v2/authorize/{access_id} with the first authorizer_id 70312662 and that client_token – returns status PENDING
• GET /corporate/v2/authorize/{access_id} until the status becomes PARTIAL
• Second PUT /corporate/v2/authorize/{access_id} with the second authorizer_id 70313004
• GET /corporate/v2/authorize/{access_id} until the status becomes ACTIVE and the "code" is generated
• POST /v2/authorize/token to exchange the code for the pair of access_token and refresh_token

Q:

We are testing Corporate Authorization v2 in the sandbox environment. Despite testing multiple Authorizer IDs, including 70313823, the status remains PENDING without the expected transitions during polling. Our implementation follows this Redirect flow:

1. POST /corporate/v2/authorize
   Response: 201 CREATED (returns access_id + client_token)
2. PUT /corporate/v2/authorize/{access_id}
   Header used for scenario testing: X-Nordea-Mock-Authorizer-Id: 70313823
   Response: 200 PENDING + redirect link
3. GET /corporate/v2/authorize/{access_id} (poll)
   Response: 200 PENDING (repeated for multiple attempts/minutes - always PENDING)

Is there an additional sandbox step required to make status progress beyond PENDING?

A:

When implementing the Redirect flow, you must follow the redirect link received after step 2. The status will only change upon completion of this action.