Observations, suggestions

joy · February 2017

I am working on the Kite API and I am presenting some of my observations.

First let me point out a couple of possible bugs

I submitted an order at market open which unfortunately returned.

13Feb17 09:15:02 : KiteConnectViewModel.ParseResponse : OrderId = {"status": "error", "message": "Couldn't connect to nest gateway", "error_type": "NetworkException"}
13Feb17 09:15:02 : KiteConnectViewModel.ParseResponse : OrderId : error (BadGateway|NetworkException) : Couldn't connect to nest gateway

However the order was successfully placed the orderId being 170213000012452

I had 2 (two) open mis orders (order id 17013000487435 and 170213000481076) which was duly cancelled by Admin at the end of the day. I received the postback for order id 17013000487435 twice while NO postbacks for order id 170213000481076. Would request you to kindly verify at your end. Below are the postbacks I received:

13Feb17 15:19:09 : KiteConnectViewModel.OnOrdersReceived : {"order_id":"170213000487435","exchange_order_id":"1200000004188242","order_timestamp":"2017-02-13 15:19:07","exchange_timestamp":"13-Feb-2017 15:19:07","status":"CANCELLED","status_message":"","placed_by":"USER ID","user_id":"USER ID","tradingsymbol":"RPOWER","exchange":"NSE","transaction_type":"BUY","order_type":"LIMIT","quantity":1,"filled_quantity":0,"unfilled_quantity":1,"price":43,"average_price":0,"trigger_price":0,"product":"MIS","validity":"DAY","tag":"d55adc3e","checksum":"2d6cf73d52166a3c04ca61924660956b7585ce9a76a86bf2324bc7978fca0550"}
13Feb17 15:19:09 : KiteConnectViewModel.OnOrderReceived : Is api submitted = True
13Feb17 15:19:09 : KiteConnectViewModel.OnOrdersReceived : {"order_id":"170213000487435","exchange_order_id":"1200000004188242","order_timestamp":"2017-02-13 15:19:07","exchange_timestamp":"13-Feb-2017 15:19:07","status":"CANCELLED","status_message":"","placed_by":"USER ID","user_id":"USER ID","tradingsymbol":"RPOWER","exchange":"NSE","transaction_type":"BUY","order_type":"LIMIT","quantity":1,"filled_quantity":0,"unfilled_quantity":0,"price":43,"average_price":0,"trigger_price":0,"product":"MIS","validity":"DAY","tag":"d55adc3e","checksum":"2d6cf73d52166a3c04ca61924660956b7585ce9a76a86bf2324bc7978fca0550"}
13Feb17 15:19:09 : KiteConnectViewModel.OnOrderReceived : Is api submitted = True

Please allow me to discuss some structural issues with the api.

Currently the postbacks are triggered only when the order gets filled, cancelled or rejected. This is grossly insufficient as there may be scenarios where the client needs to know the order state. Let me give some examples

I placed an order at market open. The order status was stuck at "open pending" for more than a minute. In absence of postbacks we have no way to know when the order will be available for modification/cancellation. Any modification (or cancellation) will fail during this period.

Heres the original order.

13Feb17 09:15:10 : KiteConnectViewModel.ParseResponse : OrderId = {"status": "success", "data": {"order_id": "170213000013217"}}

I sent a modification request while the order is still in "open pending" state and the response returns a success (shouldnt be the case)

13Feb17 09:15:22 : KiteConnectViewModel.ParseResponse : OrderId = {"status": "success", "data": {"order_id": "170213000013217"}}

Take another scenario. If an order is modified beyond the days price range then such modification request is rejected (status = not modified). However there are no postbacks for the same and in absence of any postbacks the client has no way to know the status. The response of any such request however returns success (shouldnt be the case).

13Feb17 09:21:34 : KiteConnectViewModel.ParseResponse : OrderId = {"status": "success", "data": {"order_id": "170213000020252"}}

The client app will go haywire in absence of a due postback. In such scenarios either give postbacks (preferred) or the response should return an exception.

Postbacks are available for orders placed by the api only. If the order is place via a different client (like NestTrader) the postbacks wont be available for any such external orders.

The API should be agnostic in nature and should return all orders irrespective of where the order is generated. Take for example admin submitted/modified/cancelled orders, where the client have no way to know the status.

Currently the websocket packets includes too many static data (like Opening price, previous close etc) resulting in huge data usage. This has rightly been discussed here https://kite.trade/forum/discussion/comment/1407#Comment_1407

Static data should be transmitted only once (when the instrument requests for subscription) and thereafter the data is streamed only when there is an update. I sincerely hope the new version address this scenario.

Currently mode "quote" does not provides current bid/current ask information. As such i have to subscribe mode == "full" to get the current bid/current ask info even when I do not require the full order book. the mode "quote" should include what is popularly known as level1 data and mode "full" should include level2 data.

my 2¢. tia

sujith · February 2017

Hi @joy,

I submitted an order at market open which unfortunately returned.

