So, hypothetically, if you placed say 30 orders under one second, then I assume first 15 will go through. What will happen to last 30? Will they be rejected or the thread will get locked till 1 second is passed and then remaining will go through. If rejected, what will be the output through by API:
- will it be an Exception, if yes then what Exception. We will need to catch it. - or it will return an order_id but that order_id will get rejected and show REJECTED as status when orders are fetched?
While easy solution is to get the loop to sleep 5 ms after every order fired, but need to build protection against a scenario when more orders somehow go through.
I assume that the API will return error at 16th order in 1 second, because as per your comment, they won't go through.
I have 7 algos firing orders independently. Many of the initial orders are fired at 9:20am. It is quite possible that more than 15 orders are fired under 1 second.
This is a serious limitation, especially for an expensive service (2k per month) like this.
Either increase the limit to at least 50 orders per second and/or increase the buffering to 200+ orders. To stop high-frequency trading (to satisfy regulations), you can introduce wider constraints, like "less than 1000 orders/trades per day" or something like that.
Hi @skk, You will get rate limited if you go beyond rate limit, so your request will not go through, API will throw an error saying too many requests. and the error code will be 429.
@ramatius, Our leased lines that connect to the exchanges have a certain order per second capacity, exchanges themselves have a limit on how many orders they can handle per second. (NSE is at 50k orders per second). We as India still have a long way to catch up to international exchanges in terms of support infra. Kite connect is definitely not meant for a use case where you want to be firing multiple orders per second and if you are bothered about latency as orders can get into queue beyond the rate limiting.
If you are looking to do this, one of the way we will be able to support is by moving to our exchange colo (there are no leased line limitations). The fixed cost of being on the colo can be anywhere between Rs 1.5 to Rs 3 lks per month.
Colocation is too expensive for me at this point. For now I am staggering the orders to workaround this issue. Ideally, I shouldn't be doing this - slippage also increases. Hope you can increase the limits, at least to 20 trades per second, or buffer it up to 100 trades.
Place order API limit is 5 requests per second which can buffer up to 15 requests per second.
- will it be an Exception, if yes then what Exception. We will need to catch it.
- or it will return an order_id but that order_id will get rejected and show REJECTED as status when orders are fetched?
While easy solution is to get the loop to sleep 5 ms after every order fired, but need to build protection against a scenario when more orders somehow go through.
I have 7 algos firing orders independently. Many of the initial orders are fired at 9:20am. It is quite possible that more than 15 orders are fired under 1 second.
This is a serious limitation, especially for an expensive service (2k per month) like this.
Either increase the limit to at least 50 orders per second and/or increase the buffering to 200+ orders. To stop high-frequency trading (to satisfy regulations), you can introduce wider constraints, like "less than 1000 orders/trades per day" or something like that.
You will get rate limited if you go beyond rate limit, so your request will not go through, API will throw an error saying too many requests. and the error code will be 429.
@ramatius,
Our leased lines that connect to the exchanges have a certain order per second capacity, exchanges themselves have a limit on how many orders they can handle per second. (NSE is at 50k orders per second). We as India still have a long way to catch up to international exchanges in terms of support infra. Kite connect is definitely not meant for a use case where you want to be firing multiple orders per second and if you are bothered about latency as orders can get into queue beyond the rate limiting.
If you are looking to do this, one of the way we will be able to support is by moving to our exchange colo (there are no leased line limitations). The fixed cost of being on the colo can be anywhere between Rs 1.5 to Rs 3 lks per month.
For now I am staggering the orders to workaround this issue. Ideally, I shouldn't be doing this - slippage also increases.
Hope you can increase the limits, at least to 20 trades per second, or buffer it up to 100 trades.
You will get it as KiteException only with an error_message as too many requests and error_code will be 429. It is same as other exceptions.