Callbacks (Webhooks)
Looking for Webhooks? You're on the right page!
Callbacks are used to send real-time notifications on the events that happen on a bunq account.
To receive notifications for certain events on a bunq account, you need to create notification filters. It is possible to send the notifications to a provided URL and/or the user’s phone as push notifications.
Notification FIlters
Use the notification-filter-push
resource to create and manage push notification filters. Provide the type of events you want to receive notifications about in the category
field.
Example request body:
{
"notification_filters":[
{
"category":"SCHEDULE_RESULT"
}
]
}
Use the notification-filter-url
resource to create and manage URL notification filters. The callback URL you provide in the notification_target field must use HTTPS.
Example request body:
{
"notification_filters":[
{
"category":"PAYMENT",
"notification_target":"{YOUR_CALLBACK_URL}"
}
]
}
Callback categories
Category
Description
BILLING
notifications for all bunq invoices
CARD_TRANSACTION_SUCCESSFUL
notifications for successful card transactions
CARD_TRANSACTION_FAILED
notifications for failed card transaction
CHAT
notifications for received chat messages
DRAFT_PAYMENT
notifications for creation and updates of draft payments
IDEAL
notifications for iDEAL-deposits towards a bunq account
SOFORT
notifications for SOFORT-deposits towards a bunq account
MUTATION
notifications for any action that affects a monetary account’s balance
OAUTH
notifications for revoked OAuth connections
PAYMENT
notifications for payments created from, or received on a bunq account (doesn’t include payments that result out of paying a Request, iDEAL, Sofort or Invoice). Outgoing payments have a negative value while incoming payments have a positive value
REQUEST
notifications for incoming requests and updates on outgoing requests
SCHEDULE_RESULT
notifications for when a scheduled payment is executed
SCHEDULE_STATUS
notifications about the status of a scheduled payment, e.g. when the scheduled payment is updated or cancelled
SHARE
notifications for any updates or creation of Connects (ShareInviteBankInquiry)
TAB_RESULT
notifications for updates on Tab payments
BUNQME_TAB
notifications for updates on bunq.me Tab (open request) payments
SUPPORT
notifications for messages received from us through support chat
Mutation Category
A Mutation is a change in the balance of a monetary account. A Mutation is created for each payment-like object, such as a request, iDEAL-payment or a regular payment. Therefore, the MUTATION
category can be used to keep track of a monetary account's balance change.
Receiving Callbacks
Callbacks for the sandbox environment will be made from different IP's at AWS.
Callbacks for the production environment will be made from 185.40.108.0/22.
The IP addresses might change. We will notify you in a timely fashion if such a change is planned.
Retry mechanism
When the execution of a callback fails (e.g. the callback server is down or the response contains an error), we try to resend it for a maximum of 5 times, with an interval of one minute between each try. If your server is not reachable by the callback after the 6th total try, the callback is not sent anymore.
Removing callbacks
To remove callbacks for an object, send a PUT request to the user-person, user-company, monetary-account or cash-register resource with the notification_filters
field of the JSON request body unset.
{
"notification_filters": []
}
Setting up a callback
Check Notification Filter for all possible callbacks, here we show one example API call to set up a new URL notification. For instance for succesful card transactions: ```
{
"notification_filters": [
{"category": "CARD_TRANSACTIONSUCCESSFUL",
"notification_target": "https://webhook.site/994966bb-7a4c-4be3-836a-da65231b907d"}
]
}
Manage the url notification filters for a user.
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/user/{userID}/notification-filter-url HTTP/1.1
Host: public-api.sandbox.bunq.com
User-Agent: text
X-Bunq-Client-Authentication: text
Content-Type: application/json
Accept: */*
Content-Length: 103
{
"notification_filters": [
{
"notification_filters": [
{
"notification_filters": [
"[Circular Reference]"
]
}
]
}
]
}
{
"Id": {
"id": 1
}
}
Certificate Pinning
We recommend that you use certificate pinning as an extra security measure. We will check if the certificate of the recipient server matches the pinned certificate that you provided and cancel the callback if the check fails or we detect a mismatch.
How to set up certificate pinning
Retrieve the SSL certificate of your server using the following command:
openssl s_client -servername www.example.com -connect www.example.com:443 < /dev/null | sed -n "/-----BEGIN/,/-----END/p" > www.example.com.pem
POST
the certificate to thecertificate-pinned
endpoint.
Once ready, every callback will be checked against the pinned certificate that you provided. Note that if the SSL certificate on your server expires or is changed, our callbacks will fail.
Pin the certificate chain.
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/user/{userID}/certificate-pinned HTTP/1.1
Host: public-api.sandbox.bunq.com
User-Agent: text
X-Bunq-Client-Authentication: text
Content-Type: application/json
Accept: */*
Content-Length: 46
{
"certificate_chain": [
{
"certificate": "text"
}
]
}
{
"id": 1
}
Last updated
Was this helpful?