Tradias API v2

Scroll down for code samples, example requests and responses. Select a language for code samples from the tabs above or the mobile navigation menu.

Welcome to the tradias API documentation!

Bankhaus Scheich / tradias offers the essential infrastructure and services necessary to empower institutional investors to tap into the vast potential of digital assets. Drawing from decades of accumulated expertise, Bankhaus Scheich has established itself as a prominent securities trading bank and market maker on the Frankfurt Stock Exchange. Today, this wealth of knowledge is seamlessly integrated into Bankhaus Scheich’s FinTech arm, tradias, which offers services in OTC trading and market making in FX and digital assets. The options for interaction with tradias span from trading via API, to frontend trading, and even chat trading. The digital assets supported include more than 150 cryptocurrencies, as well as tokenized assets in the secondary market.

For more about tradias and our offerings, contact info-api@tradias.de or view additional information on https://www.tradias.de/.

The API provides the functionality of subscribing to live pricing, the submitting of orders, the viewing of live and historic executions as well as the initiation and tracking of settlement requests, enabling the automation of the settlement procedure.

Subscribing to current prices, placing orders and listening to order executions is achieved by means of the WebSocket protocol. The initiation and tracking of settlement requests, the retrieval of static and historic data and the placing of bulk orders uses the REST protocol.

In this documentation we separate the endpoints into several sections: Static Data, Pricing, Trading, Historic Data and Settlement.

Features:

tradias offers more than 150 digital assets. The Instruments endpoint returns an overview of all tradeable instruments.
tradias offers post-trade settlement based on a contractually agreed trading line and collateral requirements. The settlement procedure can be automated using our Settlement API, in the section Settlement Procedure. More on the parameters for the computation of risk figures can be found in the section for the endpoint Risk Figures.
Currently all orders are executed as Fill or Kill (FoK) orders. As a result, orders are either executed in their entirety or rejected, allowing for a simple yet powerful order management.
The placing of limit orders is possible, however, only “Fill or Kill”-limit orders are currently supported. More on the execution of limit orders can be found in the section for the Orders endpoint.

The following base URLs can be used for testing and productive usage, respectively:

Testing environment: https://api.preprod.tradias.link/ or
Productive environment: https://api.tradias.link/

Using any of the endpoints provided requires the authentication by the means of a long-lived Bearer token passed in the headers of each request (REST) or connection opening (WebSocket). The Bearer token is unique for a client and should be treated with the appropriate precaution. All requests to the productive environment need to originate from whitelisted IP addresses.

You will not be able to access the productive environment from IP addresses that are not whitelisted.

About tradias

The core products:

tradias is the FinTech arm of Bankhaus Scheich Wertpapierspezialist AG, a well-established fully regulated and licenced (BaFin) trading house specialized in Market Making and OTC Bond trading with 35+ years of experience;
tradias specializes in trading digital assets as a market maker and principal OTC Desk;
tradias is one of the biggest regulated OTC trading houses within the EU;
the team operates as regulated security trading house with asset manager capabilities,
the headquarters are situated in Europe’s heart of finance, Frankfurt, Germany.
tradias aggregates global crypto liquidity and has strong capabilities to service high numbers of trades and large volumes with a low risk approach;
tradias’ platform operates 24/7 trading everywhere with a >99.9% uptime;
tradias is the leading player in servicing EUR trading pairs;
tradias focuses on a strong and robust product delivery and an excellent execution quality.
tradias offers a post-trade settlement setup, enabling efficient liquidity management lower counterparty risk;
payment-for-orderflow setup enables retail platform business;
the platform is multi-asset capable - trading cryptocurrencies, digital assets, FX and tokenized assets is possible using the same connection to the same platform.

Further services provided by tradias & Bankhaus Scheich:

Tokenization
Borrowing/Lending
Asset Management

Overview

The API can be separated into the following sections:

Static Data: using the Instruments endpoint, you can view the tradeable instruments.
- Instruments (REST)
Pricing: the prices channel can be used to get live pricing for a given tradeable instrument.
- Prices (WebSocket)
Trading: the endpoints in this section allow the placing of orders and tracking of the resulting trades. It consists of the following endpoints:
- Orders (WebSocket)
- Trades (WebSocket)
- Bulk Orders (REST)
Historic Data: the Historic Data functionality consists of the following endpoints:
- Get Orders (REST) & Get Orders By Sequence ID (REST)
- Get Trades (REST) & Get Trades By Sequence ID (REST)
Settlement: the following endpoints serve the function to initiate, track and complete settlement requests. This process covers the accumulation of trades, net settlement amounts and corresponding linking of transactions, which enables a robust, reconciled and automatable settlement procedure:
- Settlement Request (REST)
- Get Settlement Request Status (REST)
- Get Settlement Request (REST)
- Get Settlement Transactions (REST)
- Map Transaction with Settlement Request Amount (REST)

The above separation solely aims to clarify the API’s structure, as the sections may intersect depending on the final setup.

First steps

Before accessing the API, the following steps need to be completed:

Sign up with tradias You can contact us for more information and sign up via info-api@tradias.de. Subsequently, our team will reach out to you to gather all necessary information to set you up for trading.
Share required data We will need to collect some data for the configurations in our system. This may include (but is not restricted to):
- Production IP-address to be whitelisted;
- PGP public key, to exchange sensitive information (see: PGP Encryption);
- Wallet addresses;
- Bank account addresses (e.g. IBAN);
- Proof of ownership of shared addresses (wallet and bank accounts).
Acquire the API key To acquire your API key (=Bearer token), we will need your public key. Additionally, you will need our public key, it can be found in the section PGP Encryption. The steps are:
1. Save our public key.
2. Send the public key of your PGP key pair to info-api@tradias.de.
3. We will send back the encrypted secret.
4. Decrypt the message using the private key of your PGP key pair.

Authentication

After successful registration with tradias, an API Key, which is a JSON Web Token (JWT), is generated and shared using a secure method.

The system allows only one active JWT per user account at a time. By default, all tokens have an expiry date - you will be approached once it is time for your token to be renewed. A newly generated Bearer token invalidates the previous one, however, for a grace period of at least 1 week, you will be able to use both tokens at the same time, to allow for a smooth transition.

Any request to the tradias API requires a valid JWT in the headers. The example on the right illustrates the correct format for including the JWT in the headers (python syntax).

headers = {"Authorization" : f"Bearer {YOUR_JWT}"}

Request and Response Format

Messages are sent in the JSON format. The first key indicates the message’s purpose and uniquely defines the schema of the value’s content. An example is given in the column on the right.

{
    "heartbeat": {
        "header": {
            "channel": "prices",
            "timestamp": "1970-01-01T00:00:00.000000Z"
        }
    }
}

More specifically, the formats of the REST and WebSocket requests and responses look as described below.

REST endpoints

The requests always include a key called “req_header”. This header consists of two keys, a request ID: “req_id” and user data: “user_data”, these are ‘external’ references, meaning that the user has control over what values he wants to pass here and he will be able to view those values when querying the result later on. The request ID can be used as an idempotency key, meaning that when we see two requests with the same request ID, we do not process the most recent of those requests. The value for “user_data” is an object where the key-value pairs can be chosen freely by the user sending the request.
Next to these external references, we also have ‘internal’ references. Those are references, given by tradias, to the requests. For example, orders are always given an order_id and trades are given a trade_id. These IDs are chosen by tradias, so the user has no influence on their value.
When applicable, the responses always return the request ID and the user data, to help you distinguish to which request the response belongs.

WebSocket endpoints

Upon connecting with a WebSocket endpoint, a channel subscription message must be sent. The WebSocket channels serve logically separated purposes (e.g. pricing or trading) and can be unsubscribed from any time. An example of a subscription message format is shown on the right.

{
    "subscribe_price_channel": {
        "channel": "prices",
        "heartbeat_interval": 30
    }
}

Responses from WebSocket endpoints always contain a header with channel name and timestamp, along with the content of the message, which is channel-specific. An example is given on the right.

{
    "channel_subscription_confirmation": {
        "header": {
            "channel": "prices",
            "timestamp": "1970-01-01T00:00:00.000000Z"
        },
        "status": "ACTIVE",
        "heartbeat_interval": 30
    }
}

Errors and Status Codes

The status codes and errors that occur the tradias REST API responses are:

Response Code	Description
200	Successful response.
202	Successful response (Settlement & Bulk Order endpoints).
401	Unauthorized. Check your authentication.
403	Forbidden. You are not allowed to execute the desired action.
404	Not found. The information you are requesting cannot be found.
409	Duplicate request. The value for “req_id” has been used before.
422	Unprocessable content/validation error, check the validity of the passed format.
500	Internal server error. An unexpected error occurred.

Error responses from the WebSocket API consist of a message with an “error” key defining the error type and a descriptive “error_text” key containing further details. The specific possible errors in the WebSocket API are dealt with in the respective sections.

PGP Encryption

To exchange sensitive information, PGP Encryption is the preferred method. Below you can find an explanation on how to set up your key pair and encrypt and decrypt files. The PGP public key belonging to tradias can be found at the end of this section.

In the following section the setup of PGP is described using the open source GPG implementation with Kleopatra as the GUI on a Windows system. Depending on your operating system, other implementations may require slight variations in the steps described. For more details, please check https://www.gnupg.org/.

Set up a PGP key pair by following these steps:

Download the OpenPGP software: https://www.gnupg.org/download/index.html.
Make sure to install Kleopatra along with the GPG Backend (default in the gpg4win package).
Open Kleopatra and click ‘File’ -> ‘New Key Pair…’ -> ‘Create a personal OpenPGP key pair’.
Name your key and enter an email address, add a passphrase for extra security if desired. After this, you should see the name of your key pair in the list ‘Certificates’.

Share your public key by following these steps:

Open Kleopatra and go to ‘Certificates’.
Click on the key pair for which you want to share your public key.
Click ‘Export’ on the top tool bar. This automatically exports your public key, you can save it anywhere you want on your computer.
Share the file you saved in step 3 with whomever you want to exchange sensitive information with.

Decrypt a file by following these steps:

If the file is encrypted using PGP, it will be a .gpg file. Right click on the file and select: ‘open in Kleopatra’.
Kleopatra will decrypt the file (in the case that your key is protected with a passphrase, enter it), after decryption, you can choose to save or open the file.

The public key for tradias is given in the column on the right.

Contact

If you have any questions or suggestions, please contact info-api@tradias.de. We are more than happy to hear your remarks. Thank you for trading with tradias!

Servers

Base URLs:

https://api.{environment}.tradias.link
- environment - Tradias provides different environments. Default: “preprod”
  - “”
  - “preprod”
wss://ws.{environment}.tradias.link
- environment - Tradias provides different environments. Default: “preprod”
  - “”
  - “preprod”

License: tradias

Authentication

HTTP Authentication, scheme: bearer

Static Data

Tradias offers 150+ tradeable digital and fiat assets. They can be traded against several fiat or other crypto currencies. The list of tradeable asset is subject to regular review.

The following section consists of endpoints returning static data. Such data will include information about instrument names, assets within a pair, related precision and maximum order sizes. This section contains the following endpoint(s):

Instruments (REST)

Get List of tradeable Instruments

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/instruments"

rest_api_header = {
  "Authorization": "Bearer " + MY_TOKEN
}

tradeable_instruments = requests.get(url=URL, headers=rest_api_header)

print(json.dumps(tradeable_instruments.json(), indent=4))

GET /api/instruments

The Get List of tradeable Instruments endpoint returns a list of all instruments an API user can trade on the system. Apart from the instrument name, the response contains information about the instrument (e.g. the type of instrument, its legs and tenor), the trading limits and precisions. An instrument is a trading pair and it always consists of two assets, a leg 1 asset and a leg 2 asset. The leg 1 asset is the first asset that occurs in the pair and the leg 2 asset is the second. In some implementations they are referred to as the base asset and quote asset, respectively. The assets can be cryptocurrencies (including stablecoins) or fiats. Each asset has an associated precision, specifying up to how many decimals the amounts in this currency are accepted and computed. Each instrument has a maximum_leg_1_quantity associated with it, which indicates maximum order size for the instrument expressed in units of the leg 1 asset.

Example responses

200 Response

