@KD61 even with the calendar second method we still have the same issue that order may take longer to reach the broker or exchange (long enough that some orders spill over to the next calendar second).
Then if you shoot an order at 09:15:01.98, you won’t be sure how many orders you are allowed in the next calendar second 09:15:02 - 9 or 10 orders.
My point is if the order in the next calendar second 09:15:02 fails due to rate limiting error - when do you retry?
With rolling 1000ms method, you can retry immediately and likely get the order placed.
With the next calendar second method, you have to wait till 09:15:03 to try placing the failed order again.
Edit: you do raise a fair point that tracking orders may have some overhead - but I’m assuming you would (should) anyway be tracking orders even today to confirm that order was filled or not.
Edit 2: if we go with the calendar second system, broker/exchange systems will have variable loads with everyone shooting orders in the first 500ms of a calendar second just for safety - and actual transmission time to exchange and execution time for individual orders will become slower.
What exactly happens if say we exceed and send 11 orders ? Is there an error sent back ? Would you delay it on your side ? Drop it silently ?
Also, can you list out exactly which api end points are affected. Order create and modify ofc, but cancel too ? Reading orderbook ?
Right now i club them all together and i actually have a limit of 20 which seems to work. So i must have sent more than 10 (rarely), but don’t remember having any error.
Hopefully Zerodha can do this in time, other brokers (ICICI/Finvasia) seem to be going ahead and have sent emails.
Why is order cancellation also falling under 10 OPS limit? NSE/SEBI only mentioned limits on placing orders. Cancelling an order shouldn’t fall under those limits, should it?
Are we 100% sure about it? That cancel will also fall under this limit?
That’s a big shock for me. Earlier @siva informed us, cancel won’t fall under this.
Just to confirm, 20 legs of a single Iceberg order would still be considered as one order, correct?
The main issue with the current Iceberg functionality is that it sends the next leg only after the previous one is executed, which delays queueing in the order book.
Would it be possible for you to release a version of Iceberg that submits all legs at once?
Please implement order slicing for Equity with API support before this deadline. So we can reduce the OPS considerably. Just a request. Thank you Kite team
Currently, Zerodha allows auto-cancellation of orders after a fixed duration ranging from 1 minute to 120 minutes.
Would it be possible to allow auto-cancel timing to be set in seconds via the API? This would provide greater flexibility and help reduce API request usage. For instance, in my execution strategy, I often prefer to cancel orders after just a few seconds. Since that’s not currently possible, I have to send a separate cancel request, which eats into the 10-requests-per-second (OPS) limit.
Static IP Whitelisting Process - Potential Misuse and Suggested Improvements Current Process Understanding:
Users submit their static IP address through the broker’s web portal
System checks if the IP is already registered by another user
If not registered, the IP gets successfully registered under the submitting user’s name
Identified Issue:
The current implementation has a significant vulnerability where:
Intentional Misuse: Someone can deliberately register my IP address before I attempt to register
Accidental Entry: Users may mistakenly enter incorrect IP addresses, blocking legitimate owners
Dynamic IP Reassignment: If an IP was previously registered by another user and later assigned to me by my ISP, I cannot register despite being the legitimate current owner
Real-world Impact:
Legitimate users are blocked from registering their own IP addresses
No verification mechanism to confirm actual ownership/usage of the IP
Potential for malicious blocking of competitors or other users
Suggested Solutions:
1. IP Ownership Verification Process
Require users to access the registration portal FROM the IP address they wish to register
Only allow registration when the request originates from the claimed IP address
2. API Call Verification
Allow IP registration through web portal but mark as “Pending Verification”
Require at least one successful API call from the registered IP within 24-48 hours to confirm registration
Auto-expire unverified registrations after the timeout period
3. Active Usage Validation
Implement periodic validation (monthly/quarterly) requiring API activity from registered IPs
Auto-deregister IPs with no trading activity for extended periods
Send advance notifications before deregistration
4. Dispute Resolution Mechanism
Provide a process for users to claim ownership of their legitimate IP addresses
Require documentation (ISP letters, network configuration proofs) for disputed IPs
Allow override of existing registrations with proper verification
5. Enhanced Registration Flow
Step 1: User submits IP via web portal (from any location)
Step 2: System generates unique verification token
Step 3: User must access verification URL from the claimed IP address
Step 4: System confirms IP ownership and completes registration
Questions for Clarification:
Is there any current mechanism to handle IP address disputes?
Can you implement real-time IP verification during the registration process?
Is there a possibility to add IP ownership validation through API calls?
Request:
Please consider implementing enhanced IP validation mechanisms to prevent misuse while ensuring legitimate users can register their IP addresses without unnecessary obstacles. Looking forward to your response and potential improvements to this critical security process.
