Request Response
Last updated
Was this helpful?
Last updated
Was this helpful?
Get all RequestResponses for a MonetaryAccount.
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
Get the details for a specific existing RequestResponse.
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
Update the status to accept or reject the RequestResponse.
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
The status of the RequestResponse. Can be ACCEPTED, PENDING, REJECTED, REFUND_REQUESTED, REFUNDED or REVOKED.
When the request is accepted on a monetary account with a different currency, a quote is expected to convert.
The id of the Request Response.
The timestamp when the Request Response was created.
The timestamp when the Request Response was last updated (will be updated when chat messages are received).
The timestamp of when the RequestResponse was responded to.
The timestamp of when the RequestResponse expired or will expire.
The timestamp of when a refund request for the RequestResponse was claimed.
The timestamp of when the RequestResponse was refunded.
The id of the MonetaryAccount the RequestResponse was received on.
The description for the RequestResponse provided by the requesting party. Maximum 9000 characters.
The minimum age the user accepting the RequestResponse must have.
Whether or not an address must be provided on accept.
The type of the RequestInquiry. Can be DIRECT_DEBIT, DIRECT_DEBIT_B2B, IDEAL, SOFORT or INTERNAL.
The subtype of the RequestInquiry. Can be ONCE or RECURRING for DIRECT_DEBIT RequestInquiries and NONE for all other.
The URL which the user is sent to after accepting or rejecting the Request.
The credit scheme id provided by the counterparty for DIRECT_DEBIT inquiries.
The mandate id provided by the counterparty for DIRECT_DEBIT inquiries.
Recommended registration action after IdealIssuerTransaction from iDEAL issuer transaction.
The whitelist id for this action or null.
The ID of the latest event for the request.
The ID of the monetary account this user prefers to pay the request from.