Mock sample for your project: Tradeworks API

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.

Introduction
The Business Registries API is built on HTTP. The API is RESTful. It has predictable resource URIs.
The API is documented in OpenAPI format.
In addition to the standard OpenAPI syntax we use a few
vendor extensions.
Overview
The following sections describe the resources that make up the Business Registries REST API.
Current Version
By default, all requests to https://api.abr.ato.gov.au receive the v1 version of the REST API. We encourage you to explicitly request this version via the Accept header.
Accept: application/vnd.abr-ato.v1+json
Schema
All API access is over HTTPS, and accessed from https://api.abr.ato.gov.au. All data is sent and received as JSON. Blank fields are included.
All dates use the ISO 8601 format:
YYYY-MM-DD
For example: 2017-07-01 (the 1st of July 2017)
All timestamps use the ISO 8601 format:
YYYY-MM-DDTHH:MM:SSZ
For example: 2017-07-01T11:05:06+10:00
Timezones
Some requests allow for specifying timestamps or generate timestamps with time zone information. We apply the following rules, in order of priority, to determine timezone information for API calls.
Explicitly provide an ISO 8601 timestamp with timezone information
For API calls that allow for a timestamp to be specified, we use that exact timestamp.
For example: 2017-07-01T11:05:06+10:00
Pagination
Information about pagination is provided in the Link header.
For example:
Link:; rel="next",; rel="last"
rel="next" states that the next page is page=2. This makes sense, since by default, all paginated queries start at page 1. rel="last" provides some more information, stating that the last page of results is on page 34. Accordingly, we have 33 more pages of information that we can consume.
Parameters
Many API methods take optional parameters:
GET /individuals/1234/addresses/?addressType='Mailing'
In this example, the '1234' value is provided for the :partyId parameter in the path while :addressType is passed in the query string.
For POST, PATCH, PUT, and DELETE requests, parameters not included in the URL should be encoded as JSON with a Content-Type of 'application/json'.
Metadata
The API provides metadata services that you can use to discover information about the classifcation schemes and values used by the Registry.
For example:
GET /classifications/roles
Sample response:
[
{
"id": "123e4567-e89b-12d3-a456-426655440001",
"role": "Director",
"roleDescription": "An individual responsible for managing a company's ...",
"relationship": "Directorship",
"reciprocalRole": "Company",
"reciprocalRoleDescription": "An incorporated legal entity."
},
{
...
}
]
Root Endpoint
You can issue a GET request to the root endpoint (also known as the service root) to get all the endpoint categories that the REST API supports:
curl https://api.abr.ato.gov.au
Authentication
The Business Registries API supports API Key authentication.
When you sign up for an account, you are given your first API key. You can generate additional API keys, and delete
API keys (as you may need to rotate your keys in the future). You authenticate to the Business Registries API by
providing your secret key in the request header.
Note: Some requests will return 404 Not Found, instead of 403 Permission Denied. This is to prevent the
accidental leakage of information to unauthorised users.

Currency Authority: Exchange Rate of 1453 country currencies and crypto currencies

Introduction
The Xero Accounting API is a RESTful web service and uses the OAuth (v1.0a) protocol to authenticate 3rd party applications. The Accounting API exposes accounting and related functions of the main Xero application and can be used for a variety of purposes such as creating transactions like invoices and credit notes, right through to extracting accounting data via our reports endpoint.

Swagger for Payment Initiation API Specification

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.

This is an API designed for merchants who are using SpectroCoin services and wishes to integrate them locally.

Swagger for Confirmation of Funds API Specification