I am tired of pointing this out again and again. This is the reason why the kite web platform won't accurately display the latest candle, hence corrupting the indicator data. Since websockets can give only the latest ltp, and not the latest candle data, we are forced to store tick data, because minute candle api won't give latest candle data. All because of this, all of my trades are delayed by a minute to reliably get accurate data.
@vivek@Kailash@sujith@nithin Please do something about this. I am tired of compromising on my trading strategy because your api isn't best of its class.
@charuvindatre unfortunately there are several technical complexities in forming and streaming whole candles in real-time, where they change every millisecond. 1 minute is the best granularity we can offer. You should stream data using WebSockets and form your own candles. If your trading is extremely latency critical, retail trading platforms and APIs will never be enough.
... your api isn't best of its class.
Sorry about that. While we are continuously working on improving our APIs, this is not a claim we have made. Also, there are no other APIs in the class to compare.
I am not asking you to stream minute candles, just asking to include latest candle data in the historical API.
Consider your web platform kite, for a moment. When a chart is loaded, previous minute candles are loaded using historical API, and future candles are formed using websocket streaming tick data, is that correct? Your customers are getting those 'inaccurate' candles anyway for the current minute candle and future candles, while they're trading or unless they reload the page. All I am asking is why can't you cache the current minute candle in your historical minute candle API using websockets streaming data, and then correct it later when you get the data from TR? I don't think that is hard to implement. Atleast when a user opens charts in kiteweb/pi/app etc he would get an approximate current minute candle (instead of a blank line we get usually). It would be helpful for us as well, because we won't have to worry about storing tick data, and this is going to become an issue when you start limiting multiple connections to the websocket api.
TL;DR update the latest minute candle using websocket tick data, and then correct it when you get the data from TR. I don't think that is hard to implement (and this is how you make you api best of its class).
I am not asking you to stream minute candles, just asking to include latest candle data in the historical API.
Consider your web platform kite, for a moment. When a chart is loaded, previous minute candles are loaded using historical API, and future candles are formed using websocket streaming tick data, is that correct? Your customers are getting those 'inaccurate' candles anyway for the current minute candle and future candles, while they're trading or unless they reload the page. All I am asking is why can't you cache the current minute candle in your historical minute candle API using websockets streaming data, and then correct it later when you get the data from TR? I don't think that is hard to implement. Atleast when a user opens charts in kiteweb/pi/app etc he would get an approximate current minute candle (instead of a blank line we get usually). It would be helpful for us as well, because we won't have to worry about storing tick data, and this is going to become an issue when you start limiting multiple connections to the websocket api.
TL;DR update the latest minute candle using websocket tick data, and then correct it when you get the data from TR. I don't think that is hard to implement (and this is how you make you api best of its class).