Creating the Installation

1. Installation

Installation is the first step in activating your API key!

It creates an API context, which is a secure foundation for all future interactions. This step ensures that the API key is properly registered and associated with a trusted user, reducing the risk of unauthorized access. Without installation, the API key alone could be misused if leaked. This is similar to setting up encryption keys before securely exchanging data.

Firstly, you'll need to generate a public-private key pair using OpenSSL following these steps:

1. Open a terminal.

2. Run the following command to generate the key pair:

   openssl genrsa -out installation.key && openssl rsa -in installation.key -outform PEM -pubout -out installation.pub

3. Your installation key pair will be stored as:

   $(pwd)/installation.pub #your public-key
   $(pwd)/installation.key #your private-key

4. Copy the installation.pub value

   cat ~(pwd)/installation.pub | pbcopy #this command can be different depending on your Operating System.

After generating your key pair, you'll be able to pass the installation.pub in the request body as value for the field client_public_key.

Here you can find all required fields for the installation endpoint:

post

This is the only API call that does not require you to use the "X-Bunq-Client-Authentication" and "X-Bunq-Client-Signature" headers. You provide the server with the public part of the key pair that you are going to use to create the value of the signature header for all future API calls. The server creates an installation for you. Store the Installation Token and ServerPublicKey from the response. This token is used in the "X-Bunq-Client-Authentication" header for the creation of a DeviceServer and SessionServer.

Header parameters

Cache-ControlstringOptional

The standard HTTP Cache-Control header is required for all signed requests.

User-AgentstringRequired

The User-Agent header field should contain information about the user agent originating the request. There are no restrictions on the value of this header.

X-Bunq-LanguagestringOptional

The X-Bunq-Language header must contain a preferred language indication. The value of this header is formatted as a ISO 639-1 language code plus a ISO 3166-1 alpha-2 country code, separated by an underscore. Currently only the languages en_US and nl_NL are supported. Anything else will default to en_US.

X-Bunq-RegionstringOptional

The X-Bunq-Region header must contain the region (country) of the client device. The value of this header is formatted as a ISO 639-1 language code plus a ISO 3166-1 alpha-2 country code, separated by an underscore.

X-Bunq-Client-Request-IdstringOptional

This header must specify an ID with each request that is unique for the logged in user. There are no restrictions for the format of this ID. However, the server will respond with an error when the same ID is used again on the same DeviceServer.

X-Bunq-GeolocationstringOptional

This header must specify the geolocation of the device. The format of this value is longitude latitude altitude radius country. The country is expected to be formatted of an ISO 3166-1 alpha-2 country code. When no geolocation is available or known the header must still be included but can be zero valued.

X-Bunq-Client-AuthenticationstringRequired

The authentication token is used to authenticate the source of the API call. It is required by all API calls except for POST /v1/installation. It is important to note that the device and session calls are using the token from the response of the installation call, while all the other calls use the token from the response of the session-server call

Body

client_public_keystringWrite-onlyRequired

Your public key. This is the public part of the key pair that you are going to use to create value of the "X-Bunq-Client-Signature" header for all future API calls.

Responses

200

Installation is used to tell the server about the public key of your key pair. The server uses this key to verify your subsequent calls, which need to be signed with your own private key. Additionally, you can use the token you get from an Installation to authenticate the registration of a new device.

application/json

400

This is how the error response looks like for 4XX response codes

application/json

post

HTTPcURLJavaScriptPython

POST /v1/installation HTTP/1.1
Host: public-api.sandbox.bunq.com
User-Agent: text
X-Bunq-Client-Authentication: text
Content-Type: application/json
Accept: */*
Content-Length: 28

{
  "client_public_key": "text"
}

{
  "Id": {
    "id": 1
  },
  "Token": {
    "id": 1,
    "created": "text",
    "updated": "text",
    "token": "text"
  },
  "ServerPublicKey": {
    "server_public_key": "text"
  }
}

What's next

With the installation_token and the server_public_key in hands, we are able to authenticate ourselves and register our device for future endpoint calls.