☰
›

Non deterministic and inconsistent rate limit of 10 orders/sec

explorer
explorer in General
I trade large quantities and have been using API for couple of years now to place 40+ orders at any given point in time. Since last 4-6 months, I have started observing rate limit errors for order placement API. I implemented client side throttling 2 years ago where max 9 orders are placed per second with gap of 1 second between bursts. The implementation never resulted in "Maximum allowed order requests per second exceeded" errors in year 2025.

Interestingly, around May 2026 I started receiving many failures everyday due to too many order requests error. Observing that, I changed the throttling config to place 8 orders/second and then 6 orders/second. Changing from 8 to 6 orders per window reduced error rate but it was never zero.

Here is how the throttler works:
1. Accept all orders
2. Place 6 orders in burst
3. Wait 1 second
4. Place next 6 orders

Then I did few more experiments to understand rate limiter but with no complete success. The only way I was able to submit multiple order bursts was by increasing the window size to 1800ms and dropping orders per window to merely 7, down from 10. Following is one such log where 7 orders are placed every 1250ms. As you can see, first burst(1-7) was placed by 24.194 and the next burst (8-14) was placed after 1.2s at 25.439. This should have resulted in all successes. However, requests 13 and 14 failed. There is no explanation why requests 13, 14 failed despite being submitted after 1 second than the previous burst.

Timestamps in hh:mm:ss.SSS format.
7 orders per window, 1250ms window size

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
My observations suggest that rate limiter is not using known rate limiter algo viz. sliding window, sliding window log/counter, leaky/token bucket.

It would be very helpful if Kite team clarifies:
1. What algorithm is used for API/orders rate limiting?
2. What is the configuration for the algorithm?
3. The reason I am seeing inconsistent API responses?
4. What changed in 2026 vs 2025 that has suddenly caused order rejection considering no client changes.

Thank you for reading!
Tagged:
  • salim_chisty
    salim_chisty
    Based on the logs shared, it appears that more than 10 order requests were being submitted within a one-second interval, resulting in the rate-limit rejection. Please ensure that your implementation strictly adheres to the prescribed 10 orders-per-second limit. The rate limit works on a sliding window basis.

    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.
  • explorer
    explorer
    @salim_chisty instead of pointing vaguely that more than 10 orders were submitted, can you explain clearly which orders you referred to? I have checked multiple times and there is always more than one second gap between last order of the batch and the new batch.

    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?
  • explorer
    explorer
    Moreover, I have verified that 10 orders / second are allowed only when they are spaced 100ms apart. The problem is burst/batch requests despite being separated by more than 1 second.
Sign In or Register to comment.