It could be because of a lot of reasons it might because of the lease line, could be because of network drop at OMS or Kite trade to OMS or client internet connection with Kite trade.
You need to catch the exception check orderbook and then retry if…
Is this consistent or intermittent? Can you let us know at what time you tried?
We had tried this but couldn't reproduce. But again it could be because of off-market hours as you have mentioned above.
At open OHL will be the first LTP, close will be the previous day's close.
Also assume that we use historical data for backtesting but why not its same like real time otherwise real time trading will be get false signals.
You can refer to this threa…
We provide historical data for backtesting purposes only. We recommend generating candles at your end using the live market data provided via Websockets API.
You can get started here.
Historical data is provided for backtesting purposes only. It is not meant for live strategies. We suggest generating candles at your end using the live market data provided via Websocket.
You can get started here.
Hi @ramatius,
I am afraid, we can't remove this. These are the new fields that are required for building new features for our platforms.
Ideally, if we add new fields then your app shouldn't break.
Are you sure you are sending the right auth header?
I would suggest running in debug mode to get the complete stack trace with the response code including order placement param.
I think the link provided by ngrok itself if https isn't it.
Method not allowed is because your program is not accepting POST request. I think your server has to accept the POST request with data in the form body.
A Guid is a unique id for each order for each client assigned by the system. It was a mismap of the error message for the rate limit. This was fixed yesterday. I don't think you will see this again.
No, from the next October the tradingsymbol will have o for October, n for November and d for December.
The month value is 1, 2, 3, 4, 5, 6, 7, 8, 9, O, N, D
Can you switch to some other ISP and give it a try?
We haven't observed any issues like this and 8 requests failing out of 13 requests is a huge drop rate.
If we had an issue like this then it would be chaotic.
This is very unlikely because the server should through a timeout at least if request doesn't go through or the client should time out.
Can you paste complete stacktrace here?
No system can guarantee a 100% uptime. Even the biggest tech giants have gone down multiple times in recent months. We try hard to not let it happen but there are so many systems, so many vendors anything can happen anytime.
I suggest modifying you…
If it is a get request then you can retry, if the request is POST, PUT or DELETE then you need to check orderbook and then retry.
If you blindly retry then you might end up placing two orders.
When you subscribe for an instrument by default you will receive data in quote mode which doesn't contain depth data. You need to set to full mode to receive market depth data.
Hi @v4run1337,
This forum is dedicated only to Kite Connect related queries. Please write to kite(at)zerodha.com for Kite feature requests and feedback.
You are placing the order in such a way that you become the seller and buyer. Hence your order gets rejected. You need to have a significant difference in target and stop-loss values.
There is no queue in calling the callback. You will end up blocking the main thread. You may use promise or use asyc to do your stuff.
You will have no control over the onTick callback. It is an event-driven mechanism.
The method for modifying the bracket order and cover order is the same.
It is not enough to send one param. You need to send additional params as mentioned in the example.
You always send the total quantity of the order. End-user shouldn't worry a…
The new backend for the Kite Ticker is deployed. The issues you had reported shouldn't happen from now on.
You can let us know here if you spot anything related to this.
As mentioned earlier, we don't have any issues with order placements at our end. You need to give us the exact params to reproduce.
For the above-mentioned params, it seems to be working fine.
This file is updated by the RMS team and it is updated manually multiple times during the day.
Can you let us know exactly what is the issue and which instrument has the issue?
You haven't defined the order variable and what if an order is parent order, a parent order will not have parentOrderId.
PS: We use the same code in our production apps. You must be going wrong somewhere. I suggest going through codebase properly o…
