Creating a sandbox user and getting an API key
Creating a sandbox user
In order to use the bunq API you'll need a bunq user. While you are building and testing you don't want to use your own bunq account, as this contains your money, and mistakes have real consequences. To give you maximum flexibility we give you the option to generate a sandbox user.
A sandbox user behaves in very much the same way as your own bunq account. So when you generate one, your user will have a name place of birth, phone number and all other information that belongs to a bank account. From there you can use this user to build and test your app. If something ever goes wrong, you can simply generate a new user.
You can log into an app of your sandbox user Sandbox version of the bunq app and also get (fake) money on the sandbox bank account that belongs to your user Getting sandbox money on the user account. When you are ready to start using your app with real money you can start Moving to production.
It's good to know there are 2 types of users you can generate. One is user-person and the other is user-company. The difference is that a user person represents a bank account for an individual. User Company creates a business bank account.
Sandbox API Keys
An API key is a unique identifier that grants access to our services and is linked to a specific user account. Think of it like a key to your bank account—keep it secure to prevent unauthorized access to your data and transactions.
For development and testing, we offer sandbox users, which simulate real accounts, including balances, cards, and payment capabilities. This allows you to test and integrate your system safely without impacting live data. You can find more details on how to create and use a sandbox user here.
DO NOT commit your API key into your source control provider (Github/Gitlab/etc).
If you end up doing so you can always revoke the key from your bunq app, or generate a new user here.
Create a sandbox user
To create a user and obtain an API key you can just run 1 command from your terminal:
Run this command to obtain a user person. It will return just a API key, but in the background we generated a dummy user for you to play around with in the sandbox.
curl --location --request POST 'https://public-api.sandbox.bunq.com/v1/sandbox-user-person'Run this command to obtain a business user
curl --location --request POST 'https://public-api.sandbox.bunq.com/v1/sandbox-user-company'This request will create a new user in the system. The response will give you the API key that belongs to this user. Store it somewhere safe.
{
"Response": [
{
"ApiKey": {
"api_key": "sandbox_a918ac413524f2bf56ceb740595e01839dd7f0321ca08e4c4ea93349"
}
}
]
}Code samples
Creating a user-person:
Used to create a sandbox userPerson.
The standard HTTP Cache-Control header is required for all signed requests.
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.
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.
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.
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.
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.
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
POST /v1/sandbox-user-person HTTP/1.1
Host: public-api.sandbox.bunq.com
User-Agent: text
X-Bunq-Client-Authentication: text
Content-Type: application/json
Accept: */*
Content-Length: 2
{}{
"Id": {
"id": 1
}
}Creating a user-company:
Used to create a sandbox userCompany.
The standard HTTP Cache-Control header is required for all signed requests.
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.
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.
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.
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.
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.
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
POST /v1/sandbox-user-company HTTP/1.1
Host: public-api.sandbox.bunq.com
User-Agent: text
X-Bunq-Client-Authentication: text
Content-Type: application/json
Accept: */*
Content-Length: 2
{}{
"Id": {
"id": 1
}
}What's next
We can almost start making calls with this API key we now have. However because of PSD2 and security reasons we first will need to register a Installation and device. Once we have those we will get a session and our user details.
Last updated
Was this helpful?