{
  "instrument_list": [
    {
      "instrument": "ALGO-EUR",
      "leg_1_asset": {
        "name": "Algorand",
        "code": "ALGO",
        "precision": 6
      },
      "leg_2_asset": {
        "name": "Euro",
        "code": "EUR",
        "precision": 2
      },
      "maximum_leg_1_quantity": "290000.0"
    },
    {
      "instrument": "AMP-EUR",
      "leg_1_asset": {
        "name": "Amp",
        "code": "AMP",
        "precision": 18
      },
      "leg_2_asset": {
        "name": "Euro",
        "code": "EUR",
        "precision": 2
      },
      "maximum_leg_1_quantity": "2400000.0"
    },
    {
      "instrument": "BTC-EUR/SP",
      "leg_1_asset": {
        "name": "Bitcoin",
        "code": "BTC",
        "precision": 8
      },
      "leg_2_asset": {
        "name": "Euro",
        "code": "EUR",
        "precision": 2
      },
      "maximum_leg_1_quantity": "36.0"
    }
  ]
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	List of tradeable Instruments	Inline
401	Unauthorized	Unauthorized	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

List of tradeable Instruments

Name	Type	Required	Restrictions	Description
» instrument_list	[object]	true	none	Array of tradeable Instruments
»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»» leg_1_asset	asset_type	true	none	An asset describes a crypto or fiat asset. It consists of a name (readable name of the asset), a code representing the asset and of a precision, which defines the number of digits after the decimal point which can be used for quantities in this asset.
»»» name	asset_name_type	true	none	Name of a leg of an instrument
»»» code	asset_code_type	true	none	Identifier of a leg of an instrument
»»» precision	asset_precision_type	true	none	The number of digits after the decimal point which are allowed for a quantity.
»» leg_2_asset	asset_type	true	none	An asset describes a crypto or fiat asset. It consists of a name (readable name of the asset), a code representing the asset and of a precision, which defines the number of digits after the decimal point which can be used for quantities in this asset.
»» tenor	asset_tenor_type	false	none	Identifier of a tenor. The following tenors are supported * SP = Spot
»» maximum_leg_1_quantity	quantity_type	true	none	The quantity of a leg.

Pricing

This section consists of endpoints returning current prices per instrument and accounting for market depth. The WebSocket endpoint can be configured to allow for custom data load limits. For more details on this, we refer to the ‘Prices’ endpoint.

Price Levels: the price for a given instrument is dependent on the side and the quantity. The expected execution price is the price associated with to the lowest quantity in the price update message larger than order size (i.e. “the price of the next higher quantity”).
Execution: orders are always executed the latest price at the arrival time of the order.

The following endpoint is contained in this section:

Prices (WebSocket)

(Un)Subscribe Price Channel

Code samples

import websockets
import asyncio
import json

MY_TOKEN = "ENTER YOUR TOKEN HERE"
ENVIRONMENT = "preprod"
PROTOCOL = "wss"

URI = f"{PROTOCOL}://ws.{ENVIRONMENT}.tradias.link/ws/prices"

websocket_headers = {
    "Authorization": "Bearer " + MY_TOKEN
}

price_channel_subscription = {
    "subscribe_price_channel": {
        "channel": "prices",
        "heartbeat_interval": 30
    }}

instruments_list = [
    {
        "subscription_id": "XX-4567",
        "instrument": "BTC-EUR/SP",
        "max_frequency": 500
    },
    {
        "subscription_id": "TS-BTC",
        "instrument": "BTC-EUR/SP",
        "mergeable": False,
        "max_pending": 100
    },
    {
        "subscription_id": "XX-4549",
        "instrument": "ETH-EUR/SP",
        "max_frequency": 500
    },
    {
        "subscription_id": "TS-ETH",
        "instrument": "ETH-EUR/SP",
        "mergeable": False
    }
]

async def get_prices(instruments: list[dict]) -> None:
    async with websockets.connect(uri=URI, extra_headers=websocket_headers) as websocket:
        await websocket.send(json.dumps(price_channel_subscription))
        await websocket.send(json.dumps(
            {
                "subscribe_instruments": {
                    "channel": "prices",
                    "subscriptions": instruments_list
                }
            }))
        while True:
            print(await websocket.recv())

asyncio.run(get_prices(instruments=instruments_list))

POST /ws/prices

With a subscription to this endpoint, you can get the price stream of our trading pairs (instruments), for several quantities (levels). For a given quantity you will be executed at the price of the next higher quantity that is shown in the ticker prices. It is possible to open multiple subscriptions to different price tickers in a single connection.

The prices that we stream differ per side and order quantity. This means that each quantity on each side will have a different price associated to it. On the buy side, the price of the trade increases with the quantity, while on the sell side the price decreases as the quantity increases.

The following logic applies for determining the price at which an order will be executed:

The price update messages contain multiple quantities per side, each linked to a different price. We also refer to these quantities as price levels. To determine the price at which the trade will be executed, the API user should look at the price level with the lowest quantity such that the quantity is still higher than the requested order amount.

For example, if a customer places an order to buy 8 AMP in the instrument AMPEUR, and the price updates are as follows:

Quantity: 1
- Buy price: 0.0018
- Sell price: 0.0016
Quantity: 5
- Buy price: 0.0086
- Sell price: 0.0084
Quantity: 10
- Buy price: 0.0174
- Sell price: 0.0169

In this scenario, the executed price for the trade would be 0.0174, since it is based on the level with a quantity of 10 AMP, as it is the first higher level beyond the customer’s requested quantity.

API users are given some control over the number of updates they receive. This is done via several parameters, the max_frequency, max_pending and the mergeables.

- mergeable: this parameter, when set to true, allows new updates to replace older updates when the API user is not able to read out the messages from the channel fast enough. This is mainly helpful when the price update rate is (too) high, since it will ensure that the latest price data is sent out to the user.

- max_frequency: this parameter can be used in conjunction with the parameter mergeable to specify the update rate that the API user can handle. It sets the time interval between updates for a subscription, if updates are sent faster than the specified max_frequency, the updates are merged. When it is set to 0, all updates are sent.

- max_pending: used to limit the queued updates for a subscription. If the number of queued updates surpasses this number, the newest updates will merge with the older ones until the queue’s size is below the max_pending number.

Note:

The number of price levels in the production environment can differ to that in the testing environment.

It can occur that there is only one-sided quoting available for an instrument (e.g., in case a coin gets delisted). In this case, prices don’t include both the sell_price and buy_price keys. For example: {“quantity”:“0.00002”,“sell_price”:“33698.32”}.

A subscription to the prices channel can be terminated using the message shown on the right.

  # Message to unsubscribe from price channel
  {
    "unsubscribe_channel": {
      "channel": "prices"
    }
  }

Body parameter

{
  "subscribe_price_channel": {
    "channel": "prices",
    "heartbeat_interval": 30
  }
}

Name	In	Type	Required	Description
body	body	SubscribePriceChannel	false	none
» subscribe_price_channel	body	object	true	none
»» channel	body	channel_type	true	Name of the websocket channel
»» heartbeat_interval	body	heartbeat_interval_type	false	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

Enumerated Values

Parameter	Value
»» channel	orders
»» channel	prices
»» channel	trades

Example responses

200 Response

{
  "price_update": {
    "header": {
      "channel": "prices",
      "timestamp": "1970-01-01T00:08:00.000000Z"
    },
    "update_list": [
      {
        "subscription_id": "TS-BTC",
        "instrument": "BTC-EUR/SP",
        "status": "ACTUAL",
        "update_ts": "1970-01-01T00:07:58.973000Z",
        "levels": [
          {
            "quantity": "1.25867895",
            "buy_price": "23768.69386464",
            "sell_price": "23767.67893759"
          }
        ]
      },
      {
        "subscription_id": "TS-BTC",
        "instrument": "BTC-EUR/SP",
        "status": "ACTUAL",
        "update_ts": "1970-01-01T00:07:59.657000Z",
        "levels": [
          {
            "quantity": "1.25867895",
            "buy_price": "23768.63953056",
            "sell_price": "23767.23953056"
          }
        ]
      },
      {
        "subscription_id": "XX-4567",
        "instrument": "BTC-EUR/SP",
        "status": "ACTUAL",
        "merged": true,
        "first_ts": "1970-01-01T00:07:58.973000Z",
        "update_ts": "1970-01-01T00:07:59.657000Z",
        "levels": [
          {
            "quantity": "1.25867895",
            "buy_price": "23768.63953056",
            "sell_price": "23767.23953056"
          }
        ]
      }
    ]
  }
}

Status	Meaning	Description	Schema
200	OK	Asynchronous price update message send by the server to the API user. A price update is a list of updates for different subscriptions. An update is sent for an subscription for each new status or price.	Inline
201	Created	Asynchronous heart beat message sent by the server to the subscriber	Inline
202	Accepted	Confirmation of a Channel Subscription	Inline
400	Bad Request	Channel Subscription has failed, channel can’t be used	Inline
401	Unauthorized	Rejection of a Price Subscription	Inline
403	Forbidden	Message received when a new_order can not be executed	Inline

Status Code 200

Name	Type	Required	Restrictions	Description
» price_update	object	true	none	none
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» update_list	[object]	true	none	Array containing a list of updates for a subscription
»»» subscription_id	subscription_id_type	true	none	This field is set by the API user. It’s serves the purpose of identifying the instrument price subscription, it is not unique.
»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»» status	price_status_type	false	none	The status of a price subscription * ACTUAL: There is an actual price * PARTIAL: There is a reduced set of price levels * UNAVAILABLE: There is actually no price * ERROR: No price available. The subscription failed
»»» update_ts	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»» merged	boolean	false	none	If true the update contains merged data. If false or not present the update has not been merged
»»» first_ts	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»» levels	[object]	false	none	The levels element is only present when the instrument exists and the price source is active. Otherwise the error field will be filled with an error message explaining what is wrong.
»»»» Level	object	false	none	none
»»»»» quantity	quantity_type	true	none	The quantity of a leg.
»»»»» buy_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» sell_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
status	ACTUAL
status	PARTIAL
status	UNAVAILABLE
status	ERROR

Status Code 201

Name	Type	Required	Restrictions	Description
» heartbeat	object	true	none	none
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades

Status Code 202

Name	Type	Required	Restrictions	Description
» channel_subscription_confirmation	object	true	none	Message received when the user is successfully subscribed to a channel.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» status	channel_status_type	true	none	Status of the websocket channel
»» heartbeat_interval	heartbeat_interval_type	true	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
status	ACTIVE
status	CLOSED

Status Code 400

Name	Type	Required	Restrictions	Description
» channel_subscription_error	object	true	none	Message received when the subscription to a channel has failed
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
»» error_text	error_text_type	false	none	Text describing the Error

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
error	Unauthorized
error	InternalServerError
error	Conflict
error	UnprocessableEntity
error	DuplicateReq
error	InvalidOrder
error	MixedOrders
error	InvalidAmount
error	AmountTooLow
error	AmountTooAccurate
error	AmountTooHigh
error	NoPriceStream
error	RiskCheck
error	DuplicateOrderRef
error	NotFound
error	Forbidden
error	ValidationError

Status Code 401

Name	Type	Required	Restrictions	Description
» price_subscription_error	object	true	none	Message received when a price subscription failed an is rejected.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» rejection_list	[object]	true	none	Array containing a list of rejected subscriptions
»»» subscription_id	subscription_id_type	true	none	This field is set by the API user. It’s serves the purpose of identifying the instrument price subscription, it is not unique.
»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»» error	error_text_type	true	none	Text describing the Error

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades

Status Code 403

Name	Type	Required	Restrictions	Description
» reject_message	object	true	none	A message through the WebSocket that gives information on a rejected request and the reason of rejection.
»» rejection_reason	rejection_reason_type	true	none	Message used to describe the reason that a request gets rejected.
»» rejection_text	rejection_text_type	true	none	Message used to explain the reason that a request gets rejected.
»» request_ref	request_ref_type	true	none	Reference used to refer to a request that was done.
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Code samples

import websockets
import asyncio
import json

MY_TOKEN = "ENTER YOUR TOKEN HERE"
ENVIRONMENT = "preprod"
PROTOCOL = "wss"

URI = f"{PROTOCOL}://ws.{ENVIRONMENT}.tradias.link/ws/prices"

websocket_headers = {
    "Authorization": "Bearer " + MY_TOKEN
}

price_channel_subscription = {
    "subscribe_price_channel": {
        "channel": "prices",
        "heartbeat_interval": 30
    }}

instruments_list = [
    {
        "subscription_id": "XX-4567",
        "instrument": "BTC-EUR/SP",
        "max_frequency": 500
    },
    {
        "subscription_id": "TS-BTC",
        "instrument": "BTC-EUR/SP",
        "mergeable": False,
        "max_pending": 100
    },
    {
        "subscription_id": "XX-4549",
        "instrument": "ETH-EUR/SP",
        "max_frequency": 500
    },
    {
        "subscription_id": "TS-ETH",
        "instrument": "ETH-EUR/SP",
        "mergeable": False
    }
]

async def get_prices(instruments: list[dict]) -> None:
    async with websockets.connect(uri=URI, extra_headers=websocket_headers) as websocket:
        await websocket.send(json.dumps(price_channel_subscription))
        await websocket.send(json.dumps(
            {
                "subscribe_instruments": {
                    "channel": "prices",
                    "subscriptions": instruments_list
                }
            }))
        while True:
            print(await websocket.recv())

asyncio.run(get_prices(instruments=instruments_list))

POST /ws/prices/instrument

Quantity: 1
- Buy price: 0.0018
- Sell price: 0.0016
Quantity: 5
- Buy price: 0.0086
- Sell price: 0.0084
Quantity: 10
- Buy price: 0.0174
- Sell price: 0.0169

The number of price levels in the production environment can differ to that in the testing environment.

It can occur that there is only one-sided quoting available for an instrument (e.g., in case a coin gets delisted). In this case, prices don’t include both the sell_price and buy_price keys. For example: {“quantity”:“0.00002”,“sell_price”:“33698.32”}.

A subscription to instrument prices through the price channel can be terminated using the message shown on the right.

  # Message to unsubscribe from instrument prices
  {
    "unsubscribe_instruments": {
      "channel": "prices",
      "subscription_ids": [
        "XX-4567",
        "TS-BTC",
        "XX-4549",
        "TS-ETH"
      ]
    }
  }

Body parameter

{
  "subscribe_instruments": {
    "channel": "prices",
    "subscriptions": [
      {
        "subscription_id": "XX-4567",
        "instrument": "BTC-EUR/SP",
        "max_frequency": 500
      },
      {
        "subscription_id": "TS-BTC",
        "instrument": "BTC-EUR/SP",
        "mergeable": false,
        "max_pending": 100
      },
      {
        "subscription_id": "XX-4549",
        "instrument": "ETH-EUR/SP",
        "max_frequency": 500
      },
      {
        "subscription_id": "TS-ETH",
        "instrument": "ETH-EUR/SP",
        "mergeable": false
      }
    ]
  }
}

Name	In	Type	Required	Description
body	body	SubscribeInstruments	false	none
» subscribe_instruments	body	object	true	none
»» channel	body	channel_type	true	Name of the websocket channel
»» subscriptions	body	[object]	true	Array containing a list of subscriptions
»»» Subscription	body	object	false	none
»»»» subscription_id	body	subscription_id_type	true	This field is set by the API user. It’s serves the purpose of identifying the instrument price subscription, it is not unique.
»»»» instrument	body	instrument_type	true	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor
»»»» mergeable	body	boolean	false	none
»»»» max_frequency	body	integer	false	none
»»»» max_pending	body	integer	false	none

Detailed descriptions

»»»» instrument: Identifier for an instrument.
It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]

Enumerated Values

Parameter	Value
»» channel	orders
»» channel	prices
»» channel	trades

Example responses

200 Response

{
  "price_update": {
    "header": {
      "channel": "prices",
      "timestamp": "1970-01-01T00:08:00.000000Z"
    },
    "update_list": [
      {
        "subscription_id": "TS-BTC",
        "instrument": "BTC-EUR/SP",
        "status": "ACTUAL",
        "update_ts": "1970-01-01T00:07:58.973000Z",
        "levels": [
          {
            "quantity": "1.25867895",
            "buy_price": "23768.69386464",
            "sell_price": "23767.67893759"
          }
        ]
      },
      {
        "subscription_id": "TS-BTC",
        "instrument": "BTC-EUR/SP",
        "status": "ACTUAL",
        "update_ts": "1970-01-01T00:07:59.657000Z",
        "levels": [
          {
            "quantity": "1.25867895",
            "buy_price": "23768.63953056",
            "sell_price": "23767.23953056"
          }
        ]
      },
      {
        "subscription_id": "XX-4567",
        "instrument": "BTC-EUR/SP",
        "status": "ACTUAL",
        "merged": true,
        "first_ts": "1970-01-01T00:07:58.973000Z",
        "update_ts": "1970-01-01T00:07:59.657000Z",
        "levels": [
          {
            "quantity": "1.25867895",
            "buy_price": "23768.63953056",
            "sell_price": "23767.23953056"
          }
        ]
      }
    ]
  }
}

Status	Meaning	Description	Schema
200	OK	Asynchronous price update message send by the server to the API user. A price update is a list of updates for different subscriptions. An update is sent for an subscription for each new status or price.	Inline
201	Created	Asynchronous heart beat message sent by the server to the subscriber	Inline
202	Accepted	Confirmation of a Channel Subscription	Inline
400	Bad Request	Channel Subscription has failed, channel can’t be used	Inline
401	Unauthorized	Rejection of a Price Subscription	Inline
403	Forbidden	Message received when a new_order can not be executed	Inline

Status Code 200

Name	Type	Required	Restrictions	Description
» price_update	object	true	none	none
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» update_list	[object]	true	none	Array containing a list of updates for a subscription
»»» subscription_id	subscription_id_type	true	none	This field is set by the API user. It’s serves the purpose of identifying the instrument price subscription, it is not unique.
»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»» status	price_status_type	false	none	The status of a price subscription * ACTUAL: There is an actual price * PARTIAL: There is a reduced set of price levels * UNAVAILABLE: There is actually no price * ERROR: No price available. The subscription failed
»»» update_ts	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»» merged	boolean	false	none	If true the update contains merged data. If false or not present the update has not been merged
»»» first_ts	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»» levels	[object]	false	none	The levels element is only present when the instrument exists and the price source is active. Otherwise the error field will be filled with an error message explaining what is wrong.
»»»» Level	object	false	none	none
»»»»» quantity	quantity_type	true	none	The quantity of a leg.
»»»»» buy_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» sell_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
status	ACTUAL
status	PARTIAL
status	UNAVAILABLE
status	ERROR

Status Code 201

Name	Type	Required	Restrictions	Description
» heartbeat	object	true	none	none
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades

Status Code 202

Name	Type	Required	Restrictions	Description
» channel_subscription_confirmation	object	true	none	Message received when the user is successfully subscribed to a channel.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» status	channel_status_type	true	none	Status of the websocket channel
»» heartbeat_interval	heartbeat_interval_type	true	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
status	ACTIVE
status	CLOSED

Status Code 400

Name	Type	Required	Restrictions	Description
» channel_subscription_error	object	true	none	Message received when the subscription to a channel has failed
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
»» error_text	error_text_type	false	none	Text describing the Error

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
error	Unauthorized
error	InternalServerError
error	Conflict
error	UnprocessableEntity
error	DuplicateReq
error	InvalidOrder
error	MixedOrders
error	InvalidAmount
error	AmountTooLow
error	AmountTooAccurate
error	AmountTooHigh
error	NoPriceStream
error	RiskCheck
error	DuplicateOrderRef
error	NotFound
error	Forbidden
error	ValidationError

Status Code 401

Name	Type	Required	Restrictions	Description
» price_subscription_error	object	true	none	Message received when a price subscription failed an is rejected.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» rejection_list	[object]	true	none	Array containing a list of rejected subscriptions
»»» subscription_id	subscription_id_type	true	none	This field is set by the API user. It’s serves the purpose of identifying the instrument price subscription, it is not unique.
»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»» error	error_text_type	true	none	Text describing the Error

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades

Status Code 403

Name	Type	Required	Restrictions	Description
» reject_message	object	true	none	A message through the WebSocket that gives information on a rejected request and the reason of rejection.
»» rejection_reason	rejection_reason_type	true	none	Message used to describe the reason that a request gets rejected.
»» rejection_text	rejection_text_type	true	none	Message used to explain the reason that a request gets rejected.
»» request_ref	request_ref_type	true	none	Reference used to refer to a request that was done.
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Trading

This section consists of endpoints that can be used for trading. The trading flow is relatively simple - if you want to trade, you place an order. Orders are either executed in full or rejected entirely, partial fills cannot occur when trading against tradias. o Regularly monitoring the collateral and trading line usage is recommended to avoid trading halts or liquidations (see: Risk Figures).

The endpoints in this section are:

Orders (WebSocket)
Trades (WebSocket)
Bulk Orders (REST)
Risk Figures (REST)

Placing an order can be done in two ways, either through the orders channel (WebSocket) or via a Bulk Order (REST). The method of choice depends on the use-case and desired execution parameters.

An order sent through the WebSocket is most suited for a continuous order flow, where each order is executed individually. In the case orders should be booked as several individual orders but executed as one big order, a bulk order can be used, where the bulk order contains many child orders (e.g. for savings plans, portfolio rebalancing).

Note: all orders are executed as Fill or Kill (FoK) orders, i.e. executed completely immediately or are rejected. Long-lived limit orders are currently not supported. More information on the implementation of limit orders can be found in the Orders endpoint section.

Responses to the order submission contain the relevant information about the execution or rejection thereof. These responses are sent through the same channel as was used to submit the order, both for the WebSocket and REST endpoints. Order rejections contain information about the rejection reasons, whereas order executions contain the information about the associated trade(s), including execution price, first and second leg amounts and timestamp.

Retrospectively, this information can be recovered through the Historic Data endpoints.

(Un)Subscribe Order Channel

Code samples

import asyncio
import json
import websockets

ENVIRONMENT = "preprod"
PROTOCOL = "WSS"
URL = f"{PROTOCOL}://ws.{ENVIRONMENT}.tradias.link/ws/orders"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

ws_headers = {
    "Authorization": "Bearer " + MY_TOKEN
}

my_order = {
    "new_order": {
        "order_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
        "req_header": {
            "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
            "user_data": [
                {
                    "tag": "Correlation-Id",
                    "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
                },
                {
                    "tag": "TX-Id",
                    "value": "18955457"
                }
            ]
        },
        "order_type": "LIMIT",
        "time_in_force": "FOK",
        "instrument": "BTC-EUR/SP",
        "side": "BUY",
        "amount": {
            "leg_2_amount": "50000"
        },
        "limit_price": "24570"
    }
}

async def place_order(order):
    async with websockets.connect(uri=URL, extra_headers=ws_headers) as websocket:
        await websocket.send(json.dumps({
            "subscribe_order_channel":
                {
                    "channel": "orders",
                    "heartbeat_interval": 30
                }
        }))
        await websocket.send(json.dumps(order))
        while True:
            message = await websocket.recv()
            print(message)

asyncio.run(place_order(order=my_order))

POST /ws/orders

It is possible to place both market orders and limit orders via our API. The implementation of limit orders is restricted in the sense that we only allow FOK/IOC (Fill or Kill/Immediate or Cancel) orders.

Types of Orders:

Market Order: in a market order the API user has to specify the instrument, quantity and side (buy or sell). Execution of market orders is done immediately and the execution price is the newest price for the corresponding instrument, quantity and side.
Limit Order: in a limit order the API user additionally specifies a price at which they are willing to buy or sell. Next to this, the user has to specify a parameter in the time_in_force field, which is either "FOK" or "IOC". Our current implementation of limit orders is restricted to FOK/IOC orders. This means that limit orders are not kept in an order book, they are either executed immediately or canceled immediately, depending on the parameters in the order request.
- Immediate or Cancel (IOC) and Fill or Kill (FOK): when placing a limit order, the API user has to enter either "IOC" or "FOK" in the time_in_force field. The order will either be executed or rejected immediately. The order is accepted when:
  - limit_pice >= latest_price, and the order is a buy order;
  - limit_price <= latest_price, and the order is a sell order.

In all other cases the limit order will be rejected immediately. In case of an execution, the limit order is executed at the latest price update, not the limit price. This means that executions are always done at a price that is the same or better than the specified limit_price. Note that there is no difference in how “FOK” or “IOC” limit orders are handled.

A subscription to the orders channel can be terminated using the message shown on the right.

# Message to unsubscribe from orders channel
{
  "unsubscribe_channel": {
    "channel": "orders"
  }
}

Body parameter

{
  "subscribe_order_channel": {
    "channel": "orders",
    "heartbeat_interval": 30
  }
}

Name	In	Type	Required	Description
body	body	SubscribeOrderChannel	false	none
» subscribe_order_channel	body	object	true	none
»» channel	body	channel_type	true	Name of the websocket channel
»» heartbeat_interval	body	heartbeat_interval_type	false	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

Enumerated Values

Parameter	Value
»» channel	orders
»» channel	prices
»» channel	trades

