AlgoTraderAlgoTrader Documentation

Chapter 21. AlgoTrader API

21.1. JSON data binding
21.2. REST API
21.3. WebSocket/STOMP API
21.4. Inbound FIX API
21.4.1. Logon message
21.4.2. Logout message
21.4.3. Test Request message
21.4.4. Heartbeat message
21.4.5. Resend Request message
21.4.6. New Order Single message
21.4.7. Order Cancel Request message
21.4.8. Order Cancel Replace Request message
21.4.9. Execution Report message

The following sections describe how the AlgoTrader system can be accessed by external systems.

AlgoTrader uses a consistent message format based on JSON for both the WebSocket/STOMP API and the REST API.

Using the JSON messages in combination with the AlgoTrader REST API and WebSocket/STOMP API any popular development language can be used to build trading strategies making use of the AlgoTrader platform, for example:

Access to most of the functionality and data provided by AlgoTrader is available via a REST based API.

The full documentation of the AlgoTrader REST API is available here.

HTTP GET endpoints can easily be queried via the Browser. To retrieve a JSON formatted list of all accounts open to the following URL in the Browser:


In addition one case use Curl, a popular utility for execution of HTTP requests. The following example shows how to retrieve a JSON formatted list of all accounts by executing HTTP GET request:

$ curl -X GET http://localhost:9090/rest/account -i
HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Server: Jetty(9.3.6.v20151106)


Similarly one can request AlgoTrader to subscribe to market data for security with id 11 by executing HTTP PUT request:

$ curl -X PUT -H "content-type: application/json"
  http://localhost:9090/rest/subscription/marketdata/subscribe \
  -d "{\"strategyName\":\"SERVER\",\"securityId\":11,\"subscribe\":true}" -i
HTTP/1.1 200 OK
Content-Length: 0
Server: Jetty(9.3.6.v20151106)   

AlgoTrader employs STOMP messaging protocol over WebSockets transport to implement multi-topic, multi-client message delivery based on the Publish-Subscribe pattern. AlgoTrader acts as a message producer that generates messages representing various system or trading related events and publishes them to predefined topics. Browsers running the AlgoTrader UI (and potentially any external application supporting STOMP over WebSockets) act as message consumers that subscribe to message topics of interest such as market data, orders, order status updates, position changes, executed transactions and so on. Consumers express their interest in a particular type of event by subscribing to message topics. Consumers should no longer need to filter out unwanted messages. They are expected to subscribe only to a subset of messages they are interested in.

For further details on the STOMP protocol please visit the STOMP website.

AlgoTrader publishes events to multiple event topics.

Topics are organized by name spaces. A consumer wishing to receive market data for security with id 12 only can subscribe to the following topic:


A consumer wishing to receive market data all securities can subscribe to the following wild card topic.


Strategy specific events are organized by strategy name. A consumer wishing to receive order status updates for the order with internal id 10 issued by strategy MY_STRATEGY can subscribe to the following topic


A consumer wishing to receive order status updates for all orders issued by strategy MY_STRATEGY can subscribe to the following wild card topic


The * wild card selects all elements within the same namespace

A consumer wishing to receive order status updates for all orders of all strategies can subscribe to the following wild card topic


The > wild card selects all topics within the same namespace and their sub-namespaces.

In order to ensure optimal performance of HTML5 clients AlgoTrader can throttle market data event delivered by the WebSockets transport. The embedded message broker by default attempts to ensure that the total rate of events per connection does not exceed 50 per second. At the same time instruments with infrequent market data updates are not throttled if their total event rate is below 0.1 per second (less that one event every 10 seconds).

Throttling rates can be adjusted by changing the following configuration parameters:

activeMQ.maxRatePerConnection = 50
activeMQ.minRatePerConsumer = 0.1