13Feb17 09:15:02 : KiteConnectViewModel.ParseResponse : OrderId = {"status": "error", "message": "Couldn't connect to nest gateway", "error_type": "NetworkException"}
13Feb17 09:15:02 : KiteConnectViewModel.ParseResponse : OrderId : error (BadGateway|NetworkException) : Couldn't connect to nest gateway

However the order was successfully placed the orderId being 170213000012452

We have been able to locate the issue, we are working to fix it.

Orders 17013000487435 and 170213000481076 were cancelled from your app. Hence you got postback. We only send postback, if order is placed from your platform. We received 500 from your endpoint, I guess that is the reason for the issue. Check out the following logs,

521810:INFO:2017/02/13 15:19:09 Postback *.ashx -> 500
521812:INFO:2017/02/13 15:19:09 Postback *.ashx -> 200
521819:INFO:2017/02/13 15:19:09 Postback *.ashx -> 200
521829:INFO:2017/02/13 15:19:09 Postback *.ashx -> 500

Currently the postbacks are triggered only when the order gets filled, cancelled or rejected. This is grossly insufficient as there may be scenarios where the client needs to know the order state.

Your point makes sense, in future releases we will send postbacks for order status changes.

Take another scenario. If an order is modified beyond the days price range then such modification request is rejected (status = not modified). However there are no postbacks for the same and in absence of any postbacks the client has no way to know the status. The response of any such request however returns success (shouldnt be the case).

We have come across this scenario, problem is we don't have sufficient data here. We are in talks with our vendors to fix it.

Postbacks are available for orders placed by the api only. If the order is place via a different client (like NestTrader) the postbacks wont be available for any such external orders.

I am afraid that is not possible. User data cannot be shared with a third party app when an action is not originating from the app itself.

This is simply out of consideration for our user's privacy.

Currently the websocket packets includes too many static data (like Opening price, previous close etc) resulting in huge data usage.

We are planning to come up with solution wherein, clients can subscribe for each field. Hope that answers your query.

joy · February 2017

I submitted an order at market open which unfortunately returned.

13Feb17 09:15:02 : KiteConnectViewModel.ParseResponse : OrderId = {"status": "error", "message": "Couldn't connect to nest gateway", "error_type": "NetworkException"}
13Feb17 09:15:02 : KiteConnectViewModel.ParseResponse : OrderId : error (BadGateway|NetworkException) : Couldn't connect to nest gateway

However the order was successfully placed the orderId being 170213000012452
We have been able to locate the issue, we are working to fix it.

ok thats great.

521810:INFO:2017/02/13 15:19:09 Postback *.ashx -> 500
521812:INFO:2017/02/13 15:19:09 Postback *.ashx -> 200
521819:INFO:2017/02/13 15:19:09 Postback *.ashx -> 200
521829:INFO:2017/02/13 15:19:09 Postback *.ashx -> 500

Thanks for the heads up. Was able to identify the scenario at server end

The process cannot access the file 'D:\home\site\wwwroot\Postback_20170213.txt' because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

Currently the postbacks are triggered only when the order gets filled, cancelled or rejected. This is grossly insufficient as there may be scenarios where the client needs to know the order state.
Your point makes sense, in future releases we will send postbacks for order status changes.

ok, thats good news

Take another scenario. If an order is modified beyond the days price range then such modification request is rejected (status = not modified). However there are no postbacks for the same and in absence of any postbacks the client has no way to know the status. The response of any such request however returns success (shouldnt be the case).
We have come across this scenario, problem is we don't have sufficient data here. We are in talks with our vendors to fix it.

This is certainly a required feature. As an alternative can you please create an endpoint which will give the current days upper and lower circuit limit information (or include it with the instruments data) so that we can check it in our app itself.

Postbacks are available for orders placed by the api only. If the order is place via a different client (like NestTrader) the postbacks wont be available for any such external orders.
I am afraid that is not possible. User data cannot be shared with a third party app when an action is not originating from the app itself.

This is simply out of consideration for our user's privacy.

The /orders call returns all available values irrespective of whether the orders have been submitted via the api or not. So non-sharing of cross-api data is not the problem, its already there.

I presume since the postbacks are on an external site you might be reluctant to share any data as that might lead you to legal quicksand. If this is true, then will the next major release, have all the postbacks given the postbacks are planned to be streamed via the websocket itself. Or is the postbacks are linked to the api by design and any modification will require too much overhead?

Currently the websocket packets includes too many static data (like Opening price, previous close etc) resulting in huge data usage.
We are planning to come up with solution wherein, clients can subscribe for each field. Hope that answers your query.

That's good news again.

thanks again and much appreciated for your time.

sujith · February 2017

Hi @joy,
I am afraid, we can't make changes to postbacks API because postbacks are mainly based on api_key.
We are planning to send order notifications via websockets in future. I hope that serves your purpose.

Howdy, Stranger!

Categories

In this Discussion

Observations, suggestions