Mock sample for your project: Account and Transaction API Specification

Swagger for Payment Initiation API Specification

Swagger for Event Notification API Specification - TPP Endpoints

Swagger for Confirmation of Funds API Specification

Latest Swagger specification for OpenData

Portfolio Optimizer is a Web API to optimize the composition of investment portfolios (collection of financial assets such as stocks, bonds, ETFs, crypto-currencies) using modern portfolio theory-like algorithms (mean-variance, etc.).
API General Information
Portfolio Optimizer is based on REST for easy integration, uses JSON for the exchange of data and uses the two most common HTTP verbs (GET, POST) to represent the actions.
Portfolio Optimizer is also as secured as a Web API could be:
256-bit HTTPS Encryption
No usage of cookies
No usage of personal data
API Headers
The following HTTP header(s) are required when calling Portfolio Optimizer endpoints:
Content-type: application/json
This header specifies that the data provided in input to the endpoint is in JSON format
The following HTTP header(s) are optional when calling Portfolio Optimizer endpoints:
X-API-Key:
This header enables authenticated users to provide their private API key in order to benefit from higher API limits
API Key
Portfolio Optimizer is free to use, but not free to run.
In order to obtain an API key and benefit from higher API limits, a small participation to Portfolio Optimizer running costs is required.
This participation takes the form of coffee(s), with one coffee = one month of usage.
Notes:
> * Please make sure not to expose your API key publicly!
API Limits
Portfolio Optimizer comes with fairly reasonable API limits.
For anonymous users:
The API requests are restricted to a subset of all the available endpoints and/or endpoints features
The API requests are limited to 1 request per second for all the anonymous users combined, with concurrent requests rejected
The API requests are limited to 1 second of execution time
The API requests are limited to 20 assets, 100 portfolios, 500 series data points and 5 factors
For authenticated users with an API key:
The API requests have access to all the available endpoints and endpoints features
The API requests are limited to 10000 requests per 24 hour per API key, with concurrent requests queued
The API requests are limited to 2.5 seconds of execution time
The API requests are limited to 100 assets, 500 portfolios, 2500 series data points and 25 factors
> Notes:
> * It is possible to further relax the API limits, or to disable the API limits alltogether; please contact the support for more details.
> * Information on the API rate limits are provided in response messages HTTP headers x-ratelimit-*:
> * x-ratelimit-limit-second, the limit on the number of API requests per second
> * x-ratelimit-remaining-second, the number of remaining API requests in the current second
> * x-ratelimit-limit-minute, the limit on the number of API requests per minute
> * ...
API Regions
Portfolio Optimizer servers are located in Western Europe.
> Notes:
> * It is possible to deploy Portfolio Optimizer in other geographical regions, for example to improve the API latency; please contact the support for more details.
API Response Codes
Standard HTTP response codes are used by Portfolio Optimizer to provide details on the status of API requests.
| HTTP Code | Description | Notes |
| --------- | ----------- | ----- |
| 200 | Request successfully processed | - |
| 400 | Request failed to be processed because of incorrect content | The response message body contains information on the incorrect content |
| 401 | Request failed to be processed because of invalid API key | - |
| 404 | Request failed to be processed because of non existing endpoint | The requested endpoint might exist, but needs to be accessed with another HTTP method (e.g., POST instead of GET) |
| 429 | Request failed to be processed because of API limits violated | The response message HTTP headers x-ratelimit-* contain information on the API limits |
| 500 | Request failed to be processed because of an internal error | Something went wrong on Portfolio Optimizer side, do not hesitate to report the issue |
| 502 | Request failed to be processed because of a temporary connectivity error | Something went wrong on Portfolio Optimizer side, please check the API status and do not hesitate to report the issue |
API Status
Portfolio Optimizer is monitored 24/7 by UptimeRobot.
Support
For any issue or question about Portfolio Optimizer, please do not hesitate to contact the support.

Ntropy Transaction API for transaction classification & management
Contact Support:
Name: API Support
Email: [email protected]