In JavaScript STOMP messages can be consumed like this:

        <script src=""></script>
        <script type="text/javascript">
            var ws = new WebSocket("ws://localhost:61614", "stomp");
            var stompClient = Stomp.over(ws);
            stompClient.connect({}, function(frame) {
                stompClient.subscribe('/topic/tick.*', function(message){

For further details please visit the STOMP JavaScript documentation.

AlgoTrader supports STOMP over normal TCP connections. It designed initially for Python clients.

Sample subscription consumer code in Python:

import time
import sys

import stomp

class MyListener(stomp.ConnectionListener):
 def on_error(self, headers, message):
  print('received an error "%s"' % message)
 def on_message(self, headers, message):
  print('received a message "%s"' % message)
hosts = [('localhost', 61618)]

conn = stomp.Connection(host_and_ports=hosts)
conn.set_listener('', MyListener())
conn.connect( )

conn.subscribe(destination='/topic/log-event.error', id='sub-0', ack='auto')
conn.subscribe(destination='/topic/tick.849', id='10', ack='auto')


AlgoTrader provides Inbound FIX protocol based API which allows submission, modification and cancellation of simple orders (Market, Limit, Stop, Stop Limit). Those are then forwarded via the configured trading adapter to the relevant broker / exchange. You can also configure AlgoTrader to connect to multiple exchanges and use Inbound FIX API to submit orders to any of them.

Order status changes from the broker/exchange are then forwarded back to the external FIX client. This mechanism allows using the industry standard FIX API for order management via all trading adapters AlgoTrader provides. Thus also for exchanges or brokers that do not natively support FIX.

The following is an example of the QuickFixJ config (fix.cfg) that you can use to make the Inbound FIX API available.

# FIX client should have those 2 in reverse order:
# SenderCompID=BANZAI
# TargetCompID=AT

You can test AlgoTrader Inbound FIX API using e.g. Banzai FIX GUI client. Note that AlgoTrader specific custom tags 7001 (StrategyID), 7002 (StrategyName), 7003 (ExchangeOrder) on New Order Single messages are not supported by Banzai client. They can be added in the source code easily if necessary.

The following is an example banzai.cfg config for connecting to locally running AlgoTrader:


This is an example runner configuration for starting AlgoTrader with Inbound FIX API enabled and connected to Interactive Brokers:

Main Class: ch.algotrader.starter.ServerStarter
VM Options:,pooledDataSource,embeddedBroker,inboundFix,iBNative,iBMarketData,html5

Note that you can open the HTML5 UI (http://localhost:9090) and the orders you place via Inbound FIX API will be visible there. QuickFixJ logs with FIX messages between Banzai and AlgoTrader can be found in \log\FIX.4.4-AT-BANZAI.messages.log file. The raw FIX messages can be translated by e.g. FIX decoder.

The protocol version provided by the AlgoTrader Inbound FIX API is FIX 4.4. We use standard messages with 3 custom tags in New Order Single message. Following messages are supported:

  • Logon (A)

  • Logout (5)

  • Test Request (1)

  • Heartbeat (0)

  • Resend Request (2)

  • Execution Report (8)

  • New Order Single (D)

  • Business Message Reject (j)

  • Order Cancel/Replace Request (G)

  • Order Cancel Request (F)

  • Order Cancel Reject (9)

Used to receive order update information from AlgoTrader, such as confirmation for fills, cancellations, modifications or rejections. Sent from AlgoTrader to the external client

Table 21.10. Execution Report

Tag #Field NameRequiredData typeComments
35Standard Msg TypeYChar8
1AccountYStringAlgoTrader account ID
17ExecIDYStringUnique identifier for this execution report, UUID format
11ClOrdIDYStringAlgoTrader order ID
37OrderIDYStringAlgoTrader order ID
41OrigClOrdIDCStringPrevious order identifier, equal to previous ClOrdID and sent after modification requests
38OrderQtyYStringTotal order quantity
6AvgPxYPriceAverage price of all fills, 0 if no executions yet
151LeavesQtyYQtyRemaining quantity in the market. If order is still in the market LeavesQty = Qty - CumQty, 0 otherwise
14CumQtyYQtyFilled quantity so far
167SecurityTypeNStringType of security
48SecurityIDYStringAlgoTrader Security ID
55SymbolYStringAlgoTrader Security Symbol
59TimeInForceYCharHow long an order remains active. Supported: 0, 1, 2, 3, 4, 6, 7
54SideYChar1 or 2 for Buy/Sell

Indicates the reason for sending this Execution Report

  • 0: NEW, sent as a confirmation that the order has been accepted

  • 6: PENDING CANCEL, received, but not processed yet


  • E: PENDING REPLACE, received, but not processed yet

  • I: ORDER STATUS, update

  • F: TRADE, fill

  • A: PENDING_NEW, received, but not processed yet


Current order status

  • 0: NEW, order submitted

  • 1: PARTIALLY FILLED, order partially executed

  • 2: FILLED, order executed

  • 4: CANCELED, order canceled

  • 6: PENDING CANCEL, order will be cancelled

  • 8: REJECTED, order rejected

  • A: PENDING_NEW, order received, but not submitted yet

  • E: PENDING REPLACE, order will be replaced

58TextCStringAdditional information. Typically contains the details in case of rejection