Chapter 4 Webhooks / Callbacks
On top of our regular Callbacks (Webhooks) documentation there are some special options for User Provision users.
NotificationUrl Object:
target_url
Your configured webhook endpoint URL
category
Notification category (e.g., USER_INFORMATION_INQUIRY)
event_type
Specific event type within the category
object
The actual object that triggered the notification
UserInformationInquiry Object:
id
Unique identifier for the inquiry
created
Timestamp when the inquiry was created
updated
Timestamp when the inquiry was last updated
user_id
ID of the user for whom the inquiry was created
title
Title of the inquiry (e.g., "We need additional information")
subtitle
Subtitle explaining the inquiry purpose
purpose
Purpose of the inquiry (e.g., COMPLIANCE_TRANSACTION_MONITORING)
all_entry
Array of inquiry entries with specific information requests
assistant_conversation
Conversation details for user interaction
UserInformationInquiryEntry Object:
id
Unique identifier for the inquiry entry
type
Type of information requested (e.g., USER_PERSON_SOURCE_OF_FUND)
status
Status of the entry (e.g., PENDING)
all_data_submitted
Array of data submitted by the user
assistant_conversation
Conversation context for this specific entry
context
Additional context information
reject_reason
Reason for rejection (if applicable)
Webhook Body Example (PARTNER_USER_PROVISION):
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.
Removing callbacks
To remove callbacks for an object, send a POST request to the notification_filters endpoint with a JSON request body with an emtpy list.
Retry Mechanisms
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.
Listing of failed callbacks
After the sixth attempt of callback executing, the failed entry is stored and can be listed by UserApiKey
* the category & object_id can be used to verify if the callback has failed and should be retried
** the id of the NotificationFilterFailure object should be used to trigger the retry
Retry of failed callbacks
Copy
* multiple ids can be given in the same field, comma separated. Maximum of 100 ids are allowed
** response will be empty with code 200 (OK)
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.pemPOSTthe certificate to thecertificate-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.
Last updated
Was this helpful?