Introduction
Taxrates.io is a global tax rate service that automates the management of monitoring tax rates changes in 181 countries. We monitor over 14,000 US sales tax, VAT, GST rates for you and make updates via our API so you always have the most update tax rates.
You can use Taxrates.io as a virtual sandbox where we provide you with 30 days free trial.
Countries
We currently support the following countries around the world. If you would like to request the addition of a new country, please email us at [email protected]
Afghanistan Gambia Nicaragua
Albania Georgia Niger
Andorra Germany Nigeria
Angola Ghana North Korea
Antigua and Barbuda Greece Norway
Argentina Grenada Pakistan
Armenia Guam Palestine
Aruba Guatemala Panama
Australia Guinea Papua New Guinea
Austria Guyana Paraguay
Azerbaijan Haiti Peru
Bahamas Honduras Philippines
Bangladesh Hungary Poland
Barbados Iceland Portugal
Belarus India Puerto Rico
Belgium Indonesia Republic of the Congo
Belize Iran Romania
Benin Ireland Russian Federation
Bhutan Isle of Man Rwanda
Bolivia Israel Samoa
Bonaire Italy Senegal
Bosnia and Herzegovina Japan Serbia
Botswana Jersey Seychelles
Brazil Jordan Sierra Leone
Bulgaria Jordan Singapore
Burkina Faso Kazakhstan Slovakia
Burundi Kenya Slovenia
Cambodia Kiribati Solomon Islands
Cameroon Kosovo Somalia
Cape Verde Kyrgyzstan South Africa
Central African Republic Laos South Korea
Chad Latvia South Sudan
Chile Lebanon Spain
China Lesotho Sri Lanka
Columbia Liberia St Lucia
Comoros Liechtenstein Sudan
Cook Islands Lithuania Suriname
Costa Rica Luxembourg Swaziland
Cote d'Ivoire Macedonia Sweden
Croatia Madagascar Switzerland
Cuba Malawi Tahiti
Curacao Malaysia Taiwan
Cyprus Maldives Tajikistan
Czech Republic Mali Tanzania
Democratic Republic of the Congo Malta Thailand
Denmark Mauritania Togo
Djbouti Mauritius Tonga
Dominica Mexico Trinidad and Tobago
Dominican Republic Micronesia Tunisia
Ecuador Moldova Turkmenistan
Egypt Monaco Tuvalu
El Salvador Mongolia Uganda
Equatorial Guinea Montenegro Ukraine
Eritrea Morocco United Kingdom
Estonia Mozambique United States
Ethiopia Myanmar Uruguay
Fiji Namibia Vanuatu
Finland Nepal Venezuela
France Netherlands Vietnam
Gabon New Zealand Yemen
Products codes
The Taxrates.io API’s provides product-level tax rates for a subset of product codes. These codes are to be used for products that are either exempt from tax in some jurisdictions or are taxed at reduced rates.
We will be expanding support for additional, less common categories over time. If you would like to request the addition of a new product category, please email us at [email protected]
Please select a product code/s when making a request to the Taxrates.io API
Product code Product Description
C010 Services which are not subject to a service-specific tax
C011 Software - Downloaded
C012 Books - Downloaded
C011 Music - Downloaded
C011 Movies/Digital Video - Downloaded
C011 Other Electronic Goods - Downloaded
C011 Streaming Music/Audio Services new
C011 Streaming Video Services new
C018 Software as a Services, Generally (Remote Access to Hosted Software)
C018 Remote Access to Hosted Software - Personal Use
C018 Remote Access to Hosted Software - Business Use
C021 Remote Access to Hosted Business Custom Applications
C021 Personal Cloud Storage/Backup
C021 Business Cloud Storage/Backup
C021 Business Data Warehouses
C022 Infrastructure as Service, Generally
C022 Ecommerce Site/Webserver Hosting
C022 Provision of Virtual Computing Capacity
C022 Software - package or canned program
C022 Software - modifications to canned program
C022 Software - custom programs - material
C022 Software - custom programs - professional serv.
C022 Information services
C022 Data processing services
C022 Mainframe computer access and processing serv.
C022 Online Data processing services
Filtering
When calling the API endpoints you can use 'filter' parameters to get tax rate for the selected type. You can get the following tax types (Each tax rate will always have one of following types)
US Sales tax Rates
CombinedRate
StateRate
CountyRate
CityRate
SpecialRate
We recommend using Postman when discovering our API. Happy using!
Rate Limiting
We limit API requests.
If you’re exceeding this rate and encountering 429 errors, review the following:
Only make requests in states / regions where you have enabled.
Cache responses if the order details haven’t changed since the last calculation at checkout.
Errors
The Taxrates.io API uses the following error codes:
Code Error Message
400 Bad Request – Your request format is bad.
401 Unauthorized – Your API key is wrong.
404 Not Found – The specified resource could not be found.
405 Method Not Allowed – You tried to access a resource with an invalid method.
429 Too Many Requests – You’re requesting too many resources! Slow down!
500 Internal Server Error – We had a problem with our server. Try again later.
503 Service Unavailable – We’re temporarily offline for maintenance. Try again later.
Verify your API token is correct and make sure you’re correctly setting the Authorization header.
If you’re still not sure what’s wrong, contact us and we’ll investigate.
Changelog
Stay on top of new developer-facing features, accuracy improvements, and bug fixes for our API. Have a request? Encounter an issue? We’d love to hear your feedback.
Contact Support:
Name: [email protected]

