I am running a strategy that relies on placing Stop loss market orders and I am using Postback to ascertain if the order was placed or not. Most of the times, when trigger price is below LTP for BUY orders or above LTP for SELL orders, the callback returns a failure. This experience is consistent with the documentation here: https://support.zerodha.com/category/console/portfolio/holdings/articles/kite-order-rejections. As per this blog, if validation of trigger price fails then the order may not even reach Order book. So the callback correctly displays an error message.
However few times, the callback returns a valid order_id (and no error message) and only upon invoking getOrderHistory() it is found that this order was REJECTED. Sample order IDs: 230131000103105, 230131001290015, 230131001727786, 230131003412293. This is making the Order async callback unreliable and looks like a bug.
A 200 for order placement means order is placed successfully. It doesn't mean order is executed. An order goes through multiple system before it hits exchange and gets executed. You can view all the states by fetching the order history. An order that is placed may or may not get rejected. One needs to fetch orderbook and check the latest status of the order. In some cases, wherein order is blocked by our internal mini OMS, you will receive 400 response with input exception and you need to read the error message and take the necessary action.
PS: The correct way to use postbacks is to use it as an event to fetch orderbook and then check if status and filled quantity is more than 0.
A 200 for order placement means order is placed successfully. It doesn't mean order is executed. An order goes through multiple system before it hits exchange and gets executed. You can view all the states by fetching the order history.
I understand that order placement does not mean execution. My query was regarding the random nature of order REJECTION - most of the times it is done via error response in Postback but few times a valid order_id is generated and then the order's status is updated as REJECTED.
In some cases, wherein order is blocked by our internal mini OMS, you will receive 400 response with input exception and you need to read the error message and take the necessary action.
Yes, I'm doing this only. But as mentioned previously, sometimes this error is not thrown. Is there some documentation on when an Error is thrown and when order_id is generated only to be later REJECTED?
PS: The correct way to use postbacks is to use it as an event to fetch orderbook and then check if status and filled quantity is more than 0.
@sujith This seems like a hack due to the non-reliable nature of Postback. If we were to use it, do we need to put some delay() between postback event and fetching of orderbook to ensure the order status is updated?
There are two types of response for an order placement. It is either 200 which means success or else error which will have non 200 response. You can refer to all the exceptions here. If an order is rejected by our internal mini RMS then you will see 400 response with Input Exception and a meaning full error message with a link to support article that explains error. If it goes through our systems and rejected by the OMS or exchange then you will see an entry in the orderbook with rejected status and an error message in status_message field.
Postbacks are asynchronous events sent by the OMS, Hence order is not guaranteed and there are some scenarios wherein OMS sends multiple messages for a single event. To cover all the scenarios, we have suggested an appropriate solution.
An order that is placed may or may not get rejected. One needs to fetch orderbook and check the latest status of the order.
In some cases, wherein order is blocked by our internal mini OMS, you will receive 400 response with input exception and you need to read the error message and take the necessary action.
PS: The correct way to use postbacks is to use it as an event to fetch orderbook and then check if status and filled quantity is more than 0.
If it goes through our systems and rejected by the OMS or exchange then you will see an entry in the orderbook with rejected status and an error message in status_message field.
Postbacks are asynchronous events sent by the OMS, Hence order is not guaranteed and there are some scenarios wherein OMS sends multiple messages for a single event. To cover all the scenarios, we have suggested an appropriate solution.
kc.placeOrder("regular", {
"exchange": "NFO",
"tradingsymbol": "NIFTY2320918100CE",
"transaction_type": "BUY",
"quantity": 50,
"product": "NRML",
"order_type": "LIMIT",
"price":20
}).then(function(resp) {
console.log(resp);
}).catch(function(err) {
console.log(err);
});
i am getting an error:
message: 'The instrument you are placing an order for has either expired or does not exist.'
can u tell what is wrong in this