NSE released a circular on July 22 describing detailed operating procedures for algo trading and API products. Here's a very brief overview of what would change for Kite Connect users:
You'll need a static IP. We'll soon allow Kite Connect users to enter their static IP on the Kite Connect developer console. As a user, you'd only have to acquire one and enter it on the dev console.
NSE allows for one additional static IP as backup, so you may want to consider getting two.
You'll need to ensure your strategies don't place more than 10 orders per second. Any order requests over 10 in a given second will be rejected with a 429 response.
Get your strategies registered if they place more than 10 orders per second. For registration, you'll need:
Auditor certificate as per Annexure 7
Strategy writeup
RMS writeup
We've (the broker community) already made a representation to the exchange to do away with the requirement for auditor certificates.
We'll accept requests for registering algos over support tickets. More details on this soon.
The SOP requires that all algo strategies be hosted on the broker's cloud. We've requested the exchanges and SEBI to reconsider this requirement. We've also requested the exchanges and SEBI for more time to go live, since the SOP was only released on July 22 with a go-live date of August 1.
The SOP requires that all algo strategies be hosted on the broker's cloud.
can you please point out the specific page numbers/document which has this requirement? and do you mean ALL algo strategies or only those which exceed 10 OPS?
Hi Zerodha team, Pls clarify the following: a) Will I able to able to have multiple apps in the same kite developer account each one mapped to a different zerodha account. b) Will the static IP mapping happen at developer account level or the app level c) If I have two machines- first one with primary static IP and second one with secondary static IP, both mapped to the same API. Will I be able to establish web socket connection simultaneously connect both the machine.
Please clarify: 1.JIO FIBER does not give static IP for personal use, its available for buisness users/on request "JioFiber does not offer static IPs on their standard consumer broadband plans. Static IPs are typically available with their Internet Leased Line (ILL) services, which are designed for businesses."
2. I use third party application to place order like algo baba Stoxoo,, but orders less than 10/sec,, what is required to continue in same way?
Would be great if you could clarify the following @Matti ?
1. Will IPV6 address be accepted for static IPs requirement ? If no, please make a representation for it . Why waste IPV4s which are already scarce ?
2. Will all other api endpoints other than orders , be accessible from any arbitrary IP ?
Can Zerodha Team also clarify on the requirements about showing evidence of ownership of static IP address ? It's being floated in many online forums . Can @Matti confirm whether such a requirement has been mandated by regulator. If so, it will be very difficult to conform to by individual trader cum developer. Most of us rely on cloud service provider to run our setups. The most we can do is to reserve a IPV4/IPV6 address for an instance and submit it to the broker. How do we provide evidence of having ownership of IP address ? Thank you.
If I am.using stoxxo to place order in zerodha via zerodha api under limit restriction how its impacting me?
If you're using an individual API key, you'll need to map it to a static IP and send orders from that IP only.
can you please point out the specific page numbers/document which has this requirement? and do you mean ALL algo strategies or only those which exceed 10 OPS?
This is from clause 14 which points back to this NSE ciucular. See I.h. here.
Will I able to able to have multiple apps in the same kite developer account each one mapped to a different zerodha account.
Yes.
Will the static IP mapping happen at developer account level or the app level
Neither, actually. It will be on the Zerodha account level.
If I have two machines- first one with primary static IP and second one with secondary static IP, both mapped to the same API. Will I be able to establish web socket connection simultaneously connect both the machine.
Within limits, yes.
1.JIO FIBER does not give static IP for personal use, its available for buisness users/on request "JioFiber does not offer static IPs on their standard consumer broadband plans. Static IPs are typically available with their Internet Leased Line (ILL) services, which are designed for businesses."
2. I use third party application to place order like algo baba Stoxoo,, but orders less than 10/sec,, what is required to continue in same way?
1. You'll have to find an ISP or cloud service provider or VPC provider to get a static IP. 2. You'll still need a static IP.
1. For Orders Per Second (OPS) threshold, iceberg orders will be considered one OPS or OPS will be the legs of the iceberg?
2. Is 10 OPS per client or per app?
3. Will strategy registration be free with code black box to broker/exchange/SEBI?
1. It'll be one order. 2. It is per client. 3. No, exchange charges will be passed on to the customer. Exact pricing isn't indicated in the circular.
1. Will IPV6 address be accepted for static IPs requirement ? If no, please make a representation for it . Why waste IPV4s which are already scarce ? 2. Will all other api endpoints other than orders , be accessible from any arbitrary IP ?
Yes, and yes.
Can Zerodha Team also clarify on the requirements about showing evidence of ownership of static IP address ? It's being floated in many online forums .
There isn't such a requirement. We'll do a uniqueness check to ensure users can't share IPs between each other, but nothing more than that.
Will there be any restriction on market orders placed via API ?
Market orders won't be allowed for the commodity segment. The other segments will allow market orders with market protection.
One broker pointed me to this circular - NSE/MSD/67753 - basis which they are not going to allow market orders via API. Can you please confirm whether you will continue to allow market orders in segments other than Commodity?
Does that mean if we place order_type=MARKET using the API it will automatically be converted to market orders with market protection? If not, will the API be updated to include this order type?
@Matti What if I only want to use the kite API for websocket data purposes and not for order placement. I have my own charting and analysis platform and want to continue using it. I can place orders manually on kite web but I need the API for realtime data
The timeline for implementation of SEBI circular SEBI/HO/MIRSD/MIRSD-PoD/P/CIR/2025/0000013 on "Safer participation of retail investors in Algorithmic trading" has been extended from August 1, 2025 to October 1, 2025. You may refer to the circular for more details.
Suppose I manage a friend's trading algorithm. Both of us have separate APIs and each API has its own unique static IP address.
Now, to log in to his API, can I generate the `request_token` for his account from my own laptop, where my personal trading account is already logged in? Would doing this cause any compliance or technical issues for me in the future?
Here's what I understand so far:
1. SEBI/NSE/BSE might want to capture the IP addresses for critical actions such as PLACE_ORDER, MODIFY-ORDER, and CANCEL_ORDER. 2. They might also track IP addresses for other actions like LOGIN, GET-ORDERBOOK, GET-POSITIONS, etc. 3. I have access to my friend's account — can I log in to his account on my machine just to generate the `request_token`?
Please clarify whether this kind of cross-account login from the same IP or system might raise any regulatory red flags or API-level issues.
Does that mean if we place order_type=MARKET using the API it will automatically be converted to market orders with market protection? If not, will the API be updated to include this order type?
One broker pointed me to this circular - NSE/MSD/67753 - basis which they are not going to allow market orders via API. Can you please confirm whether you will continue to allow market orders in segments other than Commodity?
Does that mean if we place order_type=MARKET using the API it will automatically be converted to market orders with market protection? If not, will the API be updated to include this order type?
We'll enable market protection by default for all market orders from the API. We'll allow such "protected" market orders only on the APIs for non-commodity segments.
how about sharing single static ip within 2 family members?
Eventually, yes. Imediately though, this wouldn't be possible.
What if I only want to use the kite API for websocket data purposes and not for order placement. I have my own charting and analysis platform and want to continue using it. I can place orders manually on kite web but I need the API for realtime data
We'll only be placing the IP check on the order endpoints.
Please clarify whether this kind of cross-account login from the same IP or system might raise any regulatory red flags or API-level issues.
While there shouldn't be any technical issues with this, you aren't supposed to access other people's accounts, so you'll have to ensure there are no disputes.
Hi @Matti Suggestion: IP Ownership Validation at the Time of Registration I wanted to bring up a potential issue regarding how IP addresses (IPv4/IPv6) are registered in the Kite API app. Right now, with other brokers there doesn’t seem to be any validation step to confirm that the person registering an IP actually owns or controls it. This can create a few edge cases where legitimate users are blocked from using their own IPs.
A couple of scenarios to consider: 1. Cloud/VPN/Proxy Static/Elastic IPv4/IPv6 reuse Say someone rents an IP from a cloud provider (AWS, GCP, etc.), registers it in their Kite app, but later stops trading and shuts down the server, without removing the IPv4/IPv6 address from the app. That IP eventually gets reassigned by the provider to someone else, but when the new user tries to register it, they’re blocked because it’s already tied to another account. So now, even though they fully control the IP, they can’t use it.
2. Malicious or premature registration In another case, someone with bad intentions could register someone else’s IP before the actual owner does. They might’ve guessed it or obtained it in some way. When the real owner tries to register the IP, they’re told it’s already taken, even though it’s rightfully theirs.
Possible Solution The simplest fix might be to validate that the user actually controls the IP at the time they register it. A few ways to do this:
Source IP validation: When someone enters an IP in the app, require them to send an API request from that same IP. You can compare the IP from the request headers (`X-Forwarded-For`, `CF-Connecting-IP`, `X-Real-IP`, etc.) with the IP being registered. If it matches, allow it.
Optional verification token: As an added step, you could return a short-lived token and ask the user to hit an endpoint from the IP they want to register, using that token. If they can do that, it's a good sign they control it.
Handling inactive IPs: If an IP has been registered but hasn’t made any API requests in, say, 15–45 days, maybe flag it as stale and allow another user to try claiming it again, assuming they can prove ownership via the method above.
Grace period for current owners: If a new user tries to register an already-registered IP, notify the current owner and give them a few days to revalidate. If they don’t, release it to the new user who can prove control.
This will help us: Prevents IPs from getting “stuck” in abandoned accounts. Avoids blocking users who receive reassigned IPs from cloud providers. Stops bad actors from registering IPs they don’t actually control. Keeps the IP whitelist accurate and relevant.
We're concerned about this issue, so please let us know how Zerodha plans to handle it.
@drjunemoone it sounds like you're an algo provider to be concerned about cloud providers repurposing static IPs across various users?
Handling inactive IPs is fine theoretically, but conversely it just adds overhead if I have to compulsorily shoot an order from my IP (that I paid for) every few days or authenticate at some regular interval.
Remember that a Zerodha API key still needs to be subscribed to for 500rs per month. If someone doesn't pay, I expect their api_key is deleted and the static IP will automatically be freed up for linking with others. @Zerodha team can confirm if this understanding is right.
If someone is paying for the API, Zerodha can't arbitrarily assume after 15-45 days that the static IP is free to be repurposed if there are no orders going through it. The original person who registered may just be in the research phase.
@drjunemoone IMO you should direct this question to any broker which offers free API services (just remember that if you're not paying for the product, you may be the product). If you get a response from those other brokers, please post it here.
That's just my $0.02. Interested in Zerodha team's perspectives @Matti@siva
Mr sbalaji987, I’ve already raised this question directly with the broker I have an account with, and I’ve also asked a friend to do the same with every broker they use including ones that offer free API access.
I’m not particularly concerned with how you’ve interpreted my earlier comment. What does matter to me is how the Zerodha team @Matti@siva plans to address what seems like a real and looming/overlooked issue.
In almost every case where I add any sort of contact or identification detail to my account, whether it’s an email address, phone number, or a document. I’m required to validate ownership. That might involve a one-time code, a verification link, or even uploading documents as proof. This is standard practice to ensure that I’m the rightful owner of the information I’m associating with my account.
So it feels inconsistent, and honestly very risky to allow something like an IPv4/IPv6 address to be added without any form of ownership validation. It effectively leaves the system open to spoofing, where anyone can register any IP address, even if they don’t own or control it. That’s a serious vulnerability.
It would not be just a technical oversight, it would cause real-world problems for users. At best, it’s chaotic, at worst, it’s exploitable.
I hope the zerodha team takes this seriously and considers adding a proper verification step for IP addresses, just as is done with other sensitive account information.
@drjunemoone no offense intended. It's just that this is a paid API so generally only serious users will use it. And once you register an IP address, a malicious actor can't willy nilly change it just to spoof someone else's account. People can only update IP addresses once a week.
In your scenario 2 - the malicious actor would be paying 500rs per month just to temporarily stop someone from trading, and they wouldn't even know if whoever they want to stop from trading just changed their IP and resumed trading. The malicious actor may keep paying indefinitely. I think this is a highly unrealistic scenario.
@Matti thanks for the response. Case by case review based on support tickets does make sense since this is likely to be a very rare issue for a paid API.
If this does become a problem for a lot of users, we'll automatically remove unused IPs after x period of inactivity.
This is just for users who stopped paying for the data/orders API, right? Or for any unused IP regardless of payment status? I think it should be the former. That should resolve @drjunemoone 's scenario 1: Cloud/VPN/Proxy Static/Elastic IPv4/IPv6 reuse.
Thanks@Mattifor your response. However, I believe the most effective and technically straightforward solution would be to validate the IP address at the time of registration itself. This approach is very similar to how email addresses and phone numbers are verified through a simple validation step that proves IP ownership right at the start.
Doing this would address the core issue upfront. If someone tries to register an IP that’s already associated with another client, instead of outright rejecting it (as some brokers are doing right now), you could prompt them to validate ownership. If they can demonstrate control over that IP address, just as we do with email or mobile verification, or by utilizing the connect IP information, the registration process can be automated as well. In such cases, the registration should proceed., and the previously registered (but now invalid) association can be removed, since the former user no longer owns or controls that IP.
Also, @sbalaji987 , Zerodha’s trading API is FREE for users who only place orders (where actual IP validation will occur), the ₹500 fee doesn’t apply in those cases. I’ve personally seen people using market data from other brokers while executing trades through Zerodha. So, tying this issue to whether the API is paid or free isn’t really relevant, this is a technical and real concern that applies across the board.
@Matti@siva ,I eagerly await for your response in light of the information provided. Thank You.
I still think it's an edge case (especially the malicious scenario), but now I agree some minimal verification might need to be implemented. Perhaps Zerodha team can use their existing user/API telemetry data to estimate how much the volume of such cases may be - it might be too much to handle manually through support tickets. As users we want to avoid lag in support resolutions.
From a trading perspective it doesn't really make sense to use another broker's data to place orders on Zerodha but I acknowledge that people will try to do that.
If my IP address has been registered by someone else, and as suggested by @Matti sir, I need to raise a support ticket. In this procedure, there should also be some validation mechanism that can validate my IP ownership claim. Otherwise, how can the support team validate my claim and assign the IP to my API key (and remove the IP from the other API/account)? I may be making a claim without actually having that IP address, just to interrupt someone else's trading for my own benefit.
So as per my understanding, whatever validation the broker is going to implement at the ticket level should also be available at the first level, which will reduce the turnaround time for such cases.
Why does Zerodha need to validate the IP? If someone else maliciously registers an IP that you are using, you too should be able to register that IP. If you are the person, who actually holds the IP, you will be the one using it. Zerodha does not need to validate ownership at all!
In short: You register abc.def.ghi.jkl and you will send orders from abc.def.ghi.jkl. Zerodha API accepts your orders. Malicious person also registers abc.def.ghi.jkl. How will they send orders from the IP that has been assigned to you??
This is clearly a case of other brokers over complicating the system.
Don't think we need to have a registration flow. It can be just a whitelisting flow. At time of app update/create it can have a list of whitelisted ips, and with each order creation zerodha just need to check if the request are coming from those ips. malicious actor simply wont have access to the ips while order creation.
Regulation mentioned same IP cannot be used by multiple people except family members so if someone register your IP you cannot use it hence this discussion of ownership.
What you said is correct - some brokers are overcomplicating it. However, brokers also need to ensure that one IP address cannot be used by multiple people/API keys, so they need to maintain an active mapping where each IP is associated with only one API key/user ID.
If they only check that the request is coming from the given IP address and process it further, then the same IP could be shared among multiple IDs through VPS or multiple ways.
When will this be effective. I can not see the option for static IP in developer console. Please could you explain step by step , how to set up the static ips ?
@StaticIP Not sure if at broker level this can be enforced, i can easily use some other broker with the same static ip address and do the parallel transactions from both the brokers. I think we need to keep it simple at the broker level and let SBI have all the data required. They will have enough means to sort it at their end.
@viveksharma Yes, we also want to make it very simple, which is why I pointed out the future hurdle for special cases that need to be taken care of at an early stage.
Anyway, the broker has a larger user base and tech team, so I am sure that whatever they provide will be useful for us.
I don't understand why is SEBI insisting on static IP? It just creates fingerprinting in case dispute arise, no other advantage as such. Am I missing something here?
a) Will I able to able to have multiple apps in the same kite developer account each one mapped to a different zerodha account.
b) Will the static IP mapping happen at developer account level or the app level
c) If I have two machines- first one with primary static IP and second one with secondary static IP, both mapped to the same API. Will I be able to establish web socket connection simultaneously connect both the machine.
1.JIO FIBER does not give static IP for personal use, its available for buisness users/on request "JioFiber does not offer static IPs on their standard consumer broadband plans. Static IPs are typically available with their Internet Leased Line (ILL) services, which are designed for businesses."
2. I use third party application to place order like algo baba Stoxoo,, but orders less than 10/sec,, what is required to continue in same way?
2. Is 10 OPS per client or per app?
3. Will strategy registration be free with code black box to broker/exchange/SEBI?
1. Will IPV6 address be accepted for static IPs requirement ? If no, please make a representation for it . Why waste IPV4s which are already scarce ?
2. Will all other api endpoints other than orders , be accessible from any arbitrary IP ?
2. You'll still need a static IP. 1. It'll be one order.
2. It is per client.
3. No, exchange charges will be passed on to the customer. Exact pricing isn't indicated in the circular. Yes, and yes. There isn't such a requirement. We'll do a uniqueness check to ensure users can't share IPs between each other, but nothing more than that. Market orders won't be allowed for the commodity segment. The other segments will allow market orders with market protection.
https://kite.trade/docs/connect/v3/orders/#glossary-of-constants
Does that mean if we place order_type=MARKET using the API it will automatically be converted to market orders with market protection? If not, will the API be updated to include this order type?
how about sharing single static ip within 2 family members?
What if I only want to use the kite API for websocket data purposes and not for order placement. I have my own charting and analysis platform and want to continue using it. I can place orders manually on kite web but I need the API for realtime data
Suppose I manage a friend's trading algorithm. Both of us have separate APIs and each API has its own unique static IP address.
Now, to log in to his API, can I generate the `request_token` for his account from my own laptop, where my personal trading account is already logged in?
Would doing this cause any compliance or technical issues for me in the future?
Here's what I understand so far:
1. SEBI/NSE/BSE might want to capture the IP addresses for critical actions such as PLACE_ORDER, MODIFY-ORDER, and CANCEL_ORDER.
2. They might also track IP addresses for other actions like LOGIN, GET-ORDERBOOK, GET-POSITIONS, etc.
3. I have access to my friend's account — can I log in to his account on my machine just to generate the `request_token`?
Please clarify whether this kind of cross-account login from the same IP or system might raise any regulatory red flags or API-level issues.
Pls respond to below clarification, alreday raised by sbalaji
There isn't any separate order type for market orders with market protection in the API docs.
https://kite.trade/docs/connect/v3/orders/#glossary-of-constants
Does that mean if we place order_type=MARKET using the API it will automatically be converted to market orders with market protection? If not, will the API be updated to include this order type?
Suggestion: IP Ownership Validation at the Time of Registration
I wanted to bring up a potential issue regarding how IP addresses (IPv4/IPv6) are registered in the Kite API app. Right now, with other brokers there doesn’t seem to be any validation step to confirm that the person registering an IP actually owns or controls it. This can create a few edge cases where legitimate users are blocked from using their own IPs.
A couple of scenarios to consider:
1. Cloud/VPN/Proxy Static/Elastic IPv4/IPv6 reuse
Say someone rents an IP from a cloud provider (AWS, GCP, etc.), registers it in their Kite app, but later stops trading and shuts down the server, without removing the IPv4/IPv6 address from the app. That IP eventually gets reassigned by the provider to someone else, but when the new user tries to register it, they’re blocked because it’s already tied to another account. So now, even though they fully control the IP, they can’t use it.
2. Malicious or premature registration
In another case, someone with bad intentions could register someone else’s IP before the actual owner does. They might’ve guessed it or obtained it in some way. When the real owner tries to register the IP, they’re told it’s already taken, even though it’s rightfully theirs.
Possible Solution
The simplest fix might be to validate that the user actually controls the IP at the time they register it. A few ways to do this:
Source IP validation: When someone enters an IP in the app, require them to send an API request from that same IP. You can compare the IP from the request headers (`X-Forwarded-For`, `CF-Connecting-IP`, `X-Real-IP`, etc.) with the IP being registered. If it matches, allow it.
Optional verification token: As an added step, you could return a short-lived token and ask the user to hit an endpoint from the IP they want to register, using that token. If they can do that, it's a good sign they control it.
Handling inactive IPs: If an IP has been registered but hasn’t made any API requests in, say, 15–45 days, maybe flag it as stale and allow another user to try claiming it again, assuming they can prove ownership via the method above.
Grace period for current owners: If a new user tries to register an already-registered IP, notify the current owner and give them a few days to revalidate. If they don’t, release it to the new user who can prove control.
This will help us:
Prevents IPs from getting “stuck” in abandoned accounts.
Avoids blocking users who receive reassigned IPs from cloud providers.
Stops bad actors from registering IPs they don’t actually control.
Keeps the IP whitelist accurate and relevant.
We're concerned about this issue, so please let us know how Zerodha plans to handle it.
Handling inactive IPs is fine theoretically, but conversely it just adds overhead if I have to compulsorily shoot an order from my IP (that I paid for) every few days or authenticate at some regular interval.
Remember that a Zerodha API key still needs to be subscribed to for 500rs per month. If someone doesn't pay, I expect their api_key is deleted and the static IP will automatically be freed up for linking with others. @Zerodha team can confirm if this understanding is right.
If someone is paying for the API, Zerodha can't arbitrarily assume after 15-45 days that the static IP is free to be repurposed if there are no orders going through it. The original person who registered may just be in the research phase.
@drjunemoone IMO you should direct this question to any broker which offers free API services (just remember that if you're not paying for the product, you may be the product). If you get a response from those other brokers, please post it here.
That's just my $0.02. Interested in Zerodha team's perspectives @Matti @siva
I’m not particularly concerned with how you’ve interpreted my earlier comment. What does matter to me is how the Zerodha team @Matti @siva plans to address what seems like a real and looming/overlooked issue.
In almost every case where I add any sort of contact or identification detail to my account, whether it’s an email address, phone number, or a document. I’m required to validate ownership. That might involve a one-time code, a verification link, or even uploading documents as proof. This is standard practice to ensure that I’m the rightful owner of the information I’m associating with my account.
So it feels inconsistent, and honestly very risky to allow something like an IPv4/IPv6 address to be added without any form of ownership validation. It effectively leaves the system open to spoofing, where anyone can register any IP address, even if they don’t own or control it. That’s a serious vulnerability.
It would not be just a technical oversight, it would cause real-world problems for users. At best, it’s chaotic, at worst, it’s exploitable.
I hope the zerodha team takes this seriously and considers adding a proper verification step for IP addresses, just as is done with other sensitive account information.
If this does become a problem for a lot of users, we'll automatically remove unused IPs after x period of inactivity.
In your scenario 2 - the malicious actor would be paying 500rs per month just to temporarily stop someone from trading, and they wouldn't even know if whoever they want to stop from trading just changed their IP and resumed trading. The malicious actor may keep paying indefinitely. I think this is a highly unrealistic scenario.
@Matti thanks for the response. Case by case review based on support tickets does make sense since this is likely to be a very rare issue for a paid API. This is just for users who stopped paying for the data/orders API, right? Or for any unused IP regardless of payment status?
I think it should be the former. That should resolve @drjunemoone 's scenario 1: Cloud/VPN/Proxy Static/Elastic IPv4/IPv6 reuse.
Doing this would address the core issue upfront. If someone tries to register an IP that’s already associated with another client, instead of outright rejecting it (as some brokers are doing right now), you could prompt them to validate ownership. If they can demonstrate control over that IP address, just as we do with email or mobile verification, or by utilizing the connect IP information, the registration process can be automated as well. In such cases, the registration should proceed., and the previously registered (but now invalid) association can be removed, since the former user no longer owns or controls that IP.
Also, @sbalaji987 , Zerodha’s trading API is FREE for users who only place orders (where actual IP validation will occur), the ₹500 fee doesn’t apply in those cases. I’ve personally seen people using market data from other brokers while executing trades through Zerodha. So, tying this issue to whether the API is paid or free isn’t really relevant, this is a technical and real concern that applies across the board.
@Matti @siva ,I eagerly await for your response in light of the information provided. Thank You.
I still think it's an edge case (especially the malicious scenario), but now I agree some minimal verification might need to be implemented. Perhaps Zerodha team can use their existing user/API telemetry data to estimate how much the volume of such cases may be - it might be too much to handle manually through support tickets. As users we want to avoid lag in support resolutions.
From a trading perspective it doesn't really make sense to use another broker's data to place orders on Zerodha but I acknowledge that people will try to do that.
If my IP address has been registered by someone else, and as suggested by @Matti sir, I need to raise a support ticket. In this procedure, there should also be some validation mechanism that can validate my IP ownership claim.
Otherwise, how can the support team validate my claim and assign the IP to my API key (and remove the IP from the other API/account)? I may be making a claim without actually having that IP address, just to interrupt someone else's trading for my own benefit.
So as per my understanding, whatever validation the broker is going to implement at the ticket level should also be available at the first level, which will reduce the turnaround time for such cases.
In short:
You register abc.def.ghi.jkl and you will send orders from abc.def.ghi.jkl. Zerodha API accepts your orders.
Malicious person also registers abc.def.ghi.jkl. How will they send orders from the IP that has been assigned to you??
This is clearly a case of other brokers over complicating the system.
What you said is correct - some brokers are overcomplicating it. However, brokers also need to ensure that one IP address cannot be used by multiple people/API keys, so they need to maintain an active mapping where each IP is associated with only one API key/user ID.
If they only check that the request is coming from the given IP address and process it further, then the same IP could be shared among multiple IDs through VPS or multiple ways.
@Matti correct me if i am wrong
Anyway, the broker has a larger user base and tech team, so I am sure that whatever they provide will be useful for us.