Example responses

200 Response

{
  "order_execution": {
    "header": {
      "channel": "orders",
      "timestamp": "1970-01-01T00:00:00.000000Z"
    },
    "order_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "order_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "order_type": "LIMIT",
    "time_in_force": "FOK",
    "instrument": "BTC-EUR/SP",
    "side": "BUY",
    "amount": {
      "leg_2_amount": "50000"
    },
    "limit_price": "24570",
    "order_status": "DONE",
    "leg_1_executed_amount": "2.02814908",
    "leg_2_executed_amount": "50000",
    "execution_price": "24653.020129"
  }
}

Status	Meaning	Description	Schema
200	OK	Report the execution of an order sent earlier	Inline
201	Created	Asynchronous heart beat message sent by the server to the subscriber	Inline
202	Accepted	Confirmation of a Channel Subscription	Inline
203	Non-Authoritative Information	Message received when a new_order can not be executed	Inline
400	Bad Request	Channel Subscription has failed, channel can’t be used	Inline
403	Forbidden	Message received when a new_order can not be executed	Inline

Status Code 200

Name	Type	Required	Restrictions	Description
» order_execution	object	true	none	Message received when a new_order sent by the API user gets executed.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» trade_id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»» time_in_force	time_in_force_type	true	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»» order_status	order_status_type	true	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE

Status Code 201

Name	Type	Required	Restrictions	Description
» heartbeat	object	true	none	none
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades

Status Code 202

Name	Type	Required	Restrictions	Description
» channel_subscription_confirmation	object	true	none	Message received when the user is successfully subscribed to a channel.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» status	channel_status_type	true	none	Status of the websocket channel
»» heartbeat_interval	heartbeat_interval_type	true	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
status	ACTIVE
status	CLOSED

Status Code 203

Name	Type	Required	Restrictions	Description
» order_status	object	true	none	Message received when a new_order can not be executed
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»» order_status	order_status_type	true	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»» rejection_reason	rejection_reason_type	true	none	Message used to describe the reason that a request gets rejected.
»» rejection_text	rejection_text_type	true	none	Message used to explain the reason that a request gets rejected.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE

Status Code 400

Name	Type	Required	Restrictions	Description
» channel_subscription_error	object	true	none	Message received when the subscription to a channel has failed
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
»» error_text	error_text_type	false	none	Text describing the Error

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
error	Unauthorized
error	InternalServerError
error	Conflict
error	UnprocessableEntity
error	DuplicateReq
error	InvalidOrder
error	MixedOrders
error	InvalidAmount
error	AmountTooLow
error	AmountTooAccurate
error	AmountTooHigh
error	NoPriceStream
error	RiskCheck
error	DuplicateOrderRef
error	NotFound
error	Forbidden
error	ValidationError

Status Code 403

Name	Type	Required	Restrictions	Description
» reject_message	object	true	none	A message through the WebSocket that gives information on a rejected request and the reason of rejection.
»» rejection_reason	rejection_reason_type	true	none	Message used to describe the reason that a request gets rejected.
»» rejection_text	rejection_text_type	true	none	Message used to explain the reason that a request gets rejected.
»» request_ref	request_ref_type	true	none	Reference used to refer to a request that was done.
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

New Order through Order Channel

Code samples

import asyncio
import json
import websockets

ENVIRONMENT = "preprod"
PROTOCOL = "WSS"
URL = f"{PROTOCOL}://ws.{ENVIRONMENT}.tradias.link/ws/orders"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

ws_headers = {
    "Authorization": "Bearer " + MY_TOKEN
}

my_order = {
    "new_order": {
        "order_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
        "req_header": {
            "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
            "user_data": [
                {
                    "tag": "Correlation-Id",
                    "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
                },
                {
                    "tag": "TX-Id",
                    "value": "18955457"
                }
            ]
        },
        "order_type": "LIMIT",
        "time_in_force": "FOK",
        "instrument": "BTC-EUR/SP",
        "side": "BUY",
        "amount": {
            "leg_2_amount": "50000"
        },
        "limit_price": "24570"
    }
}

async def place_order(order):
    async with websockets.connect(uri=URL, extra_headers=ws_headers) as websocket:
        await websocket.send(json.dumps({
            "subscribe_order_channel":
                {
                    "channel": "orders",
                    "heartbeat_interval": 30
                }
        }))
        await websocket.send(json.dumps(order))
        while True:
            message = await websocket.recv()
            print(message)

asyncio.run(place_order(order=my_order))

POST /ws/orders/neworder

An order is a request for buying or selling a specific asset. Order requests always specify the trading pair, quantity, and side at which the trader is willing to transact. For limit orders, the price should also be given.

It is possible to place both market orders and limit orders via our API. The implementation of limit orders is restricted in the sense that we only allow FOK/IOC (Fill or Kill/Immediate or cancel) orders.

Types of Orders:

Market Order: in a market order the API user at least specifies the instrument, quantity and side (buy or sell). Execution of market orders is done immediately and the execution price is the newest price for the corresponding instrument, quantity and side.
Limit Order: in a limit order the API user additionally specifies a price at which they are willing to buy or sell. Next to this, the user has to specify a parameter in the time_in_force field, which is either “FOK” or “IOC”. Our current implementation of limit orders is restricted to FOK/IOC orders. This means that limit orders are not kept in an order book, they are either executed immediately or canceled immediately, depending on the parameters in the order request.
- Immediate or Cancel (IOC) and Fill or Kill (FOK): when placing a limit order, the API user has to enter either “IOC” or “FOK” in the time_in_force field. The order will either be executed or rejected immediately. The order is accepted when:
  - limit_pice >= latest_price, and the order is a buy order;
  - limit_price <= latest_price, and the order is a sell order.
In all other cases the limit order will be rejected immediately. In case of an execution, the limit order is executed at the latest price update, not the limit price. This means that executions are always done at a price that is the same or better than the specified limit_price. Note that there is no difference in how “FOK” or “IOC” limit orders are handled.

Body parameter

{
  "new_order": {
    "order_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "order_type": "LIMIT",
    "time_in_force": "FOK",
    "instrument": "BTC-EUR/SP",
    "side": "BUY",
    "amount": {
      "leg_2_amount": "50000"
    },
    "limit_price": "24570"
  }
}

Parameters

Name	In	Type	Required	Description
body	body	NewOrder	false	none
» new_order	body	object	true	none
»» order_ref	body	external_ref_type	true	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	body	req_header_type	false	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	body	unique_req_type	false	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	body	[object]	false	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	body	string	true	none
»»»» value	body	string	true	none
»» order_type	body	order_type_type	true	There are different order types. Currently only the following order types are supported
»» time_in_force	body	time_in_force_type	false	This order attribute defines the duration a order is active.
»» instrument	body	instrument_type	true	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor
»» side	body	side_type	true	The side of the order, seen from the perspective of the API user.
»» amount	body	order_amount_type	true	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»» leg_1_amount	body	quantity_type	false	The quantity of a leg.
»»» leg_2_amount	body	quantity_type	false	The quantity of a leg.
»» limit_price	body	price_type	false	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»» counter_leg_precision	body	counter_leg_precision_type	false	This optional key can be given in a new order request. The value specifies the number of decimals you want the computed amount of the leg that is not yet specified in the order request to be rounded to. For example, if you give the amount you want to buy/sell in the leg 2 asset, the counter_leg_precision specifies the number of decimals you want the leg 1 amount to be rounded to. Vice versa, if you specify the amount to buy/sell in the leg 1 asset, the amount in the leg 2 asset will be rounded to the specified number in the counter_leg_precision field.

Detailed descriptions

»» order_type: There are different order types. Currently only the following order types are supported

MARKET: This is a order (without limit).
LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price.
BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.

»» time_in_force: This order attribute defines the duration a order is active.

FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected.
IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.

»» instrument: Identifier for an instrument.
It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]

»» side: The side of the order, seen from the perspective of the API user.

BUY The user sending the order is buying assets
SELL The user sending the order is selling his assets

Enumerated Values

Parameter	Value
»» order_type	MARKET
»» order_type	LIMIT
»» order_type	BULK_MARKET
»» time_in_force	FOK
»» time_in_force	IOC
»» side	BUY
»» side	SELL

Example responses

200 Response

