We will soon start running into order rate limits imposed by kite.
We have already deployed one strategy with NF and BNF contracts which runs successfully.
We plan two add two more strategy soon: one for F&O listed stocks (there are around 200+ instruments) and one for intraday cash only (all instruments from nifty 100).
Once we put all three strategies to PROD, through three kiteticker instances, it is likely that every 15th minutes there are several orders placed across ticker instances. I am 100% sure it would be more than 10 as some or the other instrument will generate trigger on 15 minute candles.
Here we are going to hit the limit of 10 orders per sec very soon and once this happens, we will run into large impact cost as placing orders will take much more time than 1 second ( As obviously, as the delay increases, so the impact cost. )
So, the question is: How to reduce the delay between trigger and ALL orders execution. ideally all orders should be executed instantly as the trigger happens. But due to order rate limit per sec it will take around 5-10 secs (this is our current estimate) to finish sending all orders. We need legitimate ways to overcome the 10 orders per sec limit imposed by your RMS.
> Shall creating more than one kite connect app and putting strategies across different apps will help? -> if not, shall we create more user accounts to achieve this? -> if not, what do you propose? All we need is more than 10 orders per sec. If we dont get this, we will hit the wall soon and it's big showstoper for us.
One more thing: we are not going to cross 200 orders per min and 2000 orders per day despite subscribing 300+ instruments. It's only per sec limit bothers us, causing us large impact cost as we are forced to put SLEEP function in our order place API to avoid rate limit per sec.
Oh,I am really sorry. I was wrong. Looks like the order place limit of 10 r/s is also per user_id after reading the article.
PS.-Now,I am confused too. Sujith Sir told here and in few other discussions
that all api limits are per api_key. That's what I knew. But,the support article you mentioned says it's per user. https://kite.trade/forum/discussion/comment/35355/#Comment_35355
@Sujith Sir, @rakeshr Sir. Please clarify if the order place limit of 10r/s is per api_key or per user_id.
Aah this breaks the heart. As an indvidual we are not allowed to setup multiple accounts per PAN.
I am OK if we have to pay to cross the per sec limit, but restricting to 10 orders per sec is a clear dealbreaker. We have genuine requirement where we need to cross this limit at least twice a day.
After all one of the zerodha mission is to reduce the impact cost of trade, can you give me some pointers to help me on this? I am ready to talk if this needs approval from someone.
@tapanjbhatt ,
Yes,I understand. Let's wait for Sujith Sir or Rakesh Sir response. I guess the order limit per second should be per api_key, that's what Sujith Sir told in the thread I mentioned,and that's what seems logical too.
Looks like the order place limit of 10 r/s is also per user_id after reading the article.
Rate limits are based per api_key. Place orders rate limits are per minute i.e 200 orders per minute and the rest of all GET requests are rate-limited per second.
I understand that all rate limits are per api_key,only max cap on the number of orders per day are user_id based as told by Sujith Sir in the thread I mentioned. But,the confusion is about the order placement API. Actually,my doubt was if the 10r/s and 200 /minute limit for order placement API is per api_key or per user_id(Zerodha Account). Because,the support article mentioned in the above comment by @tapanjbhatt says it's per user_id. The answers by you and Sujith Sir suggest that all APIs limits including order placement API are per api_key.
In short,is it possible to cross this 10r/s and 200/min for order placement by creating more KiteConnect apps with same user_id?
This solves our problem (which is yet to occur in future ), we will use more apps when we hit the wall. Thanks all involved for clarification @SRIJAN@rakeshr@sujith
Just wanted to double confirm: the 10 orders per sec limit is per api_key and not per user right?
This support article talks about "single user will not be able to place more than....." so I was led to believe rate limit is per user.
PS.-Now,I am confused too. Sujith Sir told here and in few other discussions
that all api limits are per api_key. That's what I knew. But,the support article you mentioned says it's per user.
https://kite.trade/forum/discussion/comment/35355/#Comment_35355
@Sujith Sir, @rakeshr Sir. Please clarify if the order place limit of 10r/s is per api_key or per user_id.
Aah this breaks the heart. As an indvidual we are not allowed to setup multiple accounts per PAN.
I am OK if we have to pay to cross the per sec limit, but restricting to 10 orders per sec is a clear dealbreaker. We have genuine requirement where we need to cross this limit at least twice a day.
After all one of the zerodha mission is to reduce the impact cost of trade, can you give me some pointers to help me on this? I am ready to talk if this needs approval from someone.
Yes,I understand. Let's wait for Sujith Sir or Rakesh Sir response. I guess the order limit per second should be per api_key, that's what Sujith Sir told in the thread I mentioned,and that's what seems logical too.
I understand that all rate limits are per api_key,only max cap on the number of orders per day are user_id based as told by Sujith Sir in the thread I mentioned. But,the confusion is about the order placement API. Actually,my doubt was if the 10r/s and 200 /minute limit for order placement API is per api_key or per user_id(Zerodha Account). Because,the support article mentioned in the above comment by @tapanjbhatt says it's per user_id. The answers by you and Sujith Sir suggest that all APIs limits including order placement API are per api_key.
In short,is it possible to cross this 10r/s and 200/min for order placement by creating more KiteConnect apps with same user_id?
The client level limit is 2000 regular orders per day and 2000 cover orders per day.
Thank you so much for the clarification.