As per the documentation for Postbacks, any postback is accompanied with a checksum and it is recommended that it be checked with a locally computed hash. Now, when I try to place orders via KiteConnect, I get an order update in the 'on_order_update' callback, but the checksum in the same is blank. What might be the reason for this? I have tried with all kinds of orders and also tried regenerating my API secret, but to no avail.
I am not using a webhook for postbacks, instead, I am listening for the same on 'on_order_update' callback of KiteTicker. There I get a blank checksum. The example you pointed to uses a server for receiving postbacks
1] Can anyone give the format with example for order updates on websockets via callback :: on_order_update ? 2] Is it in "json" format? 3] Does it return responses from order placement to its last fate viz. PUT ORDER REQUEST RECEIVED VALIDATION PENDING etc etc..... till COMPLETE, REJECTED, CANCELLED, and OPEN
Specimen example would help it more!!!!
PS.:: For multiple instruments how does this work?
You can refer to the documentation here. It won't contain an array of updates but a single dict at a time. The format is the same as the postback's format.
You won't receive order updates for everything but you will receive for every update on the order like a trade happening for an order, modify on an order, execute an order (complete, rejection, canceled).
You need to try it out with examples to understand the behavior so that you can decide what is feasible for your use case.
@sujith One more very important thing:: 1] While placing order itself; [order_id = kite.place_order(tradingsymbol="INFY".........)] Does every "order placement API" return an order id regardless of whether it is in Req. pending state or complete, cancelled, rejected, open etc.... 2] So that afterwards using "on_order_update" callback mechanism we can track whether it was rejected or pending or open using this unique "order id" 3] Because if "order placement API" DOES NOT return order id then how to track its status?? Please put a light on this!!!
A 200 status of a place order API will return order id in the response. It means order placement is successful. After placing an order it can go to any state open, complete, rejected, canceled. One can use order_update via websocket, postbacks feature or fetch orderbook to know the status of the order.
If order id is not returned then you will see an error response in this format.
Please note that sometimes when there are timeout or some non-400 exceptions you will need to fetch orderbook and check or check the order updates before retry otherwise you might end up placing double order.
2] Is it in "json" format?
3] Does it return responses from order placement to its last fate viz.
PUT ORDER REQUEST RECEIVED
VALIDATION PENDING etc etc..... till
COMPLETE, REJECTED, CANCELLED, and OPEN
Specimen example would help it more!!!!
PS.:: For multiple instruments how does this work?
It won't contain an array of updates but a single dict at a time.
The format is the same as the postback's format.
You won't receive order updates for everything but you will receive for every update on the order like a trade happening for an order, modify on an order, execute an order (complete, rejection, canceled).
You need to try it out with examples to understand the behavior so that you can decide what is feasible for your use case.
1] While placing order itself;
[order_id = kite.place_order(tradingsymbol="INFY".........)]
Does every "order placement API" return an order id regardless of whether it is in Req. pending state or complete, cancelled, rejected, open etc....
2] So that afterwards using "on_order_update" callback mechanism we can track whether it was rejected or pending or open using this unique "order id"
3] Because if "order placement API" DOES NOT return order id then how to track its status??
Please put a light on this!!!
After placing an order it can go to any state open, complete, rejected, canceled.
One can use order_update via websocket, postbacks feature or fetch orderbook to know the status of the order.
If order id is not returned then you will see an error response in this format.
Please note that sometimes when there are timeout or some non-400 exceptions you will need to fetch orderbook and check or check the order updates before retry otherwise you might end up placing double order.