Currently for FNO trades, we are forced to put a python SLEEP function as API limits 10 orders per sec per app. (this was discussed in earlier discussion initiated by me).
So making ICEBERG order will solve this issue that we will send entire order with full quantity (say for example 25000 NIFTY FUTURES) with leg size as quantity freeze (1800 currently). This way we can easilly overcome the 10 order per sec per app limitation by just sending one large iceberg order.
I hope this makes sense for traders who trade with large quantities.
@rakeshr , what will be return type of the place_order() API when ICEBERG is sent? in normal order, we receive the order_id. Since here multiple orders can be placed, how can we know order_ids placed? FYI, we need to record order_id in our database system.
@tapanjbhatt, Only first leg order is placed initially, second order is triggered only after first leg is executed. Hence only one order_id is sent in response.
thx @sujith , the further order_ids can be seen in ON_ORDER_UPDATE callback, riight? if yes, is there any way to know the related orders (i.e. all orders 2nd leg onwards) based on parent order id (the main order id returned by place_order api) or something like that? we need linkage between the first leg and subsequent legs. Asking bcoz I didnt find this info in docs....
This is added to the place order API. You can go through the documentation here.
PS: i am talking about python client.
Only first leg order is placed initially, second order is triggered only after first leg is executed. Hence only one order_id is sent in response.
Asking bcoz I didnt find this info in docs....