Swagger for Account and Transaction API Specification

This is a Billingo API v3 documentation. Our API based on REST software architectural style. API has resource-oriented URLs, accepts JSON-encoded request bodies and returns JSON-encoded responses. To use this API you have to generate a new API key on our site. After that, you can test your API key on this page.

UPDATE: We have released a beta version of the new bunq API documentation.
NOTICE: We have updated the sandbox base url to https://public-api.sandbox.bunq.com/v1/. Please update your applications accordingly. Check here: for more info.
PSD2 NOTICE: The second Payment Services Directive (PSD2) may affect your current or planned usage of our public API, as some of the API services are now subject to a permit. Please be aware that using our public API without the required PSD2 permit is at your own risk and take notice of our updated API Terms and Conditions on for more information.
Introduction
Welcome to bunq!
The bunq API is organised around REST. JSON will be returned in almost all responses from the API, including errors but excluding binary (image) files.
Please configure your implementation to send its API requests to https://public-api.sandbox.bunq.com/v1/
There is a version of the Android app that connects to the bunq Sandbox environment. To create accounts for the Sandbox app, please follow the steps in the Android Emulator section.
Getting started
Before you start sending API requests, you need to get an API key and activate it. API activation happens when you install the API key and link your IP address and device to it (create an API context). The steps below will guide you through what you need to do to start sending custom API requests.
Here is an overview of what you can use to get started with the bunq API:
Create an API key. You can do it either in our developer portal or in the bunq app (Profile → Security & Settings → Developers → API keys). If you want to test our sandbox first, our bunq Developer is the best place to start.
Register a device. A device can be a phone (private), computer or a server (public). You can register a new device by using the POST /installation and POST /device-server calls. This will activate your API key. You only need to do this once.
Open a session. Sessions are temporary and expire after the auto-logout time set for the user account. It can be changed by the account owner in the bunq app.
Make your first call!
bunqAPIcontext
Versioning
Developments in the financial sector, changing regulatory regimes and new feature requests require us to be flexible. This means we can iterate quickly to improve the API and related tooling. Therefore, we have chosen not to attach any version numbers to the changes just yet.
We will inform you in a timely manner of any important changes we make before they are deployed on together.bunq.com. You can also subscribe to our API newsletter to make sure you don't miss any important updates.
OAuth
What is OAuth?
OAuth 2.0 is a protocol that will let your app connect to bunq users in a safe and easy way. Please be aware that if you will gain access to the account information of other bunq users or initiate a payment for them, you may require a PSD2 permit.
Get started with OAuth for bunq
To initiate authorization into the bunq user accounts, you need to create an OAuth Client and register at least 1 redirect URL for it.
You can have 1 OAuth Client at a time. Reuse your OAuth credentials for every authorization request.
The list of steps below will help you to get started:
Register an OAuth Client by creating an app in bunq Developer.
Add one or more Redirect URLs.
Get your client_id and secret from your app information tab in bunq Developer.
Redirect your users to the OAuth authorization request URL.
If the user accepts the authorization request, they will be redirected to the previously specified redirect_uri with an authorization code parameter.
Use the token endpoint to exchange the authorization code for an access_token.
Use the access_token as a normal API Key. Open a session or use our SDKs to get started.
You can set up an OAuth Client and add redirect URLs to it using the dedicated endpoints too. Follow the flow below to do it programmatically.
ℹ️ As a PSD2 user, you cannot log in to the bunq app. You need to follow the flow below to register an OAuth Client for your application.
bunqOAuthcredentials
What can my apps do with OAuth?
We decided to launch OAuth with a default permission that allows you to perform the following actions:
read and create Monetary Accounts;
read Payments & Transactions;
create Payments between Monetary Accounts of the same user;
create Draft-Payments (the user will need to approve the payment using the bunq app);
assign a Monetary account to a Card;
read, create and manage Cards;
read and create Request-Inquiries
read Request-Responses.
As a PSD2-licensed developer, you are limited to the permission scopes of your role.
Authorization request
Your web or mobile app should redirect users to the following URL:
https://oauth.bunq.com/auth
The following parameters should be passed:
response_type - bunq supports the authorization code grant, provide code as parameter (required)
client_id - your Client ID, get it from the bunq app (required)
redirect_uri - the URL you wish the user to be redirected after the authorization, make sure you register the Redirect URL in the bunq app (required)
state - a unique string to be passed back upon completion (optional)
Use https://oauth.sandbox.bunq.com/auth in the sandbox environment.
Authorization request example:
Android Emulator
In case you do not own an Android device on which you can run our Sandbox app for end-to-end testing, you can set up an emulator to run the bunq Sandbox app for Android.
Things you will need
The bunq Sandbox App APK that's optimised for emulating;
Android Studio.
Starting the Android Virtual Device (AVD) Manager
Open Android Studio.
From the top menu, select “Tools” > "Android" > "AVD Manager".
Setting up a new virtual device
Start the wizard by clicking on "+ Create Virtual Device".
Select a device (recommendation: "Pixel 5.0" or "Nexus 6") and press "Next".
Select an x86 system image (recommendation: Nougat, API Level 25, Android 7.1.1 with Google APIs) and press "Next". The image needs to have Google Play Services 10.0.1 or higher.
In the bottom left corner, select "Show Advanced Settings".
Scroll to "Memory and Storage".
Change "Internal Storage" to "2048 MB".
Change "SD card" to "200 MB".
Press "Finish".
Starting the virtual device
On the right side under "Actions", select the green "Play" button.
Wait for the device to boot, this may take a few minutes.
Installing the bunq Sandbox App APK
Open the command line.
Navigate to your Android SDK platform tools directory (e.g. cd ~/Library/Android/sdk/platform-tools on macOS).
Make sure that the virtual device is started and has fully booted.
Run ./adb install ~/Downloads/bunq-android-sandboxEmulator-public-api.apk, this may take a few minutes, and should finish with "Success".
Creating an account or logging in
Create a sandbox account in the developer portal.
Log in to the sandbox app using the sandbox user credentials.
ℹ️ You will be asked to verify your phone number when you open the app for the first time. Sandbox does not send actual SMS messages. Enter any valid phone number and use the default verification code 992266.
If you couldn't generate a sandbox account in the developer portal, use Tinker:
Install Tinker.
Run tinker/user-overview to create a sandbox account. The output of the command will include the login credentials for the sandbox account.
⚠️ NOTE: It is not possible to create accounts using the regular signup in the app, bunq is not reviewing Sandbox applications.
Moving to Production
Have you tested your bunq integration to the fullest and are you now ready to introduce it to the world? Then the time has come to move it to a production environment!
To get started you'll need some fresh API keys for the production environment, which you can create via your bunq app. You can create these under "Profile" by tapping the "Security" menu. We do, however, highly recommend using a standard API Key instead of a Wildcard API Key. The former is significantly safer and it protects you from intrusions and possible attacks.
There's only a few things to do before your beautiful bunq creation can be moved to production. You're going to have to change your API Key and redo the sequence of calls to open a session.
The bunq Public API production environment is hosted at https://api.bunq.com.
Do you have any questions or remarks about the process, or do you simply want to show off with your awesome creations? Don't hesitate to drop us a line on together.bunq.com.
Please be aware that if you will gain access to account information of other bunq users or initiate a payment for them, you maybrequire a PSD2 permit.
Quickstart: Opening a Session
Goal
So, you want to start using the bunq API, awesome! To do this, you have to open a session in which you will be making those calls.
Getting an API key
To connect to the API, you have to make sure you have received an API key.
For production:
create an app in the developer portal, or
generate it in the bunq app (Profile → Security & Settings → Developers → API keys).
For sandbox
You can use one of the following ways:
create a sandbox user in the developer portal;
generate an API key in the sandbox app (Profile → Security & Settings → Developers → API keys);
get an API key from Tinker;
run a cURL request: curl https://public-api.sandbox.bunq.com/v1/sandbox-user-person -X POST --header "Content-Type: application/json" --header "Cache-Control: none" --header "User-Agent: curl-request" --header "X-Bunq-Client-Request-Id: $(date)randomId" --header "X-Bunq-Language: nlNL" --header "X-Bunq-Region: nlNL" --header "X-Bunq-Geolocation: 0 0 0 0 000". Use sandbox-user-company to generate a business user.
Note that production API key is only usable on production and sandbox key is only usable on sandbox. Sandbox key has a sandbox_ prefix while production key does not have any noticeable prefixes.
Call sequence
The calls you need to perform to set up a session from scratch are the following:
1. POST installation
Each call needs to be signed with your own private key. An Installation is used to tell the server about the public key of your key pair. The server uses this key to verify your subsequent calls.
Start by generating a 2048-bit RSA key pair. You can find examples by looking at the source code of the sdk's located at github.
Headers
On the headers page you can find out about the mandatory headers. Take care that if you are in the sandbox environment, you set an Authorization header. Specific to the POST /installation call, you shouldn't use the X-Bunq-Client-Authentication or the X-Bunq-Client-Signature headers.
Body
Post your public key to the Installation endpoint (use \n for newlines in your public key).
Response
Save the Installation token and the bunq API's public key from the response. This token is used in the Authentication header to register a DeviceServer and to start a SessionServer. The bunq API's public key should be used to verify future responses received from the bunq API.
2. POST device-server
Further calls made to the server need to come from a registered device. POST /device-server registers your current device and the IP address(es) it uses to connect to the bunq API.
Headers
Use the token you received from POST /installation in the X-Bunq-Client-Authentication header. Make sure you sign your call, passing the call signature in X-Bunq-Client-Signature header.
Body
For the secret, use the API key you received. If you want to create another API key, you can do so in the bunq sandbox app (or production app for the production environment). Login, go to Profile > Security and tap 'API keys'. The freshly created API key can be assigned to one or multiple IP addresses using POST device-server within 4 hours before becoming invalid. As soon as you start using your API key, it will remain valid until the next sandbox reset. For the secret, use the API key you received.
3. POST session-server
To make any calls besides installation and device-server, you need to open a session.
Headers
Use the token you received from POST /installation in the X-Bunq-Client-Authentication header. Make sure you sign your call, passing the call signature in X-Bunq-Client-Signature header.
Body
For the secret, use the API key you received.
Response
The token received in the response to POST /session-server should be used to authenticate your calls in this session. Pass this session's token in the X-Bunq-Client-Authentication header on every call you make in this session.
Quickstart: Payment Request
Goal
You want to offer bunq payments on a website or in an application.
Scenario
In this use case the consumer and the merchant both have a bunq account. The consumer wants to pay with bunq and enters their alias in the bunq payment field at checkout. The merchant sends the request for payment to the consumer when the consumer presses enter. The consumer agrees to the request in the bunq mobile app and the merchant has immediate confirmation of the payment. Please be aware that if you will gain access to account information of other bunq users or initiate a payment for them, you require a PSD2 permit.
Before you start
Make sure that you have opened a session and that for any call you make after that, you pass the session’s token in the X-Bunq-Client-Authentication header.
Call Sequence
The consumer is at checkout and selects the bunq payment method. This would be a logical time to open a session on the bunq server.
1. LIST monetary-account
When a request for payment is accepted, the money will be deposited on the bank account the request for payment is connected to. Let’s start by finding all your available bank accounts. Pick one of them to make the request for payment with and save its id.
2. POST monetary-account attachment (optional)
Optionally, you can attach an image to the request for payment.
Headers
Make sure you set the Content-Type header to match the MIME type of the image. It’s also required you pass a description of the image via the X-Bunq-Attachment-Description header.
Body
The payload of this request is the binary representation of the image file. Do not use any JSON formatting.
Response
Save the id of the posted attachment. You’ll need it to attach it to the request for payment.
3. POST request-inquiry
Next, create a request inquiry. A request inquiry is the request for payment that your customer can respond to by accepting or rejecting it.
Body
Pass the customer’s email address, phone number or IBAN in the counterpartyalias. Make sure you set the correct type for the alias, depending on what you pass. When providing an IBAN, a name of the counterpartyalias is required. You can provide the id of the created attachment.
Response
You will receive the id of the created request inquiry in the response. Save this id. You will need it to check if the customer has responded to the request yet.
4. GET request-inquiry
After you’ve sent the request for payment, its status can be checked.
Response
When the status is ACCEPTED, the customer has accepted and paid the request, and you will have received the money on the connected monetary account. If the status is REJECTED, the customer did not accept the request.
Quickstart: Create a Tab payment
Goal
You will create a tab that can be paid once by a single user, a so called TagUsageSingle, and explore three different ways to make the Tab visible to your customers:
QR code from the CashRegister
QR code from the Tab.
Before you start
Make sure that you have opened a session and that for any call you make after that, you pass the session’s token in the X-Bunq-Client-Authentication header.
Call sequence
1. POST attachment-public
Start by creating an attachment that will be used for the avatar for the cash register.
Header
Make sure you set the Content-Type header to match the MIME type of the image. It is also required you pass a description of the image via the X-Bunq-Attachment-Description header.
Body
The payload of this request is the binary representation of the image file. Do not use any JSON formatting.
Response
Save the uuid of the posted attachment. You'll need it to create the avatar in the next step.
2. POST avatar
Make an avatar using the public attachment you've just created.
Body
The payload of this request is the uuid of the attachment public.
Response
In response, you’ll receive the UUID of the avatar created using the attachment. Save this UUID. You’ll use it as the avatar for the cash register you're about to create.
3. LIST monetary-account
Get a listing of all available monetary accounts. Choose one, and save the id of the monetary account you want your cash register to be connected to. Each paid tab for the cash register will transfer the money to this account.
4a. POST cash-register
Create a cash register. Use the id of the monetary account you want to connect the cash register to in the URL of the request.
Body
In the body provide the uuid of the avatar you created for this cash register. Also make sure to provide a unique name for your cash register. Set the status to PENDING_APPROVAL.
Response
The response contains the id of the cash register you created. Save this id. You will need it to create subsequent tabs and tab items.
4b. Wait for approval
On the production environment, a bunq admin will review and approve your cash register. In the sandbox environment, your cash register will be automatically approved.
5. POST tab-usage-single
Create a new tab that is connected to your cash register. Use the id of the cash register you want to connect this tab to in the URL of your request.
Body
Give the tab a name in merchant_reference. Create the tab with status OPEN, and give the tab a starting amount. You can update this amount later.
Response
The response contains the uuid of the tab you created.
6. POST tab-item (optional)
You can add items to a tab. For instance, if a customer will be paying for multiple products via this tab, you can decide to add an item for each of these. Adding items to a tab is optional, and adding them will not change the total amount of the tab itself. However, if you've added any tab items the sum of the amounts of these items must be equal to the totalamount of the tab when you change its status to WAITINGFOR_PAYMENT.
7. PUT tab-usage-single
Update the status of the tab to WAITINGFORPAYMENT if you want the costumer to pay the tab, and you're done adding any tab items. You can use this request to make the tab visible for your costumers.
Visibility
To decide how you are going to make your tab visible, pass a visibility object in the payload.
Setting cashregisterqr_code to true will connect this tab to the QR code from the cash register. If this cash register does not have a QR code yet, one will be created. Only one Tab can be connected to the cash register’s QR code at any given time.
Setting tabqrcode to true will create a QR code specifically for this tab. This QR code can not be linked to anything else.
Quickstart: Create a TransferWise payment
Goal
You want to send a payment in currency other than euro outside the SEPA zone.
Before you start
Make sure that you have opened a session and that for any call you make after that, you pass the session’s token in the X-Bunq-Client-Authentication header.
ℹ️ bunq relies on TransferWise for international, so you need to create a TransferWise account linked to a bunq account to be able to create international transfers. You can do it either from the bunq app or using our API as described below.
Get the up-to-date exchange rate (optional)
You might want to check the latest currency exchange rate before making a transfer. Here’s how you can do it using the bunq API:
Check the list of supported currencies via GET /user/{userID}/transferwise-currency. Copy the needed currency code.
Create a temporary quote for the currency of your choice via POST /user/{userID}/transferwise-quote-temporary.
ℹ️ A quote is the exchange rate at the exact timestamp. Temporary quotes carry solely informative value and cannot be used for creating a transfer.
Read the temporary quote via GET /user/{userID}/transferwise-quote-temporary/{transferwise-quote-temporaryID}.
Create a TransferWise account
You need a TransferWise account linked to your bunq account to make TransferWise payments via the bunq API. Create one via POST /user/{userID}/transferwise-user, and save its ID.
ℹ️ You cannot use an existing TransferWise account.
Create a quote
Create a quote via POST /user/{userID}/transferwise-quote and save its ID.
ℹ️ Use amounttarget to indicate the sum the recipient must get. Amountsource, on the other hand, will indicate the sum you want to send, but it will not necessarily be the final sum the recipient gets.
ℹ️ Quotes are valid for 30 minutes so if you do not manage to create a transfer within this time, you will need to create another quote.
Get the exchange rate by reading the quote via GET /user/{userID}/transferwise-quote/(transferwise-quoteID).
Create a recipient
If you have sent money via the TransferWise account linked to your bunq account, you can reuse the recipients. You can list their IDs via GET /user/{userID}/transferwise-quote/{transferwise-quoteID}/transferwise-recipient.
To create a new, previously unused recipient, follow these steps:
Retrieve the fields required for creating the recipient as the requirements vary for the type of recipient in each country. Iterate sending the following request pair till there are no more required fields:
GET /user/{userID}/transferwise-quote/{transferwise-quoteID}/transferwise-recipient-requirement
POST /user/{userID}/transferwise-quote/{transferwise-quoteID}/transferwise-recipient-requirement
Create a recipient account using the final request body from the previous step with POST /user/{userID}/transferwise-quote/{transferwise-quoteID}/transferwise-recipient-requirement
Create a transfer
Finally, having both the quote ID and the recipient ID, you can create a transfer. 🎉
Check if there are any additional transfer requirements via POST /user/{userID}/transferwise-quote/{transferwise-quoteID}/transferwise-transfer-requirement.
Create a transfer via POST /user/{userID}/transferwise-quote/{transferwise-quoteID}/transferwise-transfer. You need to specify the ID of the monetary account from which you want the payment to be made.
Quickstart: Downloading attachments
Goal
Export receipts and invoices attached to payments to your application.
The scenario you want to achieve
The bunq user has accepted the authorization request and your application can read the bunq user’s account information.
Your application imports all the transactions and attachments.
The bunq user sees the transactions matched with the receipts and invoices in your application.
Before you start
Make sure that you have opened a session
Make sure you pass the session Token in the X-Bunq-Client-Authentication header in all the following requests of the session.
Call sequence
List the payments of the user via GET /user/{userID}/monetary-account/{monetary-accountID}/payment.
Check if the payments have attachments via GET /user/{userID}/monetary-account/{monetary-accountID}/payment/{paymentID}/note-attachment. Save the attachment IDs.
Export the raw content of the attachments via GET /user/{userID}/attachment/{attachmentID}/content.
HINT: You can use callbacks to make sure you don’t miss anything happening on the bunq account.

