User authorization
To access a Lunar user’s resources through the Open Banking APIs, use the OAuth2 authorization-code grant with the client ID and secret that identify you as a TPP.
Start the grant by calling https://auth.openbanking.prod.lunar.app/oauth2/auth. The user is redirected to a web form, then approves the request in the Lunar app. After the user authorizes access, exchange the authorization code at https://auth.openbanking.prod.lunar.app/oauth2/token for an access token.
The API is not documented as it is a standard OAuth2 API. There are OAuth2 clients available in almost all languages, so use one that is tested and stable instead of implementing your own.
The authentication and authorization flow is a decoupled OpenID Connect flow. When an access token is requested, the user receives a push message in the Lunar app and can approve the grant there. The resulting access token can then be used with the resource APIs.
Even though
auth.openbanking.prod.lunar.app/.well-known/openid-configuration
indicates support for both client_secret_post and client_secret_basic
authentication, only client_secret_basic is supported. For more details, see
RFC6749#2.3.1 .
Extra parameters
In addition to the standard OAuth2 parameters, the /auth endpoint supports the following parameters.
Nationality
To specify a user’s nationality, add the optional nationality parameter.
Valid values: dk, no, se.
End-user application context
By default, the Lunar app identifies the party requesting access by the TPP name derived from its eIDAS certificate. This can be unclear when a TPP acts as an aggregator and retrieves account data for another application. For example, a user may start the connection in an accounting product, but see only the aggregator’s name when approving it in the Lunar app.
To give the user clearer context before they approve the connection, an aggregator can optionally include the application receiving the data and its purpose in the authorization request:
https://auth.openbanking.prod.lunar.app/oauth2/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=https%3A%2F%2Fmy-corp.com%2Fcallback&scope=PSP_AI&state=STATE&end_user_application_name=Acme%20Accounting&use_case=ACCOUNTINGThese parameters add context only. The TPP name derived from its eIDAS certificate remains visible and is not replaced. They do not change the authorization granted or affect access to data.
| Parameter | Description | Allowed values |
|---|---|---|
end_user_application_name | The human-readable name of the application that will receive the user’s data, such as the aggregator’s customer application. | Any valid UTF-8 text up to 200 characters, excluding control characters. Leading and trailing whitespace is removed. |
use_case | The purpose for which the application will use the data. The Lunar app can present this to the user as part of the connection context. | ACCOUNTING, PERSONAL_FINANCE, CREDIT_ASSESSMENT, RISK_MANAGEMENT, PAYMENT, BANKING, or OTHER. |
Both parameters are optional and should be sent only when they accurately describe the recipient and purpose. use_case is case-insensitive and surrounding whitespace is ignored. OTHER is accepted when none of the specific purposes fit; it is treated as an unspecified purpose in the app.
Invalid optional context never prevents an authorization flow from starting. Lunar ignores an invalid end_user_application_name (for example, one over 200 characters or containing control characters) or an unsupported use_case; the user then sees the standard TPP information without that invalid context.