It looks like you're new here. If you want to get involved, click one of these buttons!
7 orders per window, 1250ms window sizeMy observations suggest that rate limiter is not using known rate limiter algo viz. sliding window, sliding window log/counter, leaky/token bucket.
14:35:24.187 sending request number 1
14:35:24.191 sending request number 2
14:35:24.191 sending request number 3
14:35:24.192 sending request number 4
14:35:24.193 sending request number 5
14:35:24.193 sending request number 6
14:35:24.194 sending request number 7
14:35:24.341 request number 1 placed successfully
14:35:24.342 request number 2 placed successfully
14:35:24.351 request number 7 placed successfully
14:35:24.353 request number 4 placed successfully
14:35:24.387 request number 5 placed successfully
14:35:24.389 request number 3 placed successfully
14:35:24.395 request number 6 placed successfully
14:35:25.439 sending request number 8 (2nd burst after 1st burst was accepted and placed successfully)
14:35:25.440 sending request number 9
14:35:25.442 sending request number 10
14:35:25.443 sending request number 11
14:35:25.444 sending request number 12
14:35:25.444 sending request number 13
14:35:25.445 sending request number 14
14:35:25.466 request number 13 failed due to too many requests error
14:35:25.467 request number 14 failed due to too many requests error
14:35:25.467 request number 9 placed successfully
14:35:25.468 request number 10 placed successfully
14:35:25.469 request number 8 placed successfully
14:35:25.470 request number 12 placed successfully
14:35:25.470 request number 11 failed due to too many requests error
14:35:26.690 sending request number 15 (third burst)
14:35:26.718 request number 15 placed successfully
There have been no changes to the rate-limiting algorithm for such rejections. You can handle these responses programmatically using HTTP status code 429 (Too Many Requests) and implement appropriate retry/throttling logic. You may refer to the similar discussion here.
For example, request 7 from first batch was submitted at 14:35:24.194, while the next batch was submitted at 14:35:25.439 which is 1.2s gap. Where do you see smaller than 1s gap?
There are lot of things they can improve but it's pathetic.
I am using a mock Kite server to test such edges.
You can build it via Claude and test if your approach passes otherwise we can write them email.
Zerodha has implemented some kind of penalty for order bursts.
Where can we send email about this?
When operating very close to the limit, the timing of requests can overlap at the server side even if the client-side timestamps appear to be more than a second apart. We tested the rate-limiting behaviour independently, and it is working as intended.
For applications that generate concurrent order requests, we recommend maintaining sufficient headroom below the maximum rate. As a practical guideline, operating at around 60–70% of the documented limit provides a reasonable margin and reduces the likelihood of 429 responses during bursts or timing variations.
Applications should also handle HTTP 429 responses appropriately, using backoff before retrying.
Considering the scale of position size I am operating at, there is real impact to my trading account when I am not able to exit the position in market runaway situation where system SL is hit (orders not placed to Zerodha as limit orders) resulting into worse fill and ultimately slippage. This is tested, verified and hence this thread was created.
Can you please clarify following:
- What parameters were used in your testing? What was order burst size, and window length?
- You mentioned the behaviour is as intended. What is the intention?
- 6 orders burst size does not reliably result into all successful orders as I have proved in my first message in the thread. This is inline with your guidance that 60-70% of order limit should be followed. Despite being 60%, I still see order failures. Increasing it to 70% will result in even more.
- Why have you decided to penalize order bursts, while staggered 10 orders / second (i.e. 1 order every 100ms) go through successfully?
If I am repeatedly getting worse order fills due to Zerodha not supporting nominal order burst size, I will have to move my portfolio and trading to other brokers as the last resort. I have no other complaints of Kite API but order bursts not playing well is a deal breaker when there is real money impact.In your case, the requests are being sent concurrently. The rate limit is evaluated based on the requests received by the API within the applicable sliding window, so client-side timestamps alone cannot be used to determine exactly how the server-side rate-limit calculation will evaluate those requests.
The important point is that short bursts themselves are not prohibited. A burst of orders should be allowed as long as the number of requests falling within the applicable rate-limit window does not exceed 10 requests per second. The rate limiter is not intended to penalize a burst simply because the requests are concurrent.
Therefore, if a burst of 6 or 10 orders is resulting in HTTP 429 responses even though the requests fall within the documented 10 orders/second limit, we would need to investigate this against the actual server-side request timestamps and rate-limit calculation. Please raise a support ticket with the complete request/response logs, including precise timestamps, so that we can verify the server-side rate-limit behaviour and assist further.
We cannot increase the limit beyond 10 orders/second, as this is a regulatory requirement. If a strategy needs to place more than 10 orders per second, the strategy would need to be registered with the exchange. For more details, please raise a ticket.
Thank you for thorough reply. If it was not clear from my previous messages, nowhere I have asked to relax the limitation of 10 orders/second. All I have been complaining about is, despite staying within the said limit, the orders are rejected with HTTP 429.
I have prepared minimal reproducible steps in following Node.js script which fires 10 orders in batches. The batches are separated apart by 1550 ms gap which is much longer than advertised 10 orders/second limit. Script places 10 GTT orders and then waits 1.5 seconds to process the next batch so none of the orders should be rejected. However, 4-5 orders consistently get rejected. Following is the log to prove the same. Please let me know your findings once you run the following script, which is well within the advertised limit of 10 orders/second. I think this script provides more value than me creating a support ticket as you can reproduce the behavior in your environment quickly.
I am sure you are aware how to execute the script but if others are interested, here is how to run it:
As mentioned earlier, client-side timestamps alone cannot be used to determine exactly how the requests were evaluated against the server-side rate-limit window.
While the script and logs are useful for understanding the scenario, we need the request details from our systems to verify what happened for the specific account. Hence, please raise a support ticket and include the script, complete logs, and the relevant timestamps. We can then check the details and assist you further.
As 100ms orders are accepted, we cannot conclude that the order bursts client side timestamps are an issue. I have reproduced this issue on 2 separate accounts so far.
I will open up a support ticket.