uTrade Dot Net API 1.0.0.0

uTrade Dot Net API 1.0.0.0 provides infrastructure to interact with algo and retail trading backend server using easy and to use and efficient api method calls based out of Microsoft .Net technologies.

It allows user to create their own latency sensitive strategies and single order placement method calls in uTrade's infrastructure in exchange co-location or non co-location environment.

New custom frontend and strategies can be integrated and run in the platform on the fly with no effect on the already running strategies.

Risk Management features is also available, same as the trading platform.

Custom strategy can be run with snapshot feed for now. Latest data (order book) is provided to the strategy on request and subscription basis.

Data Flow Note

Multiple threads will be active after user will be connected to market as it will help system to perform efficiently. All requests including order and market data will be placed in main thread. Response for orders and other requests

will be received in seperate thread. So, user need to take care of resources accordingly. For market data dispatch, there will be seperate thread.

There are 2 threads through which client application will receive updates :-

T1 : it will provide online snapshot data.

T2 : it will provide responses for different client application requests.

Request-Response Flow Note

Request is accepted by the dll in the thread created by the user application.

Note : Response will be given seperately, the function only returns whether request accepted successfully or not.

Response for requests such as GetOpenOrders, and notification for order updates such as Order Partially filled (onOrderUpdate, fillReport) will be provided in seperate threads, so client application need to handle the responses and notifications such that synchronization and locking is there for updating resources if any.

Order updates :

Order book snapshots will be sent to client application whenever there is an update in the snapshot : this is provided through onOrderUpdate.
The snapshot if updated will be sent after configurable amount of time from dll to client application (minimum 0.5 sec).
The snapshot will contain all the orders that have updated during the interval.

E.g.
Assuming O1, O2 and O3 as orders request by the client.

O1 gets confirmed at time t1.
O2 gets confirmed at time t1 + 0.1 s.
O1 gets partially filled at time t1 + 0.15s.
O3 gets modified at time t1 + 0.2 s.
O1 gets partially filled at time t1 + 0.25s.

Then at t1 + 0.5s, client application will receive the snapshot containing

O1 : Partially filled (Order Price, Order Qty, Total filled qty).
O2 : Confirmed (Order Price, Order Qty).
O3 : Replaced (Replaced Order Price, Replaced Order Qty).

Through onOrderUpdate callbacks, so here 3 callbacks will be received in thread T1.
Order updates will contain Order Price, Order Qty, Total Filled qty etc.

Trade Reports :

Trade book snapshots will be sent to client application whenever there is an update in the trades, this is provided through FillReport.
The snapshot if updated will be sent after configurable amount of time from dll to client application (minimum 0.5 sec).
The snapshot will contain all the trades that have been done during the interval.

In the above example

At t1 + 0.5s, client application will receive the trade snapshot containing.
O1 : Partially filled (Last Filled Price, Last Filled Qty).
O1 : Partially filled (Last Filled Price, Last Filled Qty).

Through fillReport callbacks, so here 2 callbacks will be received in thread T1.

Note : All fills will be received seperately, but all transactions may not be received, like in the above example, only 1 O1 update received, but both trades are received.
Order update will contain - Fully Filled, New Reject, Canceled, RMS Reject and will contain one Order Update for life cycle completion.
Order update and fill report both will contain entry for Partial Fill.

Note : If there is a trade then two callbacks will be generated FillReport and OrderUpdate for e.g.

Client C1 place a buy order of 100 qty on symbol XYZ.
Client C2 place a (MARKET) sell order of 20 qty on symbol XYZ.

Then Client C1 will received an OrderUpdate(PARTIAL-FILL) with (20 filled, 80 pending) qty and FillReport with 20 qty filled.
Where Client C2 will received an OrderUpdate(FILLED) with (20 filled, 00 pending) qty and FillReport with 20 qty filled.
To get all the states of an order override OrderUpdate and for trade orderride FillReport (Can override both methods at once)

E.g. for the working thread T2

API Client request for all the clients which are mapped to the dealer by invoking the method GetAccounts().
The response of the client will be process in thread T2 and the callback method will be invoked GetAccountsStart(), GetAllAccounts()and GetAccountsEnd().

Note : When user login to HFT then it will bring offline confirmations from DMS and these offline confirmations will not get any callback

these offline confirmations can access through GetOpenOrders() and GetTradeHistory() methods, after completing offline confirmations it will request to begin online data.

Error handling and codes

Every request or method call will return an integer value which will be 0 or 1. 0 - Failure, 1 - Success. In case of failure, user can call getLastErrorCode or getLastErrorStr for exact error code. Refer error codes for more detail.

Symbology

Exchange Symbology : NSECM, NSEFO, NSECDS, NSEIFSC, NSECOM, BSECM, BSEFO, BSECDS, BSEINX, BSECOM, MCX, MSE, DGCX etc

Cash segment : <SOURCE> <EXCHANGE> <SYMBOL>-<GROUP>

Example : DEFAULT NSECM ABB-EQ

Future segment : <SOURCE> <EXCHANGE> <SYMBOL> <EXPIRY> <FUT>

Example : DEFAULT NSEFO ZEEL29NOVFUT

Options segment : <SOURCE> <EXCHANGE> <SYMBOL> <EXPIRY> <STK price>=""> <PUT or="" call>="">

Example : DEFAULT NSEFO BANKNIFTY29NOV28700PE

User need not to send source name or full key while placing an order.

e.g. PlaceOrder("NSEFO", "TESTACC", "DAY", "C", "NULL", "L", "BANKNIFTY29NOVFUT", "S", 40, 26873.50, .......)