{
  "order_execution": {
    "header": {
      "channel": "orders",
      "timestamp": "1970-01-01T00:00:00.000000Z"
    },
    "order_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "order_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "order_type": "LIMIT",
    "time_in_force": "FOK",
    "instrument": "BTC-EUR/SP",
    "side": "BUY",
    "amount": {
      "leg_2_amount": "50000"
    },
    "limit_price": "24570",
    "order_status": "DONE",
    "leg_1_executed_amount": "2.02814908",
    "leg_2_executed_amount": "50000",
    "execution_price": "24653.020129"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Report the execution of an order sent earlier	Inline
201	Created	Asynchronous heart beat message sent by the server to the subscriber	Inline
202	Accepted	Confirmation of a Channel Subscription	Inline
203	Non-Authoritative Information	Message received when a new_order can not be executed	Inline
400	Bad Request	Channel Subscription has failed, channel can’t be used	Inline
403	Forbidden	Message received when a new_order can not be executed	Inline

Response Schema

Status Code 200

Name	Type	Required	Restrictions	Description
» order_execution	object	true	none	Message received when a new_order sent by the API user gets executed.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» trade_id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»» time_in_force	time_in_force_type	true	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»» order_status	order_status_type	true	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE

Status Code 201

Name	Type	Required	Restrictions	Description
» heartbeat	object	true	none	none
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades

Status Code 202

Name	Type	Required	Restrictions	Description
» channel_subscription_confirmation	object	true	none	Message received when the user is successfully subscribed to a channel.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» status	channel_status_type	true	none	Status of the websocket channel
»» heartbeat_interval	heartbeat_interval_type	true	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
status	ACTIVE
status	CLOSED

Status Code 203

Name	Type	Required	Restrictions	Description
» order_status	object	true	none	Message received when a new_order can not be executed
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»» order_status	order_status_type	true	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»» rejection_reason	rejection_reason_type	true	none	Message used to describe the reason that a request gets rejected.
»» rejection_text	rejection_text_type	true	none	Message used to explain the reason that a request gets rejected.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE

Status Code 400

Name	Type	Required	Restrictions	Description
» channel_subscription_error	object	true	none	Message received when the subscription to a channel has failed
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
»» error_text	error_text_type	false	none	Text describing the Error

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
error	Unauthorized
error	InternalServerError
error	Conflict
error	UnprocessableEntity
error	DuplicateReq
error	InvalidOrder
error	MixedOrders
error	InvalidAmount
error	AmountTooLow
error	AmountTooAccurate
error	AmountTooHigh
error	NoPriceStream
error	RiskCheck
error	DuplicateOrderRef
error	NotFound
error	Forbidden
error	ValidationError

Status Code 403

Name	Type	Required	Restrictions	Description
» reject_message	object	true	none	A message through the WebSocket that gives information on a rejected request and the reason of rejection.
»» rejection_reason	rejection_reason_type	true	none	Message used to describe the reason that a request gets rejected.
»» rejection_text	rejection_text_type	true	none	Message used to explain the reason that a request gets rejected.
»» request_ref	request_ref_type	true	none	Reference used to refer to a request that was done.
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

New Bulk Order (Coming Soon)

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/orders/bulk"
payload = {
    "req_header": {
        "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
        "user_data": [
            {
                "tag": "Correlation-Id",
                "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
            },
            {
                "tag": "TX-Id",
                "value": "18955457"
            }
        ]
    },
    "order_type": "BULK_MARKET",
    "orders": [
        {
            "order_ref": "18955839",
            "instrument": "BTC-EUR/SP",
            "side": "BUY",
            "amount": {
                "leg_1_amount": "2.5"
            },
            "user_data": [
                {
                    "tag": "Correlation-Id",
                    "value": "7ac33648-ae4b-11ed-b2f9-81a12bb57b04"
                },
                {
                    "tag": "TX-Id",
                    "value": "18955839"
                }
            ]
        },
        {
            "order_ref": "18958204",
            "instrument": "ETH-EUR/SP",
            "side": "BUY",
            "amount": {
                "leg_2_amount": "20000"
            },
            "user_data": [
                {
                    "tag": "Correlation-Id",
                    "value": "888d205a-ae4b-11ed-9362-81a12bb57b04"
                },
                {
                    "tag": "TX-Id",
                    "value": "18958204"
                }
            ]
        }
    ]
}
rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

bulk_order_request = requests.post(url=URL, headers=rest_api_header, json=payload)

print(json.dumps(bulk_order_request.json(), indent=4))

POST /api/orders/bulk

If you want to place multiple orders at once, you can use the Bulk Order endpoint. In the request to the New Bulk Order endpoints, you can send many orders (up to 9999 orders) at once. The format of the orders in a bulk order, hereafter referred to as ‘child orders’, is the same as the format of an order that is sent to the WebSocket orders endpoint. The child orders of the bulk order will all be visible individually in the Order History. The trades originating from orders in a bulk order are all visible in the Trade History. However, the orders are not communicated as messages on the Orders WebSocket channel nor are the executions of bulk orders communicated over the Trades WebSocket channel. After a new bulk order has been created it can be inquired either by the Get Bulk Order or by the Bulk Order Status endpoints.

For example, bulk orders fit the following applications:

Executions of large amounts of orders for end-customers, where all customers must be executed at the exact same price and timestamp, yet booked individually for each customer
Rebalancing of portfolios, without breaking risk limits when shorting one asset to go long in another.
Executing basket purchases by known percentages of a predetermined investment amount

The working of a bulk order is summarized by the following steps:

The timestamp of receipt is stored along with the prices of all instruments within the bulk order.
The aggregation of all amounts over any particular instrument and side is determined.
The execution price is determined based on the aggregated amounts of the previous step.
The risk check is applied based on the resulting change of exposure.
If the risk check passes, the order is executed. The orders and corresponding executions can be viewed.

More details on the working of bulk orders can be found below:

Price: the price of orders in a bulk order is computed based on the price at the time of receipt. Note that the price is determined on the depth of the aggregated amount per instrument per side, not on the amount per child order in order to ensure that all orders for the same instrument and the same side will be executed on the same price. Also note that opposite sides are not ‘netted’ when the depth of the price is determined.

Example: suppose that up to 15 BTC, the buy price equals 27000 and from 15 to 50 BTC the buy price equals 27100. Suppose the following three orders are sent in one bulk order:
- {“order_ref”: 1, “instrument”: “BTC-EUR”, “side”: “BUY”, “amount”: {“leg_1_amount”: “10”}}
- {“order_ref”: 2, “instrument”: “BTC-EUR”, “side”: “BUY”, “amount”: {“leg_1_amount”: “20”}}
- {“order_ref”: 3, “instrument”: “BTC-EUR”, “side”: “SELL”, “amount”: {“leg_1_amount”: “20”}}
Since the price for the two ‘BUY’ orders is determined based on the aggregated amount of all ‘BUY’ orders for BTC-EUR, the price of the orders with reference 1 and 2 gets executed at a market depth of 20+10=30. Hence the first and second order will be executed at a price of 27100.
Computation of risk limits: unlike the case where all orders are submitted separately through the WebSocket, the risk check in the bulk order is applied on the change in exposure of the entire bulk order, as opposed to the risk check being applied to the change in exposure for each child order individually. This means that per instrument, the resulting exposure change in euro is computed, which is subsequently used for the computation of the risk limits.

Example: suppose that an order of 10 BTC would breach your risk limits. Posting a bulk order with the following child orders, the bulk order would be rejected as its execution would breach the risk limits:
- {“order_ref”: 1, “instrument”: “BTC-EUR”, “side”: “BUY”, “amount”: {“leg_1_amount”: “7”}}
- {“order_ref”: 2, “instrument”: “BTC-EUR”, “side”: “BUY”, “amount”: {“leg_1_amount”: “4”}}
Example: suppose that an order of 10 BTC would breach your risk limits. Posting a bulk order with the following orders, the bulk order would not be rejected since the aggregated amount does not cause a breach of the risk limits:
- {“order_ref”: 1, “instrument”: “BTC-EUR”, “side”: “BUY”, “amount”: {“leg_1_amount”: “12”}}
- {“order_ref”: 2, “instrument”: “BTC-EUR”, “side”: “SELL”, “amount”: {“leg_1_amount”: “4”}}
Valid orders: the child orders in a bulk order do not all need to have the same instruments, same sides and use the same asset for specifying the quantity of the order. However, for any particular combination of side and instrument in a bulk order, only the leg_1_amount or leg_2_amount field can be used.

Example: suppose that you send a bulk order consisting of the following orders:
- {“order_ref”: 1, “instrument”: “ETH-EUR”, “side”: “BUY”, “amount”: {“leg_1_amount”: “101”}}
- {“order_ref”: 2, “instrument”: “ETH-EUR”, “side”: “SELL”, “amount”: {“leg_2_amount”: “9000”}}
- {“order_ref”: 3, “instrument”: “ADA-EUR”, “side”: “SELL”, “amount” {“leg_2_amount”: “1500”}}
This is a valid format and the bulk order will go through.

Example: suppose that you send a bulk order consisting of the following orders:
- {“order_ref”: 1, “instrument”: “ETH-EUR”, “side”: “BUY”, “amount”: {“leg_1_amount”: “101”}}
- {“order_ref”: 2, “instrument”: “ETH-EUR”, “side”: “BUY”, “amount” {“leg_2_amount”: “1500”}}
This is not a valid format since for a specific combination of instrument and side, there is an order containing the “leg_1_amount” key and there is another order with the same instrument and same side that contains the “leg_2_amount” key. The bulk order will not go through.
Other functionalities:
- Bulk orders are designed to be atomic, meaning that either all orders in the bulk orders are executed or none.
- The “req_id” in the “req_header” can be used for its idempotency property, if required.

Body parameter

{
  "new_bulk_order": {
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "order_type": "BULK_MARKET",
    "orders": [
      {
        "order_ref": "18955839",
        "instrument": "BTC-EUR/SP",
        "side": "BUY",
        "amount": {
          "leg_1_amount": "2.5"
        },
        "user_data": [
          {
            "tag": "Correlation-Id",
            "value": "7ac33648-ae4b-11ed-b2f9-81a12bb57b04"
          },
          {
            "tag": "TX-Id",
            "value": "18955839"
          }
        ]
      },
      {
        "order_ref": "18958204",
        "instrument": "ETH-EUR/SP",
        "side": "BUY",
        "amount": {
          "leg_2_amount": "20000"
        },
        "user_data": [
          {
            "tag": "Correlation-Id",
            "value": "888d205a-ae4b-11ed-9362-81a12bb57b04"
          },
          {
            "tag": "TX-Id",
            "value": "18958204"
          }
        ]
      }
    ]
  }
}

Parameters

Name	In	Type	Required	Description
body	body	object	false	none
» new_bulk_order	body	object	true	none
»» req_header	body	req_header_type	false	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	body	unique_req_type	false	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	body	[object]	false	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	body	string	true	none
»»»» value	body	string	true	none
»» order_type	body	order_type_type	true	There are different order types. Currently only the following order types are supported
»» orders	body	[market_order_type]	true	[This schema represents all information needed for an MARKET order]
»»» Market Order Data	body	market_order_type	false	This schema represents all information needed for an MARKET order
»»»» order_ref	body	external_ref_type	true	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»»» instrument	body	instrument_type	true	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor
»»»» side	body	side_type	true	The side of the order, seen from the perspective of the API user.
»»»» amount	body	order_amount_type	true	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»»» leg_1_amount	body	quantity_type	false	The quantity of a leg.
»»»»» leg_2_amount	body	quantity_type	false	The quantity of a leg.
»»»» user_data	body	[object]	false	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» counter_leg_precision	body	counter_leg_precision_type	false	This optional key can be given in a new order request. The value specifies the number of decimals you want the computed amount of the leg that is not yet specified in the order request to be rounded to. For example, if you give the amount you want to buy/sell in the leg 2 asset, the counter_leg_precision specifies the number of decimals you want the leg 1 amount to be rounded to. Vice versa, if you specify the amount to buy/sell in the leg 1 asset, the amount in the leg 2 asset will be rounded to the specified number in the counter_leg_precision field.

Detailed descriptions

»» order_type: There are different order types. Currently only the following order types are supported

MARKET: This is a order (without limit).
LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price.
BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.

»»»» instrument: Identifier for an instrument.
It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]

»»»» side: The side of the order, seen from the perspective of the API user.

BUY The user sending the order is buying assets
SELL The user sending the order is selling his assets

Enumerated Values

Parameter	Value
»» order_type	MARKET
»» order_type	LIMIT
»» order_type	BULK_MARKET
»»»» side	BUY
»»»» side	SELL

Example responses

202 Response

{
  "new_bulk_order_response": {
    "bulk_order_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "bulk_order_status": "RECEIVED",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "timestamp": "2023-01-20T14:31:10.012123Z"
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

409 Response

{
  "error_req_header": {
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "tradias_id": "75ccdf76-ae4b-11ed-85ee-81a12bb57b04",
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "DuplicateReq",
    "error_text": "The req_id has been already processed"
  }
}

422 Response

{
  "new_bulk_order_error_response": {
    "bulk_order_id": "6c51119a-ae4b-11ed-b75a-81a12bb57b04",
    "bulk_order_status": "REJECTED",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "bulk_order_submitted_at": "2023-01-20T14:31:09.012123Z",
    "rejected_order": {
      "order_ref": "18955839",
      "instrument": "BTC-EUR/SP",
      "side": "BUY",
      "amount": {
        "leg_1_amount": "2.5"
      },
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "7ac33648-ae4b-11ed-b2f9-81a12bb57b04"
        },
        {
          "tag": "TX-Id",
          "value": "18955839"
        }
      ]
    },
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "RiskCheck",
    "error_text": "The bulk order could not be executed because the resulting margin usage would be too high."
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
202	Accepted	Accepted	Inline
401	Unauthorized	Unauthorized	internal_error_type
409	Conflict	Duplicate Request	internal_req_error_type
422	Unprocessable Entity	Bulk Order Error	Inline
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 202

Name	Type	Required	Restrictions	Description
» new_bulk_order_response	object	true	none	none
»» bulk_order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» bulk_order_status	bulk_order_status_type	true	none	The status of a new bulk order is RECEIVED. BULK_MARKET orders will be executed immediately an becomes then either REJECTED if it could not be executed or DONE if it got executed.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
bulk_order_status	RECEIVED
bulk_order_status	REJECTED
bulk_order_status	DONE

Status Code 422

Name	Type	Required	Restrictions	Description
» new_bulk_order_error_response	object	true	none	none
»» bulk_order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» bulk_order_status	bulk_order_status_type	true	none	The status of a new bulk order is RECEIVED. BULK_MARKET orders will be executed immediately an becomes then either REJECTED if it could not be executed or DONE if it got executed.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» bulk_order_submitted_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» rejected_order	market_order_type	true	none	This schema represents all information needed for an MARKET order
»»» order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»» counter_leg_precision	counter_leg_precision_type	false	none	This optional key can be given in a new order request. The value specifies the number of decimals you want the computed amount of the leg that is not yet specified in the order request to be rounded to. For example, if you give the amount you want to buy/sell in the leg 2 asset, the counter_leg_precision specifies the number of decimals you want the leg 1 amount to be rounded to. Vice versa, if you specify the amount to buy/sell in the leg 1 asset, the amount in the leg 2 asset will be rounded to the specified number in the counter_leg_precision field.
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
»» error_text	error_text_type	true	none	Text describing the Error

Enumerated Values

Property	Value
bulk_order_status	RECEIVED
bulk_order_status	REJECTED
bulk_order_status	DONE
side	BUY
side	SELL
error	Unauthorized
error	InternalServerError
error	Conflict
error	UnprocessableEntity
error	DuplicateReq
error	InvalidOrder
error	MixedOrders
error	InvalidAmount
error	AmountTooLow
error	AmountTooAccurate
error	AmountTooHigh
error	NoPriceStream
error	RiskCheck
error	DuplicateOrderRef
error	NotFound
error	Forbidden
error	ValidationError

Get Bulk Order (Coming Soon)

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/orders/bulk/6aa21c20-ae4b-11ed-b304-81a12bb57b04"

rest_api_header = {
  "Authorization": "Bearer " + MY_TOKEN
}

bulk_order_request = requests.get(url=URL, headers=rest_api_header)

print(json.dumps(bulk_order_request.json(), indent=4))

GET /api/orders/bulk/{bulk_order_id}

The Get Bulk Order endpoint allows the retrieval of all details regarding a specific bulk order. This includes the order status, timestamp as well as the details on the execution for all child orders and associated trades, if applicable.

As bulk orders are processed asynchronously, the information on a specific bulk order is only accessible after the processing is complete. In order to determine the status of the completion of the bulk order processing as well as the success of its execution, the Get Bulk Order Status endpoint can be used.

Parameters

Name	In	Type	Required	Description
bulk_order_id	path	internal_ref_type	true	none

Example responses

200 Response

{
  "get_bulk_order_response": {
    "bulk_order_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "bulk_order_status": "RECEIVED",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "bulk_order_submitted_at": "1970-01-01T00:00:00.000000Z",
    "timestamp": "1970-01-01T00:00:00.000000Z",
    "error": "NotFound",
    "error_text": "The bulk order with the given ID could not be found.",
    "executions": [
      {
        "order": {
          "order_ref": "18955839",
          "instrument": "BTC-EUR/SP",
          "side": "BUY",
          "amount": {
            "leg_1_amount": "2.5"
          },
          "user_data": [
            {
              "tag": "Correlation-Id",
              "value": "7ac33648-ae4b-11ed-b2f9-81a12bb57b04"
            },
            {
              "tag": "TX-Id",
              "value": "18955839"
            }
          ]
        },
        "order_type": "BULK_MARKET",
        "time_in_force": "FOK",
        "order_status": "DONE",
        "leg_1_executed_amount": "1.25867895",
        "leg_2_executed_amount": "1.25867895",
        "execution_price": "23768.63953056",
        "trade_ids": [
          "6aa21c20-ae4b-11ed-b304-81a12bb57b04"
        ],
        "executed_at": "1970-01-01T00:00:00.000000Z"
      }
    ]
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Get Bulk Order	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Name	Type	Required	Restrictions	Description
» get_bulk_order_response	object	true	none	none
»» bulk_order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» bulk_order_status	bulk_order_status_type	true	none	The status of a new bulk order is RECEIVED. BULK_MARKET orders will be executed immediately an becomes then either REJECTED if it could not be executed or DONE if it got executed.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» bulk_order_submitted_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» error	error_type	false	none	All error codes returned by this API have a unique code, classifying the error messages.
»» error_text	error_text_type	false	none	Text describing the Error
»» executions	[bulk_execution_type]	true	none	none
»»» Bulk Order Execution	bulk_execution_type	false	none	none
»»»» order	market_order_type	true	none	This schema represents all information needed for an MARKET order
»»»»» order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»»»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»»»»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»»»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»»»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»»» counter_leg_precision	counter_leg_precision_type	false	none	This optional key can be given in a new order request. The value specifies the number of decimals you want the computed amount of the leg that is not yet specified in the order request to be rounded to. For example, if you give the amount you want to buy/sell in the leg 2 asset, the counter_leg_precision specifies the number of decimals you want the leg 1 amount to be rounded to. Vice versa, if you specify the amount to buy/sell in the leg 1 asset, the amount in the leg 2 asset will be rounded to the specified number in the counter_leg_precision field.
»»»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»»»» time_in_force	time_in_force_type	true	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»»»» order_status	order_status_type	true	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»» trade_ids	[internal_ref_type]	false	none	[This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).]
»»»»» Internal Reference or Id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
bulk_order_status	RECEIVED
bulk_order_status	REJECTED
bulk_order_status	DONE
error	Unauthorized
error	InternalServerError
error	Conflict
error	UnprocessableEntity
error	DuplicateReq
error	InvalidOrder
error	MixedOrders
error	InvalidAmount
error	AmountTooLow
error	AmountTooAccurate
error	AmountTooHigh
error	NoPriceStream
error	RiskCheck
error	DuplicateOrderRef
error	NotFound
error	Forbidden
error	ValidationError
side	BUY
side	SELL
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE

Bulk Order Status (Coming Soon)

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/orders/bulk/6aa21c20-ae4b-11ed-b304-81a12bb57b04/status"

rest_api_header = {
  "Authorization": "Bearer " + MY_TOKEN
}

bulk_order_status_request = requests.get(url=URL, headers=rest_api_header)

print(json.dumps(bulk_order_status_request.json(), indent=4))

GET /api/orders/bulk/{bulk_order_id}/status

The Bulk Order Status endpoint can be queried using the bulk_order_id as returned in the response of the New Bulk Order endpoint. The endpoint serves as a shorter version of the Get Bulk Order endpoint allows checking on the processing state of a bulk order.

In particular, the endpoint returns the status of the bulk order, which is either ‘DONE’, meaning it was executed, ‘REJECTED’, meaning that it cannot be processed and executed due to an error, or ‘RECEIVED’, which means that it is being processed. Additionally, the endpoint returns the request ID and the user data as passed in the request to the New Bulk Order endpoint.

Both the Get Bulk Order and Get Bulk Order Status endpoints return information on the bulk orders that were posted. Generally, the Get Bulk Order Status endpoint is more useful when you are polling the state of a bulk order, as its response is more compact compared to the Get Bulk Order endpoint response. In contrast, the Get Bulk Order endpoint returns detailed information about the bulk order and its associated child orders.

Parameters

Name	In	Type	Required	Description
bulk_order_id	path	internal_ref_type	true	none

Example responses

200 Response

{
  "bulk_order_status_response": {
    "bulk_order_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "bulk_order_status": "RECEIVED",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "timestamp": "2023-01-20T14:31:10.012123Z"
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Bulk Order Status	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Name	Type	Required	Restrictions	Description
» bulk_order_status_response	object	true	none	none
»» bulk_order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» bulk_order_status	bulk_order_status_type	true	none	The status of a new bulk order is RECEIVED. BULK_MARKET orders will be executed immediately an becomes then either REJECTED if it could not be executed or DONE if it got executed.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
bulk_order_status	RECEIVED
bulk_order_status	REJECTED
bulk_order_status	DONE

Trade channel (Coming Soon)

Code samples

import asyncio
import json
import websockets

ENVIRONMENT = "preprod"
PROTOCOL = "wss"
ws_url = f"{PROTOCOL}://ws.{ENVIRONMENT}.tradias.link/ws/trades"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

ws_headers = {
    "Authorization": "Bearer " + MY_TOKEN
}

async def trades():
    async with websockets.connect(uri=ws_url, extra_headers=ws_headers) as websocket:
        await websocket.send(json.dumps({
            "subscribe_trade_channel": {
                "channel": "trades",
                "heartbeat_interval": 30,
                "seq_number": 47110815
            }
        }))
        while True:
            message = await websocket.recv()
            print(message)

asyncio.run(trades())

POST /ws/trades

A trade is an execution of a market or limit order. The trade channel is a WebSocket channel via which an API user can listen to executions or other updates on orders. Whenever an order is executed or cancelled, this is reflected via an update in the trade channel.

This subscription is used to receive trades executed by the API user. In the subscription to the channel, the user can specify sequence numbers or a time stamp which filter which trades will be shown in the channel. If both are not given, the trades that are shown will be all trades starting at the current day. Each trade is reported as a separate message. The last trade from the history is marked with a flag and from then on all trades executed are delivered in real-time.

A subscription to the trades channel can be terminated using the message shown on the right.

  # Message to unsubscribe from trades channel
  {
    "unsubscribe_channel": {
      "channel": "trades"
    }
  }

Body parameter

{
  "subscribe_trade_channel": {
    "channel": "trades",
    "heartbeat_interval": 30,
    "seq_number": 47110815
  }
}

Parameters

Name	In	Type	Required	Description
body	body	SubscribeTradeChannel	false	none
» subscribe_trade_channel	body	object	true	none
»» channel	body	channel_type	true	Name of the websocket channel
»» heartbeat_interval	body	heartbeat_interval_type	false	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.
»» seq_number	body	sequence_type	false	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.
»» execution_time	body	timestamp_type	false	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Parameter	Value
»» channel	orders
»» channel	prices
»» channel	trades

Example responses

200 Response

{
  "channel_subscription_confirmation": {
    "header": {
      "channel": "prices",
      "timestamp": "1970-01-01T00:00:00.000000Z"
    },
    "status": "ACTIVE",
    "heartbeat_interval": 30
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Confirmation of a Channel Subscription	Inline
201	Created	Asynchronous heart beat message sent by the server to the subscriber	Inline
202	Accepted	Message received when a execution happens	Inline
400	Bad Request	Channel Subscription has failed, channel can’t be used	Inline
403	Forbidden	Message received when a new_order can not be executed	Inline

Response Schema

Status Code 200

Name	Type	Required	Restrictions	Description
» channel_subscription_confirmation	object	true	none	Message received when the user is successfully subscribed to a channel.
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» status	channel_status_type	true	none	Status of the websocket channel
»» heartbeat_interval	heartbeat_interval_type	true	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
status	ACTIVE
status	CLOSED

Status Code 201

Name	Type	Required	Restrictions	Description
» heartbeat	object	true	none	none
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades

Status Code 202

Name	Type	Required	Restrictions	Description
» trade	object	true	none	none
»» trade_id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» seq_number	sequence_type	false	none	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.
»» order_id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» order_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» order	order_data_type	false	none	This schema represents all information of an order
»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»»» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»»» arrived_at	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»» order_status	order_status_type	false	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»» trade	trade_type	false	none	none
»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»» leg_1_status	trade_leg_status_type	false	none	none
»»» leg_2_status	trade_leg_status_type	false	none	none
»» history_done	boolean	false	none	none

Enumerated Values

Property	Value
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED

Status Code 400

Name	Type	Required	Restrictions	Description
» channel_subscription_error	object	true	none	Message received when the subscription to a channel has failed
»» header	header_type	true	none	Header used for all websocket messages
»»» channel	channel_type	true	none	Name of the websocket channel
»»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
»» error_text	error_text_type	false	none	Text describing the Error

Enumerated Values

Property	Value
channel	orders
channel	prices
channel	trades
error	Unauthorized
error	InternalServerError
error	Conflict
error	UnprocessableEntity
error	DuplicateReq
error	InvalidOrder
error	MixedOrders
error	InvalidAmount
error	AmountTooLow
error	AmountTooAccurate
error	AmountTooHigh
error	NoPriceStream
error	RiskCheck
error	DuplicateOrderRef
error	NotFound
error	Forbidden
error	ValidationError

Status Code 403

Name	Type	Required	Restrictions	Description
» reject_message	object	true	none	A message through the WebSocket that gives information on a rejected request and the reason of rejection.
»» rejection_reason	rejection_reason_type	true	none	Message used to describe the reason that a request gets rejected.
»» rejection_text	rejection_text_type	true	none	Message used to explain the reason that a request gets rejected.
»» request_ref	request_ref_type	true	none	Reference used to refer to a request that was done.
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

Get Risk Figures

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/v1/riskfigures/report"
rest_api_header = {
  "Authorization": "Bearer " + MY_TOKEN
}

bulk_order_request = requests.get(url=URL, headers=rest_api_header)

print(json.dumps(bulk_order_request.json(), indent=4))

GET /api/v1/riskfigures/report

Trading is facilitated according to risk limits, where a collateral agreement (=margin parameter) is contractually specified. To enable trading, collateral has to be placed with Bankhaus Scheich & tradias, which defines the trading line. Whenever an order execution causes a breach of the risk limits, the order is rejected with a message asking for a collateral increase. In order to avoid such situations, it is recommended to closely monitor the collateral and trading line. This functionality is provided through the Get Risk Figures endpoint.

This exposure is always measured in euro. The field exposure_in_eur contains the exposure of the current unsettled position.

The maximum_allowed_exposure is the highest exposure in euro the trading line allows. The maximum_allowed_exposure is computed using your current collateral and the “margin parameter”.

The margin_usage represents the current utilization of the collateral and trading line (margin_usage = exposure_in_eur / maximum_allowed_exposure). The closer it gets to 1, the closer you are to reaching your risk limits.

The field margin_requirement equals the exposure_in_eur in relation to collateral and trading line, and expresses the amount of collateral currently in use to secure the position (measured in euro).

In order to assure the possibility to keep trading, verify that your trades do not cause the margin_usage to get too close to 1! Trading is halted when the margin_usage > 1.

Example responses

200 Response

{
  "risk_figures_response": {
    "exposure_in_eur": 123456.78,
    "maximum_allowed_exposure": 1000000,
    "margin_requirement": 12345.68,
    "margin_usage": 0.123456
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Risk Figures Response	Inline
401	Unauthorized	Unauthorized	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Risk Figures Response

Name	Type	Required	Restrictions	Description
» risk_figures_response	object	true	none	none
»» exposure_in_eur	fiat_amount_type	true	none	A positive Fiat Currency amount with 15 digits number and 3 digits decimal fraction. It does not allow negative values.
»» maximum_allowed_exposure	fiat_amount_type	true	none	A positive Fiat Currency amount with 15 digits number and 3 digits decimal fraction. It does not allow negative values.
»» margin_requirement	number	true	none	The collateral currently in use to secure your exposure.
»» margin_usage	number	true	none	The usage of your margin as a fraction.

Historic Data

In order to read out the history of your orders and trades, you can call the endpoints in the ‘Historic Data’ section. The section consists of the following endpoints:

Order History
Get Orders By Sequence ID
Trade History
Get Trades By Sequence ID

There are various ways to filter orders and trades, which can be applied in combination. The explanation on how to use the filters is given in the sections describing the endpoints.

Both historic orders and historic trades each have an endpoint for multifunctional filtering as well as an endpoint supporting a sequence ID filtering. You can either find orders or trades. While the multifunctional filtering can be applied when searching specific entries, the filtering by sequence ID’s allows the building (or rebuilding) or the order and trade histories (e.g. for balance computation or reconciliation purposes).

Get Orders

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/orders

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

filter_params = {
    "from_datetime": "2023-10-20T11:20:21.000000Z",
    "to_datetime": "2023-10-20T15:20:21.000000Z",
    "side": "BUY",
    "type": "MARKET"
}

get_orders_request = requests.get(url=URL, headers=rest_api_header, params=filter_params)

print(json.dumps(get_orders_request.json(), indent=4))

GET /api/orders

This endpoint enables highly customizable queries on historic order data. The response from this endpoint is a list of orders that fit the criteria given by the filters that were passed in the request. It is possible to filter for specific values of keys that were passed in the order request, it is also possible to filter by timestamp and to set a limit on the amount of orders returned by the endpoint.

If some orders are not shown due to the limit, the key ‘more’ will take the value true, if not, it will take the value false.

If a complete timeseries of orders is the desired outcome, is is recommended to query not by timestamp, but by sequence number using another endpoint: Get Orders By Sequence ID. The child orders of a bulk order are also visible in from the response of the Get Orders and Get Orders By Sequence ID endpoint.

Parameters

Name	In	Type	Required	Description
from_datetime	query	timestamp_type	true	Select orders which arrived at Tradias after the timestamp given here
to_datetime	query	timestamp_type	true	Select orders which arrived at Tradias before the timestamp given here
side	query	side_type	false	Select only orders from the given side
type	query	order_type_type	false	Select only orders of the given order type
status	query	order_status_type	false	Select only orders which have a given order status
order_id	query	internal_ref_type	false	Select an order which has the given order ID (order_id given by Tradias to the order)
order_ref	query	external_ref_type	false	Select an order which has the given order ref (order_ref given to the order by the API user)
req_id	query	unique_req_type	false	Select an order which has the given request ID (req_id given to the order by the API user)
instrument	query	instrument_type	false	Select orders which have the given instrument
limit	query	integer	false	Pagination Logic - maximal number of orders returned by this request (page)
skip	query	integer	false	Pagination Logic - number of pages to skip. The first page is 0 (no skip)

Enumerated Values

Parameter	Value
side	BUY
side	SELL
type	MARKET
type	LIMIT
type	BULK_MARKET
status	UNSPECIFIED
status	RECEIVED
status	CONFIRMED
status	DUPLICATE
status	REJECTED
status	OPEN
status	UPDATED
status	CANCELLED
status	EXPIRED
status	DONE

Example responses

200 Response

{
  "get_orders_response": {
    "orders": [
      {
        "order_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
        "seq_number": 47110815,
        "order_ref": "18955839",
        "req_header": {
          "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
          "user_data": [
            {
              "tag": "Correlation-Id",
              "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
            },
            {
              "tag": "TX-Id",
              "value": "18955457"
            }
          ]
        },
        "arrived_at": "1970-01-01T00:00:00.000000Z",
        "order": {
          "instrument": "BTC-EUR/SP",
          "order_type": "LIMIT",
          "time_in_force": "FOK",
          "side": "BUY",
          "amount": {
            "leg_1_amount": "2.5"
          },
          "limit_price": "24650",
          "order_status": "DONE"
        },
        "executions": [
          {
            "trade_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
            "leg_1_executed_amount": "1.25867895",
            "leg_2_executed_amount": "1.25867895",
            "execution_price": "23768.63953056",
            "executed_at": "1970-01-01T00:00:00.000000Z",
            "leg_1_status": "PENDING",
            "leg_2_status": "SETTLED"
          }
        ]
      }
    ],
    "more": false
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Get Orders	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Get Orders Response

Name	Type	Required	Restrictions	Description
» get_orders_response	object	true	none	none
»» orders	[object]	true	none	none
»»» Order Details	object	false	none	none
»»»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» seq_number	sequence_type	true	none	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.
»»»» order_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»»»» tag	string	true	none	none
»»»»»» value	string	true	none	none
»»»» arrived_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»» order	order_data_type	true	none	This schema represents all information of an order
»»»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»»»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»»»»» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»»»»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»»»»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»»»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»»»»» arrived_at	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» order_status	order_status_type	false	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»»»» executions	[execution_type]	true	none	none
»»»»» Order Execution	execution_type	false	none	none
»»»»»» trade_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»»» leg_1_status	trade_leg_status_type	false	none	none
»»»»»» leg_2_status	trade_leg_status_type	false	none	none
»» more	boolean	false	none	none

Enumerated Values

Property	Value
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED

Get Orders By Sequence Id

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/orders/sequence"

rest_api_header = {
  "Authorization": "Bearer " + MY_TOKEN
}

params = {"seq_number": 47110815}

get_order_by_sequence_id_request = requests.get(url=URL, headers=rest_api_header, params=params)

print(json.dumps(get_order_by_sequence_id_request.json(), indent=4))

GET /api/orders/sequence

This endpoint can be used to query historic orders by the sequence numbers that are given to the orders. The response from this endpoint is a list of orders that have a sequence number in the interval passed in the request to the endpoint. Sequence numbers strictly increase (although not necessarily by 1) and are most useful when (re-)building a timeseries of the historic orders placed.

It is possible to set a limit on the amount of orders you want to have returned by the endpoint. If some orders are not shown due to the limit, the key ‘more’ will take the value true, if not, it will take the value false.

It is also possible to obtain orders via properties of the orders, however, this is done via another endpoint: Get Orders. The child orders of a bulk order are also visible in the response of the Get Orders and Get Orders By Sequence ID endpoint.

Parameters

Name	In	Type	Required	Description
seq_number	query	sequence_type	true	The sequence number from which to start the list of orders
limit	query	integer	false	Pagination Logic - maximal number of orders returned by this request (page)

Example responses

200 Response

{
  "get_orders_response": {
    "orders": [
      {
        "order_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
        "seq_number": 47110815,
        "order_ref": "18955839",
        "req_header": {
          "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
          "user_data": [
            {
              "tag": "Correlation-Id",
              "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
            },
            {
              "tag": "TX-Id",
              "value": "18955457"
            }
          ]
        },
        "arrived_at": "1970-01-01T00:00:00.000000Z",
        "order": {
          "instrument": "BTC-EUR/SP",
          "order_type": "LIMIT",
          "time_in_force": "FOK",
          "side": "BUY",
          "amount": {
            "leg_1_amount": "2.5"
          },
          "limit_price": "24650",
          "order_status": "DONE"
        },
        "executions": [
          {
            "trade_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
            "leg_1_executed_amount": "1.25867895",
            "leg_2_executed_amount": "1.25867895",
            "execution_price": "23768.63953056",
            "executed_at": "1970-01-01T00:00:00.000000Z",
            "leg_1_status": "PENDING",
            "leg_2_status": "SETTLED"
          }
        ]
      }
    ],
    "more": false
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Get Orders	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Get Orders Response

Name	Type	Required	Restrictions	Description
» get_orders_response	object	true	none	none
»» orders	[object]	true	none	none
»»» Order Details	object	false	none	none
»»»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» seq_number	sequence_type	true	none	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.
»»»» order_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»»»» tag	string	true	none	none
»»»»»» value	string	true	none	none
»»»» arrived_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»» order	order_data_type	true	none	This schema represents all information of an order
»»»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»»»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»»»»» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»»»»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»»»»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»»»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»»»»» arrived_at	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» order_status	order_status_type	false	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»»»» executions	[execution_type]	true	none	none
»»»»» Order Execution	execution_type	false	none	none
»»»»»» trade_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»»» leg_1_status	trade_leg_status_type	false	none	none
»»»»»» leg_2_status	trade_leg_status_type	false	none	none
»» more	boolean	false	none	none

Enumerated Values

Property	Value
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED

Get Trades

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/trades

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

filter_params = {
    "from_datetime": "2023-10-20T11:20:21.000000Z",
    "to_datetime": "2023-10-20T15:20:21.000000Z",
    "side": "SELL",
    "type": "MARKET",
    "instrument": "BTC-EUR/SP",
    "price_from": "24000"
}

get_trades_request = requests.get(url=URL, headers=rest_api_header, params=filter_params)

print(json.dumps(get_trades_request.json(), indent=4))

GET /api/trades

This endpoint enables highly customizable queries on historic trade data. The response from this endpoint is a list of trades that fit the criteria given by the filters that were passed in the request.

Additionally, it is possible to filter by a price (range) and the trade ID’s. It is also possible to filter by timestamp and to set a limit on the amount of trades returned by the endpoint. If some trades are not shown due to the limit, the key ‘more’ will take the value true, otherwise it will take the value false.

It is also possible to obtain trades via the sequence number, however, this is done via another endpoint: Get Trades By Sequence ID. The trades originating from a bulk order are also visible in from the response of the Get Trades and Get Trades By Sequence ID endpoint.

Parameters

Name	In	Type	Required	Description
from_datetime	query	timestamp_type	true	Select trades which have been executed after the timestamp given here
to_datetime	query	timestamp_type	true	Select trades which have been executed before the timestamp given here
instrument	query	instrument_type	false	Select orders which have the given instrument
side	query	side_type	false	Select only orders from the given side
trade_id	query	internal_ref_type	false	Select trades which have the given trade ID (trade_id)
order_id	query	internal_ref_type	false	Select trades belonging to the order with the given order ID (order_id)
order_ref	query	external_ref_type	false	Select trades belonging to the order with the given order ref (order_ref)
leg_1_status	query	trade_leg_status_type	false	The status of the leg_1 part of the trade
leg_2_status	query	trade_leg_status_type	false	The status of the leg_2 part of the trade
price_from	query	price_type	false	The starting confirmed price for the trades search
price_to	query	price_type	false	The ending confirmed price for the trades search
leg_1_from	query	quantity_type	false	The starting leg 1 amount for the trades search
leg_1_to	query	quantity_type	false	The ending leg 1 amount for the trades search
leg_2_from	query	quantity_type	false	The starting leg 2 amount for the trades search
leg_2_to	query	quantity_type	false	The ending leg 2 amount for the trades search
limit	query	integer	false	Pagination Logic - maximal number of orders returned by this request (page)
skip	query	integer	false	Pagination Logic - number of pages to skip. 0 is the first page (no skip)

Enumerated Values

Parameter	Value
side	BUY
side	SELL
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED

Example responses

200 Response

{
  "get_trades_response": {
    "trades": [
      {
        "trade_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
        "seq_number": 47110815,
        "order_id": "73f2e419-e4ac-4db2-84ab-81a12ad43d54",
        "order_ref": "18955839",
        "req_header": {
          "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
          "user_data": [
            {
              "tag": "Correlation-Id",
              "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
            },
            {
              "tag": "TX-Id",
              "value": "18955457"
            }
          ]
        },
        "order": {
          "instrument": "BTC-EUR/SP",
          "order_type": "LIMIT",
          "time_in_force": "FOK",
          "side": "BUY",
          "amount": {
            "leg_1_amount": "2.5"
          },
          "limit_price": "24650",
          "arrived_at": "1970-01-01T00:00:00.000000Z",
          "order_status": "DONE"
        },
        "execution": {
          "leg_1_executed_amount": "1.25867895",
          "leg_2_executed_amount": "1.25867895",
          "execution_price": "23768.63953056",
          "executed_at": "1970-01-01T00:00:00.000000Z",
          "leg_1_status": "PENDING",
          "leg_2_status": "SETTLED"
        }
      }
    ],
    "more": false
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Get Trades	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Get Trades Response

Name	Type	Required	Restrictions	Description
» get_trades_response	object	true	none	none
»» trades	[object]	true	none	none
»»» Trade Details	object	false	none	none
»»»» trade_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» seq_number	sequence_type	true	none	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.
»»»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» order_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»»»» tag	string	true	none	none
»»»»»» value	string	true	none	none
»»»» order	order_data_type	true	none	This schema represents all information of an order
»»»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»»»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»»»»» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»»»»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»»»»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»»»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»»»»» arrived_at	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» order_status	order_status_type	false	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»»»» trade	trade_type	true	none	none
»»»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» leg_1_status	trade_leg_status_type	false	none	none
»»»»» leg_2_status	trade_leg_status_type	false	none	none
»»»» execution	execution_type	false	none	none
»»»»» trade_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» leg_1_status	trade_leg_status_type	false	none	none
»»»»» leg_2_status	trade_leg_status_type	false	none	none
»» more	boolean	false	none	none

Enumerated Values

Property	Value
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED

Get Trades By Sequence ID

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/trades/sequence"

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

params = {"seq_number": 47110815}

get_trade_by_sequence_id_request = requests.get(url=URL, headers=rest_api_header)

print(json.dumps(get_trade_by_sequence_id_request.json(), indent=4))

GET /api/trades/sequence

This endpoint enables queries on historic trade data by sequence id. The response from this endpoint is a list of trades that have a sequence number in the interval passed in the request to the endpoint. Sequence numbers strictly increase (although not necessarily by 1) and are most useful when (re-)building a timeseries of the historic trades.

It is possible to set a limit on the amount of trades returned by the endpoint.

If some trades are not shown due to the limit, the key ‘more’ will take the value true, if not, it will take the value false. It is also possible to obtain trades via properties of the trades/orders, however, this is done via another endpoint: Get Trades. The trades originating from a bulk order are also visible in from the response of the Get Trades and Get Trades By Sequence ID endpoint.

Parameters

Name	In	Type	Required	Description
seq_number	query	sequence_type	true	The sequence number from which to start the list of trades
limit	query	integer	false	Pagination Logic - maximal number of orders returned by this request (page)

Example responses

200 Response

{
  "get_trades_response": {
    "trades": [
      {
        "trade_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
        "seq_number": 47110815,
        "order_id": "73f2e419-e4ac-4db2-84ab-81a12ad43d54",
        "order_ref": "18955839",
        "req_header": {
          "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
          "user_data": [
            {
              "tag": "Correlation-Id",
              "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
            },
            {
              "tag": "TX-Id",
              "value": "18955457"
            }
          ]
        },
        "order": {
          "instrument": "BTC-EUR/SP",
          "order_type": "LIMIT",
          "time_in_force": "FOK",
          "side": "BUY",
          "amount": {
            "leg_1_amount": "2.5"
          },
          "limit_price": "24650",
          "arrived_at": "1970-01-01T00:00:00.000000Z",
          "order_status": "DONE"
        },
        "execution": {
          "leg_1_executed_amount": "1.25867895",
          "leg_2_executed_amount": "1.25867895",
          "execution_price": "23768.63953056",
          "executed_at": "1970-01-01T00:00:00.000000Z",
          "leg_1_status": "PENDING",
          "leg_2_status": "SETTLED"
        }
      }
    ],
    "more": false
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Get Trades	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Get Trades Response

Name	Type	Required	Restrictions	Description
» get_trades_response	object	true	none	none
»» trades	[object]	true	none	none
»»» Trade Details	object	false	none	none
»»»» trade_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» seq_number	sequence_type	true	none	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.
»»»» order_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» order_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»»»» tag	string	true	none	none
»»»»»» value	string	true	none	none
»»»» order	order_data_type	true	none	This schema represents all information of an order
»»»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»»»» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
»»»»» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
»»»»» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
»»»»» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
»»»»»» leg_1_amount	quantity_type	false	none	The quantity of a leg.
»»»»»» leg_2_amount	quantity_type	false	none	The quantity of a leg.
»»»»» arrived_at	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» order_status	order_status_type	false	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
»»»» trade	trade_type	true	none	none
»»»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» leg_1_status	trade_leg_status_type	false	none	none
»»»»» leg_2_status	trade_leg_status_type	false	none	none
»»»» execution	execution_type	false	none	none
»»»»» trade_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»» leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
»»»»» execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
»»»»» executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»»»»» leg_1_status	trade_leg_status_type	false	none	none
»»»»» leg_2_status	trade_leg_status_type	false	none	none
»» more	boolean	false	none	none

Enumerated Values

Property	Value
order_type	MARKET
order_type	LIMIT
order_type	BULK_MARKET
time_in_force	FOK
time_in_force	IOC
side	BUY
side	SELL
order_status	UNSPECIFIED
order_status	RECEIVED
order_status	CONFIRMED
order_status	DUPLICATE
order_status	REJECTED
order_status	OPEN
order_status	UPDATED
order_status	CANCELLED
order_status	EXPIRED
order_status	DONE
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED
leg_1_status	UNSPECIFIED
leg_1_status	PENDING
leg_1_status	SETTLED
leg_2_status	UNSPECIFIED
leg_2_status	PENDING
leg_2_status	SETTLED

Settlement Procedure

The Settlement Request and Transactions endpoints serve to automate settlement and simplify the reconciliation. Before using the endpoints, make sure that the addresses (SSIs) for the currencies (fiat and crypto) in use for settlement are shared with tradias and whitelisted. Please inform with your contact at tradias how to share the addresses. In general, the user flow for the settlement and transactions API looks as follows:

Send one or more order(s) through the WebSocket or to the bulk order endpoint.
Collect the trade_id(s), leg_1_amount(s) and leg_2_amount(s) for each trade as well as the corresponding leg_1_asset(s) and leg_2_asset(s).
Post a settlement request via the Settlement Request endpoint: In the req_header, optionally pass a value for the req_id (this has to be a UUID), this will have an idempotency property. From the response, obtain the settlement_request_id, which is needed to use the Get Settlement Request and Map Transaction With Settlement Request Amount endpoints.
Get the status of the settlement request using the Get Settlement Request Status endpoint. As the settlement requests are processed asynchronously, this endpoint serves as a check on the completion of the processing of the settlement request. The response of such a call is either ‘CONFIRMED’, ‘PARTIALLY’, ‘SETTLED’ or ‘REJECTED’.
Get the settlement request by passing the settlement_request_id in the Get Settlement Request endpoint call. The response contains all information on the settlement request, such as which amounts are settled or why a settlement request was rejected.
The confirmation of a settlement request implies the intention to settle each settlement_request_amount in the settlement request to and from the respective senders and receivers. For settlement to be completed, each settlement_request_amount needs to be associated with one or more transactions.
Initiate your settlement transactions through your bank and/or custodian. Save the reference used to identify the transaction uniquely on the channel used (e.g. SEPA reference, On-Chain Transaction IDs).
Get the transactions: using the Get Settlement Transactions endpoint, all transactions arrived at or sent from tradias & Bankhaus Scheich to you and corresponding transaction_id’s can be viewed.
Patch transactions with settlement request amount: using the endpoint Map Transaction With Settlement Request Amount, an amount from a transaction can be mapped to a settlement request. This amount does not have to be precisely the amount in the transaction, nor does it have to be exactly the amount in the settlement request. However, the amount can not exceed the outstanding amount in the transaction, nor the amount in the settlement request. This only applies to transactions from you to Bankhaus Scheich/tradias, transactions to you will be mapped automatically.

In the case the the netted settlement amount for a specific asset traded adds to 0, a settlement request amount with the amount set to 0 should be included in the corresponding settlement request. Such a settlement request amount would take the following format: { “currency”: “The asset code for which the amount to be settled is 0”, “from_address”: “BHS”, “to_address”: “Your address”, “amount”: “0” }

Whenever there is a rejection of a settlement request, you will be able to see this when querying the Get Settlement Request endpoint. If there are unknown trades, already settled trades or trades that are already in another uncompleted settlement request, you will be able to see this in the response. Also, you are able to see the validity of addresses and computed amounts in the response. These fields can be used to understand the reasons behind the failure of the confirmation of the settlement request.

Settlement Request

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/settlement-requests"

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

payload = {
    "req_header": {
        "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
        "user_data": [
            {
                "tag": "Correlation-Id",
                "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
            },
            {
                "tag": "TX-Id",
                "value": "18955457"
            }
        ]
    },
    "settlement_request_ref": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "trade_ids": [
        "2987a674-fa91-4bcb-b480-24934bc4166c",
        "a83ceb8f-a7cd-46c6-8322-826a21f56511",
        "94f7b459-ae19-4600-8d72-9a21c78b86f4"
    ],
    "request_amounts": [
        {
            "currency": "EUR",
            "from_address": "BHS",
            "to_address": "DE89370400440532013000",
            "amount": "12766.04"
        },
        {
            "currency": "LTC",
            "from_address": "BHS",
            "to_address": "MGxNPPB7eBoWPUaprtX9v9CXJZoD2465zN",
            "amount": "207.606"
        },
        {
            "currency": "BTC",
            "from_address": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq",
            "to_address": "BHS",
            "amount": "1.23"
        }
    ]
}

post_settlement_request = requests.post(url=URL, json=payload, headers=rest_api_header)
print(json.dumps(post_settlement_request.json(), indent=4))

POST /api/settlement-requests

Tradias offers post-trade settlement. The settlement process with tradias is completely automatable. Depending on the setup, settlement is typically done T+1 or T+2. The settlement procedure consists of the following steps:

Post a settlement request which includes all trades that you want to/have to settle and the corresponding amounts and addresses per currency/asset.
When the system agrees on the amounts (this is checked based on the trades included in the request) and the addresses and there are no unknown or conflicting trades, the settlement request is accepted.
Both you and tradias do the necessary settlement transactions.
You map the transactions to the settlement request of your choice.
Once all amounts in the settlement request have a transaction and amount mapped to it that covers the amount to be settled, the settlement request status changes to ‘settled’ and the settlement is complete.

It is possible to include several settlement request amounts with the same currency but difference from and to addresses. In such a case the reconciliation is based on the sum of these amounts.

As is the case for other REST requests, you can use the “req_id” as an idempotency key and “user_data” to pass any additional information of your choice.

In case a settlement request is rejected, a new settlement request has to be created. There can be several reasons for a rejection. If a settlement request is rejected due to one of the following reasons, it will be visible in the response of the Get Settlement Request endpoint:

Unknown trades: you have included a trade_id that is not known to our system.
Conflicting trades: you have included a trade_id that is also included in a settlement request that is already pending.
Already settled trades: you have included a trade_id that is also included in a settlement request that is already settled.
Invalid address: you have included an address that is not in our system.
Incorrect amounts: you have included an amount to be settled that is different than the amount that we computed. The amounts are computed solely based on the trades that you passed in the settlement request.

Note that it is not required to settle in the order in which the trading occurred, however, it is not possible to leave trades unsettled for more than 5 business days.

Body parameter

{
  "settlement_request": {
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "settlement_request_ref": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "trade_ids": [
      "2987a674-fa91-4bcb-b480-24934bc4166c",
      "a83ceb8f-a7cd-46c6-8322-826a21f56511",
      "94f7b459-ae19-4600-8d72-9a21c78b86f4"
    ],
    "settlement_amounts": [
      {
        "currency": "EUR",
        "from_address": "BHS",
        "to_address": "DE89370400440532013000",
        "amount": "12766.04"
      },
      {
        "currency": "LTC",
        "from_address": "BHS",
        "to_address": "MGxNPPB7eBoWPUaprtX9v9CXJZoD2465zN",
        "amount": "207.606"
      },
      {
        "currency": "BTC",
        "from_address": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq",
        "to_address": "BHS",
        "amount": "1.23"
      }
    ]
  }
}

Parameters

Name	In	Type	Required	Description
body	body	object	true	none
» settlement_request	body	object	true	none
»» req_header	body	req_header_type	false	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	body	unique_req_type	false	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	body	[object]	false	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	body	string	true	none
»»»» value	body	string	true	none
»» settlement_request_ref	body	external_ref_type	true	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» trade_ids	body	[internal_ref_type]	true	List of all trade_ids which net to the settlement amounts contained in
»»» Internal Reference or Id	body	internal_ref_type	false	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» settlement_amounts	body	[object]	true	Array containing the individual net amounts of the settlement
»»» Settlement Amount	body	object	false	none
»»»» currency	body	asset_code_type	true	Identifier of a leg of an instrument
»»»» from_address	body	address_type	true	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» to_address	body	address_type	true	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» amount	body	quantity_type	true	The quantity of a leg.

Detailed descriptions

»» trade_ids: List of all trade_ids which net to the settlement amounts contained in the request_amounts field.

Example responses

202 Response

{
  "settlement_request_response": {
    "settlement_request_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "settlement_request_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "timestamp": "1970-01-01T00:00:00.000000Z",
    "settlement_status": "RECEIVED"
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

409 Response

{
  "error_req_header": {
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "tradias_id": "75ccdf76-ae4b-11ed-85ee-81a12bb57b04",
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "DuplicateReq",
    "error_text": "The req_id has been already processed"
  }
}

422 Response

{
  "error_req_header": {
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "tradias_id": "75ccdf76-ae4b-11ed-85ee-81a12bb57b04",
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "UnprocessableEntity",
    "error_text": "The request is not processable"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
202	Accepted	Settlement Status Response - Short Version	Inline
401	Unauthorized	Unauthorized	internal_error_type
409	Conflict	Duplicate Request	internal_req_error_type
422	Unprocessable Entity	Unprocessable Entity	internal_req_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 202

Settlement Request Response

Name	Type	Required	Restrictions	Description
» settlement_request_response	object	true	none	none
»» settlement_request_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» settlement_request_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» settlement_status	settlement_status_type	true	none	Status of a settlement. In case the trades in the settlement request are ok and result in the correct amounts, the value will be CONFIRMED. The value switches to “PARTIALLY”, once the transaction has been made and to SETTLED if all transactions have been successfully executed. In case if there is a problem with the settlement its status will be REJECTED. When the settlement request has just been sent the status will be RECEIVED. This status is also been used to reflect the status of each amount (transaction) of a settlement. In this case the state PARTIALLY will not been used.

Enumerated Values

Property	Value
settlement_status	RECEIVED
settlement_status	REJECTED
settlement_status	CONFIRMED
settlement_status	PARTIALLY
settlement_status	SETTLED

Get Settlement Request Status (Coming Soon)

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "PREPROD"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

settlement_request_id = "13bd7e32-4a43-4112-9002-38c402a2fb11"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/settlement-requests/{settlement_request_id}/status"

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

settlement_request_status = requests.get(url=URL, headers=rest_api_header)
print(json.dumps(setllement_request_status.json(), indent=4))

GET /api/settlement-requests/{settlement_request_id}/status

This endpoint can be used to query the status of a settlement request after posting it to the Settlement Request endpoint. Both the Get Settlement Request and Get Settlement Request Status endpoints can be used to query information on a posted settlement request. The difference between the endpoints is that the Get Settlement Request Status returns a more compact response than the Get Settlement Request endpoint. In particular, the Get Settlement Request Status returns some basic information on the settlement request together with the status. The Get Settlement Request endpoint returns all information on the settlement request, including linked transactions. The Get Settlement Request Status is therefore more useful when polling the endpoint to check for completion of the settlement.

The possible status that can be returned are the following:

CONFIRMED: the settlement request is received and the trades, amounts and addresses are correct.
PARTIALLY SETTLED: the settlement request is accepted and some (but not all) of the amounts to be settled have been settled.
SETTLED: the settlement request is accepted and all amounts to be settled are settled.
REJECTED: the status will change to this when there is a problem with the request.

Parameters

Name	In	Type	Required	Description
settlement_request_id	path	internal_ref_type	true	none

Example responses

200 Response

{
  "settlement_request_response": {
    "settlement_request_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "settlement_request_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "timestamp": "1970-01-01T00:00:00.000000Z",
    "settlement_status": "PARTIALLY",
    "settlement_amounts": [
      {
        "settlement_request_amount_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
        "currency": "BTC",
        "from_address": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq",
        "to_address": "BHS",
        "amount": "1.23",
        "expected_amount": "1.23",
        "status": "PARTIALLY",
        "transactions": [
          {
            "tx_id": "265a2482-bf2f-11ed-8f96-eac8fe84d40c",
            "reference_type": "ON_CHAIN_TX_ID",
            "reference": "1b82e950aebfd74ab6508538f2138cf4ab0b904a9a3c93ad2df209e5f78d1ea9",
            "amount": "1.00"
          }
        ]
      },
      {
        "settlement_request_amount_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
        "currency": "EUR",
        "from_address": "BHS",
        "to_address": "DE89370400440532013000",
        "amount": "18453.45",
        "expected_amount": "18453.45",
        "status": "SETTLED",
        "transactions": [
          {
            "tx_id": "0d87d88e-b17a-11ed-9c9d-cc17d418c9e0",
            "reference_type": "SEPA_REFERENCE",
            "reference": "44053201300089370400440532013",
            "amount": "18453.45"
          }
        ]
      }
    ]
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Settlement Status Response	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Settlement Request Response

Name	Type	Required	Restrictions	Description
» settlement_request_response	object	true	none	none
»» settlement_request_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» settlement_request_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» settlement_status	settlement_status_type	true	none	Status of a settlement. In case the trades in the settlement request are ok and result in the correct amounts, the value will be CONFIRMED. The value switches to “PARTIALLY”, once the transaction has been made and to SETTLED if all transactions have been successfully executed. In case if there is a problem with the settlement its status will be REJECTED. When the settlement request has just been sent the status will be RECEIVED. This status is also been used to reflect the status of each amount (transaction) of a settlement. In this case the state PARTIALLY will not been used.
»» settlement_amounts	[settlement_amount_type]	true	none	Array containing the individual net amounts of the settlement
»»» Settlement Amount	settlement_amount_type	false	none	none
»»»» settlement_request_amount_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» currency	asset_code_type	true	none	Identifier of a leg of an instrument
»»»» from_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» to_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» amount	quantity_type	true	none	The quantity of a leg.
»»»» expected_amount	quantity_type	true	none	The quantity of a leg.
»»»» status	settlement_status_type	true	none	Status of a settlement. In case the trades in the settlement request are ok and result in the correct amounts, the value will be CONFIRMED. The value switches to “PARTIALLY”, once the transaction has been made and to SETTLED if all transactions have been successfully executed. In case if there is a problem with the settlement its status will be REJECTED. When the settlement request has just been sent the status will be RECEIVED. This status is also been used to reflect the status of each amount (transaction) of a settlement. In this case the state PARTIALLY will not been used.
»»»» transactions	[transaction_type]	false	none	A list of transactions that have been made and associated with this settlement request amount
»»»»» Transaction Data	transaction_type	false	none	none
»»»»»» tx_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»»» reference_type	transaction_ref_type_type	true	none	Type of the reference of a transaction
»»»»»» reference	transaction_ref_type	true	none	This field is used by the API user to pass an reference or ID of a Transaction. It is either the reference field of an FIAT money transaction or in case of a crypto asset transfer the hash or ID of the blockchain transaction.
»»»»»» amount	quantity_type	true	none	The quantity of a leg.

Enumerated Values

Property	Value
settlement_status	RECEIVED
settlement_status	REJECTED
settlement_status	CONFIRMED
settlement_status	PARTIALLY
settlement_status	SETTLED
status	RECEIVED
status	REJECTED
status	CONFIRMED
status	PARTIALLY
status	SETTLED
reference_type	ON_CHAIN_TX_ID
reference_type	SEPA_REFERENCE
reference_type	SEPA_DESCRIPTION
reference_type	SEPA_END_TO_END_ID

Get Settlement Request

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

settlement_request_id = "13bd7e32-4a43-4112-9002-38c402a2fb11"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/settlement-requests/{settlement_request_id}/status"

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

settlement_request_status = requests.get(url=URL, headers=rest_api_header)
print(json.dumps(settlement_request_status.json(), indent=4))

GET /api/settlement-requests/{settlement_request_id}

This endpoint can be used to query information on a settlement request after posting it to the Settlement Request endpoint. Both the Get Settlement Request and Get Settlement Request Status endpoints can be used to query information on a posted settlement request. The difference between the endpoints is that the Get Settlement Request Status returns a more compact response than the Get Settlement Request endpoint. In particular, the Get Settlement Request Status returns some basic information on the settlement request together with the status. The Get Settlement Request endpoint returns all information on the settlement request, including linked transactions. The Get Settlement Request Status is therefore more useful when polling the endpoint to check the processing status or completion of the settlement request.

Parameters

Name	In	Type	Required	Description
settlement_request_id	path	internal_ref_type	true	none

Example responses

200 Response

{
  "get_settlement_request": {
    "settlement_request_id": "92ec4900-8da5-4700-a28c-2c1f2b32b914",
    "settlement_request_ref": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "timestamp": "1970-01-01T00:00:00.000000Z",
    "settlement_status": "PARTIALLY",
    "trades_ok": [
      "2987a674-fa91-4bcb-b480-24934bc4166c",
      "a83ceb8f-a7cd-46c6-8322-826a21f56511",
      "94f7b459-ae19-4600-8d72-9a21c78b86f4"
    ],
    "settlement_amounts": [
      {
        "settlement_request_amount_id": "99859305-be58-11ed-99a9-ba16c3846fc3",
        "currency": "LTC",
        "from_address": "BHS",
        "to_address": "MGxNPPB7eBoWPUaprtX9v9CXJZoD2465zN",
        "amount": "207.606",
        "expected_amount": "207.606",
        "status": "SETTLED",
        "transactions": [
          {
            "tx_id": "73b0b7f2-bd94-11ed-bef0-ba16c3846fc3",
            "reference": "d8a8b5c19200417cfad98b30423737cad7a27b40bd19bdec89620e953748f189",
            "amount": "207.606"
          }
        ]
      },
      {
        "settlement_request_amount_id": "81a108fc-3181-4e29-a2aa-9464cd77f0fe",
        "currency": "EUR",
        "from_address": "BHS",
        "to_address": "DE89370400440532013000",
        "amount": "12766.04",
        "expected_amount": "12766.04",
        "status": "CONFIRMED"
      },
      {
        "settlement_request_amount_id": "febf879f-11e8-41e1-a909-6438593b154a",
        "currency": "BTC",
        "from_address": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq",
        "to_address": "BHS",
        "amount": "1.23",
        "expected_amount": "1.23",
        "status": "PARTIALLY",
        "transactions": [
          {
            "tx_id": "265a2482-bf2f-11ed-8f96-eac8fe84d40c",
            "reference": "1b82e950aebfd74ab6508538f2138cf4ab0b904a9a3c93ad2df209e5f78d1ea9",
            "amount": "0.6"
          },
          {
            "tx_id": "0d87d88e-b17a-11ed-9c9d-cc17d418c9e0",
            "reference": "2de370af4083d27328ff0036af8b3e577c71cce5eae9e597d3106c2fa54d0b97",
            "amount": "0.5"
          }
        ]
      }
    ]
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Get Settlement Request	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Get Settlement Request

Name	Type	Required	Restrictions	Description
» get_settlement_request	object	true	none	none
»» settlement_request_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» settlement_request_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»» tag	string	true	none	none
»»»» value	string	true	none	none
»» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
»» settlement_status	settlement_status_type	true	none	Status of a settlement. In case the trades in the settlement request are ok and result in the correct amounts, the value will be CONFIRMED. The value switches to “PARTIALLY”, once the transaction has been made and to SETTLED if all transactions have been successfully executed. In case if there is a problem with the settlement its status will be REJECTED. When the settlement request has just been sent the status will be RECEIVED. This status is also been used to reflect the status of each amount (transaction) of a settlement. In this case the state PARTIALLY will not been used.
»» trades_unknown	[internal_ref_type]	false	none	List of all trade_ids from the settlement request which are not known by tradias
»»» Internal Reference or Id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» trades_conflicting	[internal_ref_type]	false	none	List of all trade_ids from the settlement request which are in a conflicting state with another settlement request, i.e. in a pending settlement state
»»» Internal Reference or Id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» trades_already_settled	[internal_ref_type]	false	none	List of all trade_ids from the settlement request which have already been settled previously
»»» Internal Reference or Id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» trades_ok	[internal_ref_type]	false	none	List of all trade_ids from the settlement request which are OK
»»» Internal Reference or Id	internal_ref_type	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»» settlement_amounts	[object]	true	none	Array containing the individual net amounts of the settlement
»»» Settlement Amount	object	false	none	none
»»»» settlement_request_amount_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» currency	asset_code_type	true	none	Identifier of a leg of an instrument
»»»» from_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» to_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» amount	quantity_type	true	none	The quantity of a leg.
»»»» expected_amount	quantity_type	true	none	The quantity of a leg.
»»»» status	settlement_status_type	true	none	Status of a settlement. In case the trades in the settlement request are ok and result in the correct amounts, the value will be CONFIRMED. The value switches to “PARTIALLY”, once the transaction has been made and to SETTLED if all transactions have been successfully executed. In case if there is a problem with the settlement its status will be REJECTED. When the settlement request has just been sent the status will be RECEIVED. This status is also been used to reflect the status of each amount (transaction) of a settlement. In this case the state PARTIALLY will not been used.
»»»» transactions	[object]	false	none	A list of transactions that have been made and associated with this settlement request amount
»»»»» List of Transactions	object	false	none	none
»»»»»» tx_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»»» reference	transaction_ref_type	true	none	This field is used by the API user to pass an reference or ID of a Transaction. It is either the reference field of an FIAT money transaction or in case of a crypto asset transfer the hash or ID of the blockchain transaction.
»»»»»» amount	quantity_type	true	none	The quantity of a leg.

Enumerated Values

Property	Value
settlement_status	RECEIVED
settlement_status	REJECTED
settlement_status	CONFIRMED
settlement_status	PARTIALLY
settlement_status	SETTLED
status	RECEIVED
status	REJECTED
status	CONFIRMED
status	PARTIALLY
status	SETTLED

Get Settlement Transactions

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/transactions

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

params = {
    "from_datetime": "2023-10-20T11:20:21.000000Z",
    "to_datetime": "2023-10-20T15:20:21.000000Z"
}

settlement_request_transactions = requests.get(url=URL, headers=rest_api_header, params=params)
print(json.dumps(settlement_request_transactions.json(), indent=4))

GET /api/transactions

There are two endpoints concerning transactions. The Get Settlement Transactions endpoint can be used to see the transactions and information on the transactions known to the tradias system and belong to the user that queries the endpoint. The Map Transaction With Settlement Request Amount endpoint can be used to map (part of) the amount belonging to the transaction to an existing settlement_request_amount which is in the settlement request.

There are several parameters that can be used for filtering the transactions. The from_datetime and to_datetime are required parameters, the other ones are optional.

Parameters

Name	In	Type	Required	Description
from_datetime	query	timestamp_type	true	Select transactions where the settlement has been started after the given timestamp
to_datetime	query	timestamp_type	true	Select transactions where the settlement has been started before the given timestamp
amount_from	query	quantity_type	false	Select transactions with a transaction amount higher than the given amount
amount_to	query	quantity_type	false	Select transactions with a transaction amount lower than the given amount
transaction_id	query	internal_ref_type	false	Select transactions with the given transaction ID
currency	query	asset_code_type	false	Select transactions with the given currency
settlement_id	query	internal_ref_type	false	Select transactions with the given settlement ID
settlement_ref	query	external_ref_type	false	Select transactions with the given settlement reference
direction	query	direction_type	false	Select transactions where the API user is either SENDER or RECEIVER
limit	query	integer	false	Pagination Logic - maximal number of orders returned by this request (page)
skip	query	integer	false	Pagination Logic - number of pages to skip. 0 is the first page (no skip)

Enumerated Values

Parameter	Value
direction	SEND
direction	RECEIVE

Example responses

200 Response

{
  "get_transaction_list": {
    "transactions": [
      {
        "transaction_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
        "transaction_ref": "c8d16891-b669-11ed-bc43-f1002b6e6125",
        "req_header": {
          "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
          "user_data": [
            {
              "tag": "Correlation-Id",
              "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
            },
            {
              "tag": "TX-Id",
              "value": "18955457"
            }
          ]
        },
        "amount": "1.25867895",
        "reference": "a38ca981-b669-11ed-bc43-cb132b8d1265",
        "reference_type": "ON_CHAIN_TX_ID",
        "timestamp": "2019-08-24T14:15:22Z",
        "from_address": "string",
        "to_address": "string",
        "currency": "BTC",
        "settlement_requests": [
          {
            "settlement_request_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
            "settlement_request_amount_id": "6aa21c20-ae4b-11ed-b304-81a12bb57b04",
            "amount": "1.25867895"
          }
        ]
      }
    ],
    "more": true
  }
}

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "ValidationError",
    "error_text": "The request is not valid"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Successful Response	Inline
401	Unauthorized	Unauthorized	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Request	internal_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Status Code 200

Get List of Transactions

Name	Type	Required	Restrictions	Description
» get_transaction_list	object	true	none	none
»» transactions	[complete_transaction_type]	true	none	none
»»» Complete Transaction Data	complete_transaction_type	false	none	none
»»»» transaction_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»» transaction_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
»»»» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
»»»»» req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
»»»»» user_data	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
»»»»»» tag	string	true	none	none
»»»»»» value	string	true	none	none
»»»» amount	quantity_type	true	none	The quantity of a leg.
»»»» reference	transaction_ref_type	true	none	This field is used by the API user to pass an reference or ID of a Transaction. It is either the reference field of an FIAT money transaction or in case of a crypto asset transfer the hash or ID of the blockchain transaction.
»»»» reference_type	transaction_ref_type_type	true	none	Type of the reference of a transaction
»»»» timestamp	string(date-time)	true	none	none
»»»» from_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» to_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
»»»» currency	asset_code_type	true	none	Identifier of a leg of an instrument
»»»» settlement_requests	[object]	true	none	List of references to settlement requests in which this transaction is used for settlement
»»»»» Settlement Request	object	false	none	Reference to an amount in a settlement request
»»»»»» settlement_request_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»»» settlement_request_amount_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
»»»»»» amount	quantity_type	true	none	The quantity of a leg.
»» more	boolean	false	none	none

Enumerated Values

Property	Value
reference_type	ON_CHAIN_TX_ID
reference_type	SEPA_REFERENCE
reference_type	SEPA_DESCRIPTION
reference_type	SEPA_END_TO_END_ID

Map Transaction With Settlement Request Amount

Code samples

import requests
import json

PROTOCOL = "https"
ENVIRONMENT = "preprod"
MY_TOKEN = "ENTER YOUR TOKEN HERE"

settlement_request_id = "514704a5-848e-4211-a7ce-ec388e122882"

URL = f"{PROTOCOL}://api.{ENVIRONMENT}.tradias.link/api/transactions/{settlement_request_id}"

rest_api_header = {
    "Authorization": "Bearer " + MY_TOKEN
}

settlement_request_transactions = requests.patch(url=URL, headers=rest_api_header, json={
    "settlement_request_amount_id": "76b8c625-d540-42cc-96e4-ee97658d918b",
    "amount": "1151.01"
})

print(json.dumps(settlement_request_transactions.json(), indent=4))

PATCH /api/transaction/{transaction_id}

This endpoint is used to map a transaction to a settlement request amount. Once you have the desired transaction_id, settlement_request_amount_id and the amount from the transaction that you want to map to the settlement request amount, you can combine this information to a request to this endpoint. As a result of this, the transaction is mapped to the settlement request. This will also be visible when querying the Get Settlement Request endpoint.

Body parameter

{
  "settlement_request_amount_id": "dc1be491-9492-46bf-a40b-51e5e69e1473",
  "amount": "51"
}

Parameters

Name	In	Type	Required	Description
transaction_id	path	internal_ref_type	true	none
body	body	object	true	none
» settlement_request_amount_id	body	string	true	The unique identifier of the settlement request amount.
» amount	body	string	false	The amount to use from the transaction for this settlement request amount.

Example responses

200 Response

null

401 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Unauthorized",
    "error_text": "The JWT token could not be validated"
  }
}

403 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "Forbidden",
    "error_text": "Action is forbidden."
  }
}

404 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "NotFound",
    "error_text": "The given object (Order, Trade, ...) could not be found."
  }
}

422 Response

{
  "error_req_header": {
    "req_header": {
      "req_id": "ca57eead-b699-11ed-b3ff-cc17d418c9e0",
      "user_data": [
        {
          "tag": "Correlation-Id",
          "value": "c8d16891-b669-11ed-bc43-f1002b6e6125"
        },
        {
          "tag": "TX-Id",
          "value": "18955457"
        }
      ]
    },
    "tradias_id": "75ccdf76-ae4b-11ed-85ee-81a12bb57b04",
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "UnprocessableEntity",
    "error_text": "The request is not processable"
  }
}

500 Response

{
  "error": {
    "timestamp": "2023-01-20T14:31:10.012123Z",
    "error": "InternalServerError",
    "error_text": "Internal Server Error: the server can currently not process the request"
  }
}

Responses

Status	Meaning	Description	Schema
200	OK	Successful Response	Inline
401	Unauthorized	Unauthorized	internal_error_type
403	Forbidden	Forbidden	internal_error_type
404	Not Found	Not Found	internal_error_type
422	Unprocessable Entity	Unprocessable Entity	internal_req_error_type
500	Internal Server Error	Internal Server Error	internal_error_type

Response Schema

Schemas

instrument_type

BTC-EUR/SP

Identifier for an instrument.
It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]

Properties

Name	Type	Required	Restrictions	Description
anonymous	string	false	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]

rejection_reason_type

INVALID REQUEST

Rejection Reason

Properties

Name	Type	Required	Restrictions	Description
Rejection Reason	string	false	none	Message used to describe the reason that a request gets rejected.

rejection_text_type

The format of the request sent is not parseable

Rejection Text

Properties

Name	Type	Required	Restrictions	Description
Rejection Text	string	false	none	Message used to explain the reason that a request gets rejected.

request_ref_type

TX-1001

Reference to a request

Properties

None

asset_code_type

BTC

Identifier of a leg of an instrument

Properties

Name	Type	Required	Restrictions	Description
anonymous	string	false	none	Identifier of a leg of an instrument

asset_tenor_type

SP

Identifier of a tenor.
The following tenors are supported * SP = Spot

Properties

Name	Type	Required	Restrictions	Description
anonymous	string	false	none	Identifier of a tenor. The following tenors are supported * SP = Spot

asset_name_type

Bitcoin

Name of a leg of an instrument

Properties

Name	Type	Required	Restrictions	Description
anonymous	string	false	none	Name of a leg of an instrument

asset_precision_type

The number of digits after the decimal point which are allowed for a quantity.

Properties

Name	Type	Required	Restrictions	Description
anonymous	integer	false	none	The number of digits after the decimal point which are allowed for a quantity.

asset_type

name: Bitcoin
code: BTC
precision: 8

Asset

Properties

Name	Type	Required	Restrictions	Description
name	asset_name_type	true	none	Name of a leg of an instrument
code	asset_code_type	true	none	Identifier of a leg of an instrument
precision	asset_precision_type	true	none	The number of digits after the decimal point which are allowed for a quantity.

address_type

string

Fiat Account Number or Crypto Wallet Key

Properties

Name	Type	Required	Restrictions	Description
Fiat Account Number or Crypto Wallet Key	string	false	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.

quantity_type

"1.25867895"

Quantity

Properties

Name	Type	Required	Restrictions	Description
Quantity	string	false	none	The quantity of a leg.

price_type

"23768.63953056"

Price

Properties

Name	Type	Required	Restrictions	Description
Price	string	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.

counter_leg_precision_type

999999999999999

Counter leg precision

Properties

Name	Type	Required	Restrictions	Description
Counter leg precision	number	false	none	This optional key can be given in a new order request. The value specifies the number of decimals you want the computed amount of the leg that is not yet specified in the order request to be rounded to. For example, if you give the amount you want to buy/sell in the leg 2 asset, the counter_leg_precision specifies the number of decimals you want the leg 1 amount to be rounded to. Vice versa, if you specify the amount to buy/sell in the leg 1 asset, the amount in the leg 2 asset will be rounded to the specified number in the counter_leg_precision field.

fiat_amount_type

47118.15

Amount of a Fiat Currency

Properties

Name	Type	Required	Restrictions	Description
Amount of a Fiat Currency	number	false	none	A positive Fiat Currency amount with 15 digits number and 3 digits decimal fraction. It does not allow negative values.

timestamp_type

1970-01-01T00:00:00.000000Z

Timestamp

Properties

Name	Type	Required	Restrictions	Description
Timestamp	string	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

side_type

BUY

Side (Buy / Sell)

Properties

Name	Type	Required	Restrictions	Description
Side (Buy / Sell)	string	false	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets

Enumerated Values

Property	Value
Side (Buy / Sell)	BUY
Side (Buy / Sell)	SELL

unique_req_type

7ac33648-ae4b-11ed-b2f9-81a12bb57b04

Unique Request Id

Properties

Name	Type	Required	Restrictions	Description
Unique Request Id	string	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.

external_ref_type

c8d16891-b669-11ed-bc43-f1002b6e6125

External Reference or Id

Properties

Name	Type	Required	Restrictions	Description
External Reference or Id	string	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.

internal_ref_type

6aa21c20-ae4b-11ed-b304-81a12bb57b04

Internal Reference or Id

Properties

Name	Type	Required	Restrictions	Description
Internal Reference or Id	string	false	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).

user_data_type

- tag: Correlation-Id
  value: 7ac33648-ae4b-11ed-b2f9-81a12bb57b04
- tag: TX-Id
  value: "18955839"

User Data Array

Properties

Name	Type	Required	Restrictions	Description
User Data Array	[object]	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
tag	string	true	none	none
value	string	true	none	none

req_header_type

req_id: ca57eead-b699-11ed-b3ff-cc17d418c9e0
user_data:
  - tag: Correlation-Id
    value: c8d16891-b669-11ed-bc43-f1002b6e6125
  - tag: TX-Id
    value: "18955457"

Request Header

Properties

Name	Type	Required	Restrictions	Description
req_id	unique_req_type	false	none	The unique request ID is generated by the API user, it has to be a UUID. It is used to detect that a request has already been processed. If the unique request ID has already been used then the request will not be executed. Instead an error will be (DuplicateReq) reported.
user_data	user_data_type	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.

sequence_type

47110815

Sequence Number

Properties

Name	Type	Required	Restrictions	Description
Sequence Number	integer	false	none	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.

transaction_ref_type

a38ca981-b669-11ed-bc43-cb132b8d1265

Transaction Reference or Id

Properties

Name	Type	Required	Restrictions	Description
Transaction Reference or Id	string	false	none	This field is used by the API user to pass an reference or ID of a Transaction. It is either the reference field of an FIAT money transaction or in case of a crypto asset transfer the hash or ID of the blockchain transaction.

transaction_ref_type_type

ON_CHAIN_TX_ID

Transaction Reference Type

Properties

Name	Type	Required	Restrictions	Description
Transaction Reference Type	string	false	none	Type of the reference of a transaction

Enumerated Values

Property	Value
Transaction Reference Type	ON_CHAIN_TX_ID
Transaction Reference Type	SEPA_REFERENCE
Transaction Reference Type	SEPA_DESCRIPTION
Transaction Reference Type	SEPA_END_TO_END_ID

channel_type

orders

Channel

Properties

Name	Type	Required	Restrictions	Description
Channel	string	false	none	Name of the websocket channel

Enumerated Values

Property	Value
Channel	orders
Channel	prices
Channel	trades

channel_status_type

ACTIVE

Channel Status

Properties

Name	Type	Required	Restrictions	Description
Channel Status	string	false	none	Status of the websocket channel

Enumerated Values

Property	Value
Channel Status	ACTIVE
Channel Status	CLOSED

heartbeat_interval_type

Heartbeat Interval (Seconds)

Properties

Name	Type	Required	Restrictions	Description
Heartbeat Interval (Seconds)	integer	false	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

subscription_id_type

a38ca981-b669-11ed-bc43-cb132b8d1265

Subscription Id

Properties

Name	Type	Required	Restrictions	Description
Subscription Id	string	false	none	This field is set by the API user. It’s serves the purpose of identifying the instrument price subscription, it is not unique.

header_type

channel: orders
timestamp: 1970-01-01T00:00:00.000000Z

Message Header

Properties

Name	Type	Required	Restrictions	Description
channel	channel_type	true	none	Name of the websocket channel
timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

price_status_type

ACTUAL

Price Status

Properties

Name	Type	Required	Restrictions	Description
Price Status	string	false	none	The status of a price subscription * ACTUAL: There is an actual price * PARTIAL: There is a reduced set of price levels * UNAVAILABLE: There is actually no price * ERROR: No price available. The subscription failed

Enumerated Values

Property	Value
Price Status	ACTUAL
Price Status	PARTIAL
Price Status	UNAVAILABLE
Price Status	ERROR

order_type_type

MARKET

Order Type

Properties

Name	Type	Required	Restrictions	Description
Order Type	string	false	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.

Enumerated Values

Property	Value
Order Type	MARKET
Order Type	LIMIT
Order Type	BULK_MARKET

time_in_force_type

FOK

Time In Force

Properties

Name	Type	Required	Restrictions	Description
Time In Force	string	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.

Enumerated Values

Property	Value
Time In Force	FOK
Time In Force	IOC

bulk_order_status_type

RECEIVED

Bulk Order Status

Properties

Name	Type	Required	Restrictions	Description
Bulk Order Status	string	false	none	The status of a new bulk order is RECEIVED. BULK_MARKET orders will be executed immediately an becomes then either REJECTED if it could not be executed or DONE if it got executed.

Enumerated Values

Property	Value
Bulk Order Status	RECEIVED
Bulk Order Status	REJECTED
Bulk Order Status	DONE

order_status_type

DONE

Order Status

Properties

Name	Type	Required	Restrictions	Description
Order Status	string	false	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.

Enumerated Values

Property	Value
Order Status	UNSPECIFIED
Order Status	RECEIVED
Order Status	CONFIRMED
Order Status	DUPLICATE
Order Status	REJECTED
Order Status	OPEN
Order Status	UPDATED
Order Status	CANCELLED
Order Status	EXPIRED
Order Status	DONE

trade_leg_status_type

UNSPECIFIED

Trade Leg Status

Properties

Name	Type	Required	Restrictions	Description
Trade Leg Status	string	false	none	none

Enumerated Values

Property	Value
Trade Leg Status	UNSPECIFIED
Trade Leg Status	PENDING
Trade Leg Status	SETTLED

order_amount_type

leg_1_amount: "1.25"

Order Amount

Properties

Name	Type	Required	Restrictions	Description
leg_1_amount	quantity_type	false	none	The quantity of a leg.
leg_2_amount	quantity_type	false	none	The quantity of a leg.

market_order_type

order_ref: "18955839"
instrument: BTC-EUR/SP
side: BUY
amount:
  leg_1_amount: "2.5"
user_data:
  - tag: Correlation-Id
    value: 7ac33648-ae4b-11ed-b2f9-81a12bb57b04
  - tag: TX-Id
    value: "18955839"

Market Order Data

Properties

Name	Type	Required	Restrictions	Description
order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
user_data	user_data_type	false	none	This object is an array used by the API user to pass data to the tradias system which will be returned back to the API user together with the responses related to the transaction. It can be used by the API user to identify an transaction in a later response.
counter_leg_precision	counter_leg_precision_type	false	none	This optional key can be given in a new order request. The value specifies the number of decimals you want the computed amount of the leg that is not yet specified in the order request to be rounded to. For example, if you give the amount you want to buy/sell in the leg 2 asset, the counter_leg_precision specifies the number of decimals you want the leg 1 amount to be rounded to. Vice versa, if you specify the amount to buy/sell in the leg 1 asset, the amount in the leg 2 asset will be rounded to the specified number in the counter_leg_precision field.

order_data_type

instrument: BTC-EUR/SP
order_type: LIMIT
time_in_force: FOK
side: BUY
amount:
  leg_1_amount: "2.5"
limit_price: "24650"
arrived_at: 1970-01-01T00:00:00.000000Z
order_status: DONE

Order Data

Properties

Name	Type	Required	Restrictions	Description
instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
arrived_at	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
order_status	order_status_type	false	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.

bulk_execution_type

order:
  order_ref: "18955839"
  instrument: BTC-EUR/SP
  side: BUY
  amount:
    leg_1_amount: "2.5"
  user_data:
    - tag: Correlation-Id
      value: 7ac33648-ae4b-11ed-b2f9-81a12bb57b04
    - tag: TX-Id
      value: "18955839"
order_type: MARKET
time_in_force: FOK
order_status: DONE
leg_1_executed_amount: "1.25867895"
leg_2_executed_amount: "1.25867895"
execution_price: "23768.63953056"
trade_ids:
  - 6aa21c20-ae4b-11ed-b304-81a12bb57b04
executed_at: 1970-01-01T00:00:00.000000Z

Bulk Order Execution

Properties

Name	Type	Required	Restrictions	Description
order	market_order_type	true	none	This schema represents all information needed for an MARKET order
order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
time_in_force	time_in_force_type	true	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
order_status	order_status_type	true	none	Orders have a live cycle. The state an order is in that live cycle expressed by its state. The above values are states an order can have in its live cycle. Initially the order is RECEIVED. DUPLICATE, REJECTED, EXPIRED, CANCELLED and DONE are terminal states which will not change any more. UNSPECIFIED means the state is unknown.
leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
trade_ids	[internal_ref_type]	false	none	[This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).]
executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

execution_type

trade_id: 6aa21c20-ae4b-11ed-b304-81a12bb57b04
leg_1_executed_amount: "1.25867895"
leg_2_executed_amount: "1.25867895"
execution_price: "23768.63953056"
executed_at: 1970-01-01T00:00:00.000000Z
leg_1_status: UNSPECIFIED
leg_2_status: UNSPECIFIED

Order Execution

Properties

Name	Type	Required	Restrictions	Description
trade_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
leg_1_status	trade_leg_status_type	false	none	none
leg_2_status	trade_leg_status_type	false	none	none

trade_type

leg_1_executed_amount: "1.25867895"
leg_2_executed_amount: "1.25867895"
execution_price: "23768.63953056"
executed_at: 1970-01-01T00:00:00.000000Z
leg_1_status: UNSPECIFIED
leg_2_status: UNSPECIFIED

Trade Data

Properties

Name	Type	Required	Restrictions	Description
leg_1_executed_amount	quantity_type	true	none	The quantity of a leg.
leg_2_executed_amount	quantity_type	true	none	The quantity of a leg.
execution_price	price_type	true	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
executed_at	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
leg_1_status	trade_leg_status_type	false	none	none
leg_2_status	trade_leg_status_type	false	none	none

settlement_status_type

RECEIVED

Settlement Status

Properties

Name	Type	Required	Restrictions	Description
Settlement Status	string	false	none	Status of a settlement. In case the trades in the settlement request are ok and result in the correct amounts, the value will be CONFIRMED. The value switches to “PARTIALLY”, once the transaction has been made and to SETTLED if all transactions have been successfully executed. In case if there is a problem with the settlement its status will be REJECTED. When the settlement request has just been sent the status will be RECEIVED. This status is also been used to reflect the status of each amount (transaction) of a settlement. In this case the state PARTIALLY will not been used.

Enumerated Values

Property	Value
Settlement Status	RECEIVED
Settlement Status	REJECTED
Settlement Status	CONFIRMED
Settlement Status	PARTIALLY
Settlement Status	SETTLED

direction_type

SEND

Direction (SEND / RECEIVE)

Properties

Name	Type	Required	Restrictions	Description
Direction (SEND / RECEIVE)	string	false	none	The direction of a transaction, seen from the perspective of the API user. * SEND The user sending money or assets to tradias * RECEIVE The user receiving money or assets from tradias

Enumerated Values

Property	Value
Direction (SEND / RECEIVE)	SEND
Direction (SEND / RECEIVE)	RECEIVE

transaction_type

tx_id: 265a2482-bf2f-11ed-8f96-eac8fe84d40c
reference_type: ON_CHAIN_TX_ID
reference: 1b82e950aebfd74ab6508538f2138cf4ab0b904a9a3c93ad2df209e5f78d1ea9
amount: "1.76"

Transaction Data

Properties

Name	Type	Required	Restrictions	Description
tx_id	internal_ref_type	true	none	A tradias ID of the transaction
reference_type	transaction_ref_type_type	true	none	Type of the reference of a transaction
reference	transaction_ref_type	true	none	This field is used by the API user to pass an reference or ID of a Transaction. It is either the reference field of an FIAT money transaction or in case of a crypto asset transfer the hash or ID of the blockchain transaction.
amount	quantity_type	true	none	The quantity of a leg.

settlement_amount_type

settlement_request_amount_id: 6aa21c20-ae4b-11ed-b304-81a12bb57b04
currency: BTC
from_address: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
to_address: BHS
amount: "1.23"
expected_amount: "1.23"
status: PARTIALLY
transactions:
  - tx_id: 265a2482-bf2f-11ed-8f96-eac8fe84d40c
    reference_type: ON_CHAIN_TX_ID
    reference: 1b82e950aebfd74ab6508538f2138cf4ab0b904a9a3c93ad2df209e5f78d1ea9
    amount: "1.00"

Settlement Amount

Properties

Name	Type	Required	Restrictions	Description
settlement_request_amount_id	internal_ref_type	true	none	Server-side generated unique identifier of the settlement request amount
currency	asset_code_type	true	none	The currency to which the request amount applies
from_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
to_address	address_type	true	none	An address to transfer either Fiat money or crypto assets to or from. It is either (for Fiat money) an account number (IBAN) or (for crypto assets) an wallet key. In the case of tradias as recipient or sender the value “BHS” will be used.
amount	quantity_type	true	none	The quantity of a leg.
expected_amount	quantity_type	true	none	The amount expected by tradias as a result of the trades passed in the corresponding trade list. In order for settlement to go forward, this expected_amount has to agree with the amount field.
status	settlement_status_type	true	none	Settlement status of the respective settlement request amount. In case amount of the settlement request matches with the amount tradias has calculated the value will be “CONFIRMED” and the value switches to “SETTLED”, once the transaction has been done. In case tradias receives the amount, the status change will happen upon receipt of the amount, in the case tradias sends the amount, the status change happens upon the sending of the amount.
transactions	[transaction_type]	false	none	A list of transactions that have been made and associated with this settlement request amount

complete_transaction_type

transaction_id: 6aa21c20-ae4b-11ed-b304-81a12bb57b04
transaction_ref: c8d16891-b669-11ed-bc43-f1002b6e6125
req_header:
  req_id: ca57eead-b699-11ed-b3ff-cc17d418c9e0
  user_data:
    - tag: Correlation-Id
      value: c8d16891-b669-11ed-bc43-f1002b6e6125
    - tag: TX-Id
      value: "18955457"
amount: "1.25867895"
reference: a38ca981-b669-11ed-bc43-cb132b8d1265
reference_type: ON_CHAIN_TX_ID
timestamp: 2019-08-24T14:15:22Z
from_address: string
to_address: string
currency: BTC
settlement_requests:
  - settlement_request_id: 6aa21c20-ae4b-11ed-b304-81a12bb57b04
    settlement_request_amount_id: 6aa21c20-ae4b-11ed-b304-81a12bb57b04
    amount: "1.25867895"

Complete Transaction Data

Properties

Name	Type	Required	Restrictions	Description
transaction_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
transaction_ref	external_ref_type	false	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
amount	quantity_type	true	none	The quantity of a leg.
reference	transaction_ref_type	true	none	External reference to the transaction. For example an on-chain txid or a reference value in the SEPA reference field.
reference_type	transaction_ref_type_type	true	none	Reference type of the transaction, specifying the place in which the reference field was passed on some external record (e.g. SEPA transaction)
timestamp	string(date-time)	true	none	none
from_address	address_type	true	none	Address from which the amount was sent
to_address	address_type	true	none	Address on which the amount was received
currency	asset_code_type	true	none	Identifier of a leg of an instrument
settlement_requests	[object]	true	none	List of references to settlement requests in which this transaction is used for settlement
» Settlement Request	object	false	none	Reference to an amount in a settlement request
»» settlement_request_id	internal_ref_type	true	none	Unique identifier of the settlement request
»» settlement_request_amount_id	internal_ref_type	true	none	List of settlement request amounts relevant for the settlement mapping of this transaction
»» amount	quantity_type	true	none	Numerical value used from this transaction to settle the respective settlement request amount.

error_type

NotFound

Error Code

Properties

Name	Type	Required	Restrictions	Description
Error Code	string	false	none	All error codes returned by this API have a unique code, classifying the error messages.

Enumerated Values

Property	Value
Error Code	Unauthorized
Error Code	InternalServerError
Error Code	Conflict
Error Code	UnprocessableEntity
Error Code	DuplicateReq
Error Code	InvalidOrder
Error Code	MixedOrders
Error Code	InvalidAmount
Error Code	AmountTooLow
Error Code	AmountTooAccurate
Error Code	AmountTooHigh
Error Code	NoPriceStream
Error Code	RiskCheck
Error Code	DuplicateOrderRef
Error Code	NotFound
Error Code	Forbidden
Error Code	ValidationError

error_text_type

The bulk order with the given ID could not be found.

Error Text

Properties

Name	Type	Required	Restrictions	Description
Error Text	string	false	none	Text describing the Error

internal_error_type

error:
  timestamp: 2023-01-20T14:31:10.012123Z
  error: InternalServerError
  error_text: "Internal Server Error: the server can currently not process the request"

Internal Error Type (for 4xx Results)

Properties

Name	Type	Required	Restrictions	Description
error	object	true	none	none
» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
» error_text	error_text_type	true	none	Text describing the Error

internal_req_error_type

error_req_header:
  req_header:
    req_id: ca57eead-b699-11ed-b3ff-cc17d418c9e0
    user_data:
      - tag: Correlation-Id
        value: c8d16891-b669-11ed-bc43-f1002b6e6125
      - tag: TX-Id
        value: "18955457"
  tradias_id: 6aa21c20-ae4b-11ed-b304-81a12bb57b04
  timestamp: 1970-01-01T00:00:00.000000Z
  error: NotFound
  error_text: The bulk order with the given ID could not be found.

Internal Req Error Type (for 4xx Results)

Properties

Name	Type	Required	Restrictions	Description
error_req_header	object	true	none	none
» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
» tradias_id	internal_ref_type	true	none	This field is used by tradias to pass an reference or ID to the API User. It is used in the tradias system to to act as an reference or ID to an object (Order, Trade, …).
» timestamp	timestamp_type	true	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”
» error	error_type	true	none	All error codes returned by this API have a unique code, classifying the error messages.
» error_text	error_text_type	true	none	Text describing the Error

SubscribePriceChannel

subscribe_price_channel:
  channel: prices
  heartbeat_interval: 30

Subscribe to a Channel

Properties

Name	Type	Required	Restrictions	Description
subscribe_price_channel	object	true	none	none
» channel	channel_type	true	none	Name of the websocket channel
» heartbeat_interval	heartbeat_interval_type	false	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

UnSubscribeChannel

unsubscribe_channel:
  channel: prices

End the Subscription of a Channel

Properties

Name	Type	Required	Restrictions	Description
unsubscribe_channel	object	true	none	none
» channel	channel_type	true	none	Name of the websocket channel

SubscribeInstruments

subscribe_instruments:
  channel: prices
  subscriptions:
    - subscription_id: XX-4567
      instrument: BTC-EUR/SP
      max_frequency: 500
    - subscription_id: TS-BTC
      instrument: BTC-EUR/SP
      mergeable: false
      max_pending: 100
    - subscription_id: XX-4549
      instrument: ETH-EUR/SP
      max_frequency: 500
    - subscription_id: TS-ETH
      instrument: ETH-EUR/SP
      mergeable: false

Subscribe to Instrument Prices

Properties

Name	Type	Required	Restrictions	Description
subscribe_instruments	object	true	none	none
» channel	channel_type	true	none	Name of the websocket channel
» subscriptions	[object]	true	none	Array containing a list of subscriptions
»» Subscription	object	false	none	none
»»» subscription_id	subscription_id_type	true	none	This field is set by the API user. It’s serves the purpose of identifying the instrument price subscription, it is not unique.
»»» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
»»» mergeable	boolean	false	none	none
»»» max_frequency	integer	false	none	none
»»» max_pending	integer	false	none	none

UnSubscribeInstruments

unsubscribe_instruments:
  channel: prices
  subscription_ids:
    - XX-4567
    - TS-BTC
    - XX-4549
    - TS-ETH

Un-Subscribe from a Subscription

Properties

Name	Type	Required	Restrictions	Description
unsubscribe_instruments	object	true	none	none
» channel	channel_type	true	none	Name of the websocket channel
» subscriptions_ids	[subscription_id_type]	false	none	Array containing a list of subscriptions to unsubscribe from

SubscribeOrderChannel

subscribe_order_channel:
  channel: orders
  heartbeat_interval: 30

Subscribe to a Order Channel

Properties

Name	Type	Required	Restrictions	Description
subscribe_order_channel	object	true	none	none
» channel	channel_type	true	none	Name of the websocket channel
» heartbeat_interval	heartbeat_interval_type	false	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.

SubscribeTradeChannel

subscribe_trade_channel:
  channel: trades
  heartbeat_interval: 30
  seq_number: 47110815

Subscribe to a Trade Channel

Properties

Name	Type	Required	Restrictions	Description
subscribe_trade_channel	object	true	none	none
» channel	channel_type	true	none	Name of the websocket channel
» heartbeat_interval	heartbeat_interval_type	false	none	This optional field defines if the tradias server sends heartbeat messages to the channel or not. The value specifies the interval of the heartbeat messages in seconds. The maximum is 600 seconds (10 minutes). A value of 0 switches the heartbeat message generation off. Zero is the default which means by default there are no heartbeat messages.
» seq_number	sequence_type	false	none	Sequence number of an order, trade or any other event. A sequence number is assigned to the object (e.g. order) when it is received. All sequence number are unique and increasing. There may be gaps in the sequence numbers assigned! The sequence number can ba used sort objects in the way they have been received/happened. If the maximum is reached the sequence numbers continue with 0.
» execution_time	timestamp_type	false	none	Timestamp in UTC Timezone using the following format “%Y-%m-%dT%H:%M:%S.%fZ”

NewOrder

new_order:
  order_ref: c8d16891-b669-11ed-bc43-f1002b6e6125
  req_header:
    req_id: ca57eead-b699-11ed-b3ff-cc17d418c9e0
    user_data:
      - tag: Correlation-Id
        value: c8d16891-b669-11ed-bc43-f1002b6e6125
      - tag: TX-Id
        value: "18955457"
  order_type: LIMIT
  time_in_force: FOK
  instrument: BTC-EUR/SP
  side: BUY
  amount:
    leg_2_amount: "50000"
  limit_price: "24570"

New Order

Properties

Name	Type	Required	Restrictions	Description
new_order	object	true	none	none
» order_ref	external_ref_type	true	none	This field is used by the API user to pass an reference or ID to the tradias system which is used in the tradias system to to act as an reference or ID to the transaction in the API users system.
» req_header	req_header_type	false	none	This request header is part of any request creating or modifying an object (order, bulk-order, settlement, …). It consists of two parts, a request ID which will be checked on the tradias side for uniqueness, and an array of user data (tag value). Both parts are option as the complete request header is. The request ID can be used by the API user to allow, that if a request does not answer properly, to sent the request again. If the first one has been processed, then the second one will be rejected with a 409 error and the API user knows that the first request has been processed. If the first request did not make it the second one will be processed normally. The second part is an array of values tagged by a short tag. This data provided by the API user will be returned with the response of the request and if a possible will be added to the object the request relates to and later returned with all responses relating to the object.
» order_type	order_type_type	true	none	There are different order types. Currently only the following order types are supported * MARKET: This is a order (without limit). * LIMIT: This is a order with a limit. Buy orders are only executed if the execution price is lower or equal than the limit price. Sell orders are only executed if the execution price is higher or equal than the limit price. * BULK_MARKET: This is a list order where multiple orders are entered as a single bulk. The bulk is either executed completely or not at all.
» time_in_force	time_in_force_type	false	none	This order attribute defines the duration a order is active. * FOK: Fill Or Kill is an order which is either completely executed immediately or will be canceled/rejected. * IOC: Immediately Or Cancel is an order which is either executed immediately or will be canceled/rejected. The difference to FOK is that IOC allows partial executions. As tradias always executes completely there is no difference in FOK and IOC orders.
» instrument	instrument_type	true	none	Identifier for an instrument. It consists of the asset codes of the two legs and an optional asset tenor {leg_1_asset} “-” {leg_2_asset} [ “/” {tenor} ]
» side	side_type	true	none	The side of the order, seen from the perspective of the API user. * BUY The user sending the order is buying assets * SELL The user sending the order is selling his assets
» amount	order_amount_type	true	none	You can specify the amount of an instrument to buy or sell either in the leg_1 or in the leg_2 quantity. If you for example want to buy BTC-EUR you can either define the amount to buy in BTC by specifying the leg_1_amount, or you can specify the amount to spend in EUR by defining the leg_2_amount. Only one of the two legs can be used for a single order!
» limit_price	price_type	false	none	The price of a quantity of 1.0 of leg_1 expressed in a leg_2 quantity. For example the instrument “BTC-EUR” the leg_1 is “BTC” and the leg_2 is “EUR”. A price of “23768.63953056” means that you pay 23,768.63953956 EUR for one BTC.
» counter_leg_precision	counter_leg_precision_type	false	none	This optional key can be given in a new order request. The value specifies the number of decimals you want the computed amount of the leg that is not yet specified in the order request to be rounded to. For example, if you give the amount you want to buy/sell in the leg 2 asset, the counter_leg_precision specifies the number of decimals you want the leg 1 amount to be rounded to. Vice versa, if you specify the amount to buy/sell in the leg 1 asset, the amount in the leg 2 asset will be rounded to the specified number in the counter_leg_precision field.