These endpoints are specific to Xero Files API

Latest Swagger specification for OpenData

Authentication is required to access all methods of the API. Enter username and password.
Credentials are automatically set as you type.

Summary
The Swiss NextGen API is based on the NextGenPSD2 Framework Version 1.3.4 of the Berlin Group which offers a modern, open, harmonised and interoperable set of
Application Programming Interfaces (APIs) as the safest and most efficient way to provide data securely.
The NextGen Framework reduces XS2A complexity and costs, addresses the problem of multiple competing standards
in Europe and, aligned with the goals of the Euro Retail Payments Board,
enables European banking customers to benefit from innovative products and services ('Banking as a Service')
by granting TPPs safe and secure (authenticated and authorised) access to their bank accounts and financial data.
The Swiss edtion refines the message formats specific to Switzerland and defines some matching examples.
The possible Approaches are:
Redirect SCA Approach
(Not recommended by obp.ch community) OAuth SCA Approach
(Not recommended by obp.ch community) Decoupled SCA Approach
(Not recommended by obp.ch community) Embedded SCA Approach without SCA method
(Not recommended by obp.ch community) Embedded SCA Approach with only one SCA method available
(Not recommended by obp.ch community) Embedded SCA Approach with Selection of a SCA method
Not every message defined in this API definition is necessary for all approaches.
Furthermore this API definition does not differ between methods which are mandatory, conditional, or optional
Therefore for a particular implementation of a compliant API it is only necessary to support
a certain subset of the methods defined in this API definition.
**Please have a look at the implementation guidelines if you are not sure
which message has to be used for the approach you are going to use.**
Some General Remarks Related to this version of the OpenAPI Specification:
This API definition is based on the Implementation Guidelines of the Berlin Group API.
It is not a replacement in any sense.
The main specification is (at the moment) always the Implementation Guidelines of the Berlin Group API.
This API definition contains the REST-API for requests from the PISP to the ASPSP.
This API definition contains the messages for all different approaches defined in the Implementation Guidelines.
According to the OpenAPI-Specification [https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md]
"If in is "header" and the name field is "Accept", "Content-Type" or "Authorization", the parameter definition SHALL be ignored."
The element "Accept" will not be defined in this file at any place.
The elements "Content-Type" and "Authorization" are implicitly defined by the OpenApi tags "content" and "security".
There are several predefined types which might occur in payment initiation messages,
but are not used in the standard JSON messages in the Implementation Guidelines.
Therefore they are not used in the corresponding messages in this file either.
We added them for the convenience of the user.
If there is a payment product, which needs these fields, one can easily use the predefined types.
But the ASPSP need not to accept them in general.
**We omit the definition of all standard HTTP header elements (mandatory/optional/conditional)
except they are mentioned in the Implementation Guidelines.**
Therefore the implementer might add these in his own realisation of a comlient API in addition to the elements defined in this file.
General Remarks on Data Types
The Berlin Group definition of UTF-8 strings in context of the API have to support at least the following characters
a b c d e f g h i j k l m n o p q r s t u v w x y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9
/ - ? : ( ) . , ' +
Space

The Assets API exposes fixed asset related functions of the Xero Accounting application and can be used for a variety of purposes such as creating assets, retrieving asset valuations etc.