bunq API Documentation
SDK'sPostman Collection
  • Getting Started
    • Welcome to the bunq API documentation
    • Tools
      • Software Development Kits (SDKs)
        • PHP
          • Usage
          • Tests
          • Exceptions
        • Java
          • Usage
          • Tests
          • Exceptions
        • Python
          • Usage
          • Tests
          • Exceptions
        • C#
          • Usage
          • Tests
          • Exceptions
      • Postman
      • Android Emulator
      • Developers Portal
  • Basics
    • bunq API Objects
      • User
      • Monetary Account
      • Payment
      • RequestInquiry
      • Card
      • Attachment and Note Attachment
    • API Context, Device Installation and Session
    • Authentication
      • API Keys
      • OAuth
    • Pagination
    • Errors
    • Rate Limits
    • Response body formatting
    • Moving to production
    • Headers
  • NOT SO BASICS
    • Signing
      • Python Code Example
        • Full main.py
        • Full bunq_lib.py
        • Full signing.py
      • PHP Code Example
    • Callbacks (Webhooks)
  • PSD2
    • Are you a Third Party Provider (TPP)? Start here!
      • Register as a TPP
      • Change your avatar
    • Account Information Service Provider (AISP)
    • Payment Initiation Service Provider (PISP)
    • Card-Based Payment Instrument Issuer (CBPII)
  • Support
    • FAQ
    • bunq status page
    • Terms and Conditions
  • TUTORIALS
    • Your first payment
      • Introduction
      • Creating a sandbox user and getting an API key
      • Creating the API Context
        • Creating the Installation
        • Device Registration
        • Start a Session
      • Setting up a sandbox user
        • Retrieving my user details
        • Getting sandbox money on the user account
        • Sandbox version of the bunq app
      • First Payments
    • Receiving payments on your website using bunq.me
    • How to manage your cards
      • Introduction
      • Ordering a card
      • Setting the card Limit and changing the PIN code
  • API Reference
    • Start here
    • Additional Transaction Information Category
    • Additional Transaction Information Category User Defined
    • Attachment
    • Attachment Public
    • Avatar
    • Billing Contract Subscription
    • bunqme
      • bunqme Tab
      • bunqme Fundraiser Profile
      • bunqme Tab Response
      • bunqme Fundraiser Result
    • Callback URL OAuth
    • Cards
      • Card
      • Card-Batch
      • Card Credit
      • Card Debit
      • Card Name
      • Card Replace
  • Confirmation Of Funds
  • Content and Exports
  • Currency Cloud
    • Currency cloud Benificiairy
    • Payment Quote
  • Currency Conversion
    • Convert
    • Quotes
  • Customer Statements
  • Devices
  • Draft Payment
  • Event
  • Exports
    • Export Annual Overview
    • Export RIB
    • Export Statement Card
  • Generated CVC2
  • Ideal Merchant Transaction
  • Insights
  • Installation
  • Invoice
  • Invoice Export
  • Legal Name
  • Limit
  • Mastercard Action
  • Monetary Account
    • Monetary Account Bank
    • Monetary Account Card
    • Monetary Account External
    • Monetary Account External Savings
    • Monetary Account Joint
    • Monetary Account Savings
    • Monetary Account Savings External
  • Name
  • Note Text & Attachment
    • Adyen Card Transaction
    • Switch Service Payment
    • bunqme fundraiser result
    • Draft Payment
    • Ideal Merchant Transaction
    • Mastercard Action
    • Open Banking Merchant
    • Payment Batch
    • Payment Delayed
    • Payment
    • Request Inquiry Batch
    • Request Response
    • Schedule Payment
    • Schedule Request
    • Sofort
    • Whitelist Result
  • Notification Filter
    • Notification Filter Email
    • Notification Filter Failure
    • Notification Filter Push
    • Notification Filter URL
  • OAuth
  • Payment
    • Payment
    • Payment Auto Allocate
    • Payment Batch
  • Payment Auto Allocation
  • Payment Service Provider
    • Payment Service Provider Credential
    • Payment Service Provider Draft Payment
    • Payment Service Provider Issuer Transaction
  • Request
    • Request Inquiry
    • Request Inquiry Batch
    • Request Response
  • Sandbox Users
  • Schedule
    • Schedule Instance
    • Schedule Payment
    • Schedule Payment Batch
  • Server Error
  • Server Public Key
  • Session
  • [deprecated] Share Invite Monetary Account Inquiry
  • Share Invite Monetary Account Response
  • Sofort Merchant Transaction
  • Statement
  • Switch Service Payment
  • Token QR Request Sofort
  • Transferwise
    • Transferwise Currency
    • Transferwise Quote
    • Transferwise Recipient
    • Transferwise Recipient Requirement
    • Transferwise Transfer
    • Transferwise Transfer Requirement
    • Transferwise User
  • Tree Progress
  • User
    • User Person
    • User Company
    • User Payment Service Provider
  • Whitelist SSD
    • Whitelist SSD One Off
    • Whitelist SSD Recurring
  • Content
Powered by GitBook
On this page

Was this helpful?

  1. NOT SO BASICS

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 MUTATIONcategory 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"}
    ]
}

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

  1. 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

  2. POST the certificate to the certificate-pinnedendpoint.

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.

PreviousPHP Code ExampleNextAre you a Third Party Provider (TPP)? Start here!

Last updated 1 month ago

Was this helpful?

  • Notification FIlters
  • Callback categories
  • Mutation Category
  • Receiving Callbacks
  • Retry mechanism
  • Removing callbacks
  • Setting up a callback
  • POST/user/{userID}/notification-filter-url
  • Certificate Pinning
  • How to set up certificate pinning
  • POST/user/{userID}/certificate-pinned
post

Manage the url notification filters for a user.

Path parameters
userIDintegerRequired
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
Responses
200
Manage the url notification filters for a user.
application/json
400
This is how the error response looks like for 4XX response codes
application/json
post
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
  }
}
post

Pin the certificate chain.

Path parameters
userIDintegerRequired
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
Responses
200
This endpoint allow you to pin the certificate chains to your account. These certificate chains are used for SSL validation whenever a callback is initiated to one of your https callback urls.
application/json
400
This is how the error response looks like for 4XX response codes
application/json
post
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
}