@Sravanthi_bh thanks for checking. The close price is adjusted correctly without such a big gap down in trading view. This gap impacts backtests, can you please apply the adjustment to make it continuous like in tradingview?
@MAG sounds like averaging is not the reason then. Lets please not conflate data discrepancy and end use. I'm not looking at using history API for live trading
@rakeshr please take a look when you get the chance
Thanks for sharing this @MAG
Is the 3.05pm candle close recomputed based on the average price or only the 3.30pm candle? In the example above, 3.05pm candle has changed. If we need to consider averaging for all candles after 3pm, I'll add that to …
Past candle close seems to be changing @rakeshr Could you please confirm why this happens or if its a bug?
See one more example apart from AVALON below -
Local DB for 5 min intervals was caught up till 3.15pm Feb 20 '24 -
open=823.8, close=832.…
Thanks for the info @rakeshr I'll acount for the open price changing now.
Why did the 2024-02-07 15:23:00 close price for AVALON change? I'm trying to understand when price change is limited to past say 10 mins and when its due to corporate actions…
Yes @MAG I keep refreshing the current day's data trailing by 10 mins.
Key challenge is if a past candle changes, it could be due to corporate action or due to history data adjusting for late candles/processing. So we need to reload all candles wh…
@Kailash @nitin could you please have someone in engineering acknowledge seeing this bug report?
Apart from the history API, I use the RT streaming API. It's been working wonderfully for me. I understand these API subscriptions even at 48K/year don…
Here's another example for AVALON where close has changed between two API invocations. Volume does not change, so no additional ticks were received.
Yesterday response -
open=472.3, close=472.5, low=472.2, high=472.75, volume=1093.0, oi=0.0, symbo…
There seems to have been some instability in the auth system two days back at Kite API that triggered this. The issue got resolved after reverting to use separate request tokens for two systems and letting things idle over night.
+1 these changes to API contract should be published ahead of time via email with lead time of at least 6 months to adapt. It's standard practice for professional APIs
Thanks for looking into this @sujith will look forward to the next update and change to getholdings. Is there a plan to improve the oms sustem availability?
Related bug report - I've noticed this error as well when running getMargins(). Maybe connection handling in the SDK needs to be looked into as well?
java.lang.IllegalStateException: closed
at okio.RealBufferedSource.rangeEquals(RealBufferedSource…
Thanks for replying @rakeshr. Can you please add a backlog story to add externally provided UUID? Its a fairly common API construct and frankly a pretty obvious missing piece in a well designed API spec like Kite
