A trader opens the Kite Connect docs. They read through order placement, positions, and the WebSocket tick feed. They walk away thinking the hard part is done. It isn't. A broker API gives you the plumbing to send and receive orders. It does not tell you when to sell a strangle, how big to size it, or when to cut a loss before it eats the week's profit. That gap between "I have API access" and "I have a trading system" is where most self-built automation on Zerodha, Fyers, Angel One or Upstox quietly loses money. It's rarely the API's fault.
EliteAlgo runs a NIFTY and SENSEX expiry-day option-selling desk out of Delhi, trading proprietary capital since 2006 with our own backtest engine built in-house. We are not SEBI-registered advisors and we don't sell signals — this is analytical research on what a broker API is actually for, not investment advice. Paper trade any self-built API automation first, before a single rupee of live capital touches it.
What a Broker API Actually Gives You
Every major Indian broker API — Zerodha's Kite Connect, Fyers API, Angel One SmartAPI, Upstox API, Groww API — covers roughly the same four jobs. They let a script place and modify orders programmatically. They let it read live positions and holdings. They run margin checks before an order goes out. And they stream tick-by-tick or quote-level market data over a WebSocket connection. That's the execution layer, full stop. It is a genuinely useful layer; a strategy that can route an order in under a second has a real edge over one dialled in by hand at 9:20 am. But it is also the entire scope of what the API promises.
According to Kite Connect's own v3 documentation, the API surface is order management, portfolio and holdings, margins, and market quotes/historical candles. Nothing in that list is a trading rule. Fyers' API v3 docs describe the same shape: REST endpoints for orders and positions, a WebSocket for live ticks, and historical OHLC pulls. Both are solid, well-documented pieces of plumbing, named here because they're the tools in question, not as an endorsement of either. Neither one ships with an edge.
Per the February 2025 SEBI circular on safer retail participation in algorithmic trading, brokers must now issue API access through a unique, vendor-specific client API key with a static IP whitelisted on the broker's side. Any retail-built algo crossing the exchange's order-per-second threshold has to be registered through the broker before it can run live. That's a meaningful change. It tightens who can push orders through an API and how. But it still regulates access to the execution layer. It does not, and was never meant to, certify that the strategy behind the orders is sound. This is a regulatory fact about broker access, not a claim about EliteAlgo's own registration status — EliteAlgo trades proprietary capital only and holds no SEBI registration or empanelment, nor does it need one for that activity.
Data from IOSCO's 2015 report on mechanisms for trading venues to manage electronic trading risk found that the operational risk in algorithmic and electronic trading sits overwhelmingly in the systems around order routing — monitoring, kill switches, and pre-trade risk checks — not in the order-routing API itself. That finding, from a securities-regulator body looking at markets globally, lines up with what we see at the retail level in India. The API is rarely the weak link.
What It Doesn't Give You — and Why That Matters More
Here is the part the documentation pages never say out loud: a broker API will execute a bad rule exactly as fast, exactly as reliably, and exactly as cleanly as a good one. Speed of execution and quality of the underlying logic are two completely unrelated variables. Conflating them is the single most expensive mistake we see traders make when they move from manual trading to their first API script.
None of the four broker APIs above give you a backtest engine. None give you a signal. None give you position-sizing logic that scales a quantity down after three straight losing days. None give you risk controls that stop the script when the day goes wrong faster than a human would catch it. We tracked this gap directly: when we built our own expiry-day option-selling engine, roughly 70% of the actual build time went into the backtest and risk layer, and only about 30% into the API integration that talks to the broker. Traders who skip straight to "connect the API and go live" are building on the 30% and skipping the 70% that actually determines whether the system survives a bad week.
We found that the failure mode is almost always the same shape. A trader back-tests a rule informally in a spreadsheet. They wire it to Kite Connect or Fyers over a weekend. They go live on Monday with real capital, on the same rule that was never stress-tested against a gap-down open, a sudden IV spike, or a broker API timeout mid-order. The API didn't fail. The missing layer around it did.
Comparing the Major Indian Broker APIs for Option Sellers
For an option seller specifically — someone running multi-leg strangles, iron condors or spreads on NIFTY/SENSEX expiry — the APIs are not interchangeable. The things that matter are WebSocket feed reliability under load, whether the API accepts a true multi-leg basket order or forces you to fire legs one at a time, per-second order rate limits, and how deep the options-chain documentation actually goes.
| Broker API | WebSocket feed | Multi-leg order support | Options-chain docs | Typical rate limit |
|---|---|---|---|---|
| Zerodha Kite Connect | Reliable under normal load; single-symbol subscription model | No native basket order — legs placed individually | Good instrument-master docs; options-chain building is left to the developer | ~3 orders/second (standard plan) |
| Fyers API v3 | Stable; supports symbol-group subscriptions | Supports basket/multi-order payloads in v3 | Clear options-master and Greeks-adjacent fields documented | ~10 orders/second |
| Angel One SmartAPI | Historically more prone to disconnects during high-volatility opens | Individual leg placement; no native basket endpoint | Thinner options-chain documentation than Kite or Fyers | ~1 order/second on some endpoints |
| Upstox API | Improved WebSocket stability after the v2 rewrite | Individual leg placement | Adequate but sparse on multi-leg examples | Varies by plan |
We measured something traders rarely check before committing to a broker's API: what happens to the WebSocket feed in the first 90 seconds after 9:15 am, when volatility and message volume both spike. In our own testing across three expiry sessions, Fyers and Kite held their tick feed without a visible gap. One of the other APIs dropped and silently reconnected. That's invisible to a dashboard but fatal to a strategy that trails a stop-loss off live premium. That single difference — not the brand name on the login page — is what should decide which API a serious option-selling script is built on.
None of this is a strategy comparison. None of it should be read as "Kite is better than Fyers" in any absolute sense — each has traded well for different systems we've tested. It's a plumbing comparison, and plumbing quality is exactly the layer a trader needs to get right before writing a single line of strategy logic on top of it.
Margin Checks and the Expiry-Day Timing Nobody Scripts For
A margin check sounds simple on paper. Send the order, the broker checks SPAN plus exposure margin, and the order either clears or gets rejected. In practice, expiry-day margin requirements for index options can shift intraday as implied volatility moves. A script that calculated the margin it needed at 9:16 am may not have enough free margin for the exact same trade at 2:30 pm, even with zero new positions opened in between, because the exchange's own margin model recalculated against the day's IV move.
None of the four broker APIs flag this proactively. Kite Connect, Fyers, Angel One and Upstox all expose a margin-check endpoint, but it's a pull, not a push — the script has to ask before every order, not just once at the start of the day. We've seen traders skip this check to save a network round-trip and shave a few milliseconds off execution. On a normal day that costs nothing. On a day the index gaps 150 points at the open, it's the difference between a clean fill and a rejected order sitting unfilled while the market runs away from the intended strike.
There's also a scheduling detail that trips up almost every first-time API script: broker API rate limits and exchange-side order acceptance windows both tighten in the first and last few minutes of the session. A script built and tested mid-session, when the API is calm and fills are instant, will behave differently at 9:15-9:20 am or in the closing minutes, when order volume across the exchange spikes and the same API that felt instant in testing queues for a second or two longer. A system that trades expiry-day option selling has to be tested specifically in those windows, not just in the calm middle of the day, or the backtest numbers won't match what actually happens live.
Rate Limits and Order Routing: the Detail Option Sellers Skip
A four-leg iron condor is four separate order calls on three of the four APIs above. At roughly 3 orders/second on a standard Kite Connect plan, placing all four legs cleanly takes over a second even before the exchange acknowledges anything. On an expiry morning, when NIFTY and SENSEX premiums can move several rupees in that same second, a slow multi-leg fill is a real cost, not a theoretical one. We measured this on our own desk: legging into a condor sequentially instead of as a single basket cost us an average of ₹8-₹15 per lot in slippage across 40 tracked fills, purely from the gap between leg one and leg four.
Rate limits also bite during error handling, which almost nobody tests before going live. If an order gets rejected for insufficient margin and the script retries immediately, a tight per-second cap can throttle the retry and leave a position half-built — one leg filled, three pending — for several seconds longer than intended. That's exactly the kind of failure a backtest never surfaces, because a backtest doesn't model broker-side rejections at all unless someone deliberately built that into the simulation.
The Build-vs-Buy Problem Nobody Mentions in the Docs
Scripting against a raw broker API — whether it's the Kite API, the Kite Connect API, Fyers API, Angel One API, Upstox API or Groww API — means you are not buying a trading system. You are buying the execution pipe, and signing up to build everything else: a backtest engine that can simulate your rule across years of historical option-chain data, a risk layer that caps daily loss and position size, a monitoring layer that tells you when the script has silently stopped working, and ongoing maintenance every time the broker ships an API version bump.
We surveyed our own build timeline honestly. The execution layer took about three weeks. The backtest engine, the risk controls, and the monitoring took closer to eight months of iteration before we trusted it with real capital — and we do this full-time. That asymmetry is exactly the gap a dedicated platform like EliteAlgo's backtested option-selling platform for Indian traders exists to close. The broker API still does the execution, but the backtest, the risk sizing, and the historical validation are already built, tested across market regimes, and maintained.
That's not a knock on any broker's API. Kite Connect, Fyers and the rest are genuinely well-built for what they promise. It's an honest statement about scope: an API gives you a pipe to the exchange; a platform gives you a tested system that uses that pipe responsibly.
A Sober Caution: Automation Makes Bad Ideas Fail Faster, Not Safer
This is worth saying plainly because API marketing rarely does: giving a bad rule a faster execution path does not make it a good rule. It makes the bad rule lose money with more consistency and less supervision than a human trading it by hand ever could. We've seen this play out across dozens of self-built scripts over three years of reviewing them for traders who came to us after a rough stretch. The API performed flawlessly. The strategy behind it had never been tested against a real volatility spike before it went live with real money.
Paper trade any self-built API automation first — for a minimum of 20-30 trading sessions — before it touches live capital, regardless of how simple the rule looks on paper. An API script that places orders in 200 milliseconds is not safer than a manual trade placed in 20 seconds, if the underlying rule hasn't survived contact with a gap-up open, a sudden options-chain IV crush, or a broker rate-limit error mid-execution. Speed is not risk management. This is analytical software and research territory, not investment advice. Nothing here is a recommendation to deploy any specific rule with your own capital.
Where a Solo API Script Genuinely Makes Sense
None of this means a trader should never script against a broker API directly. In our experience, a solo-built API script is a reasonable choice when the rule is genuinely simple — a single entry condition, one exit rule, modest position size — and the trader has the time to build and maintain the backtest and monitoring themselves rather than treating that layer as optional. On site, we've watched this work well for traders running one straightforward intraday rule on a single instrument, with capital small enough that a bad week doesn't threaten the account. It stops making sense the moment the rule grows multi-leg, multi-instrument, or needs historical validation across more than a year of data. At that point, the build cost of doing it properly from scratch usually exceeds the cost of a platform that has already done it.
Frequently Asked Questions
What can you actually do with the Kite API?
The Kite API (Kite Connect) lets a script place, modify and cancel orders, read live positions and holdings, run margin checks, and stream live market quotes and historical candle data. It does not include a backtest engine, a trading signal, or risk management. Those have to be built separately.
Is a broker API enough to automate trading on its own?
No. A broker API is the execution layer only. Automating a trading strategy safely also needs a backtested rule, position-sizing logic, and risk controls, none of which the API provides. Without those three, the API will execute whatever rule it's given, good or bad, at full speed.
Zerodha Kite API vs Fyers API vs Angel One SmartAPI — which is best for options?
For multi-leg options work specifically, Fyers API v3 supports native basket/multi-order payloads and has clearer options-chain documentation, which matters for strangles and condors. Kite Connect's feed and order management are solid but require placing legs individually. Angel One SmartAPI has historically had thinner options-chain documentation and a higher rate of feed disconnects during volatile opens in our own testing. None is unsuitable; the right choice depends on order-rate needs and whether native multi-leg placement matters to the specific strategy.
Do broker APIs backtest strategies?
No broker API — Kite Connect, Fyers API, Angel One SmartAPI, Upstox API or Groww API — includes a backtest engine. Historical candle endpoints exist, and can be used to build a backtest, but the backtest logic, the options-chain handling, and the statistical validation are the trader's (or a platform's) responsibility to build.
Is building your own trading bot on a broker API worth it?
It's worth it for a simple, single-rule, modest-capital strategy where the trader has the time to also build and maintain a proper backtest and risk layer — that part typically takes far longer than the API integration itself. For multi-leg option-selling systems that need validation across multiple market regimes, the build cost usually exceeds what a dedicated, already-tested platform charges. Either way, paper trade first before any live-capital decision.
What's the realistic build time for a broker-API trading system, not just the API integration?
Wiring up order placement, positions and the live feed took about three weeks on our own build. Building and validating the backtest engine and risk controls to a standard trusted with real capital took roughly eight months of iteration. The API integration is the fast, visible part. The backtest and risk layer is the slow, invisible part that actually determines whether the system holds up.
Does SEBI's 2025 algo trading circular change how retail traders use broker APIs?
Yes. Brokers now issue API access via a unique vendor-specific client key with a static whitelisted IP, and retail algos crossing the exchange's order-per-second threshold must be registered through the broker before going live. That changes who can push orders through an API and under what registration, but it doesn't certify or backtest the strategy running behind the orders. That responsibility still sits with the trader or platform building it.
What does a Groww API or Upstox API add that Kite or Fyers don't?
Functionally, not much for an option seller. All five APIs cover the same four jobs: order placement, positions, margin checks, and market data. The differences that matter are WebSocket feed reliability under load, native multi-leg support, and rate limits, not brand name. Upstox's v2 rewrite improved feed stability. Groww's API documentation for options-chain data is comparatively newer and thinner than Kite's or Fyers', which matters if a script needs to pull option Greeks or chain depth directly rather than computing them itself.
How long should a trader paper trade an API-automated option-selling rule before going live?
We treat 20-30 full trading sessions as a floor, not a target. That's roughly one calendar month, which is usually enough to see at least one gap-up or gap-down open and one high-IV expiry. A rule that holds up across a single calm month hasn't actually been tested against the conditions that cause real damage. Paper trading through at least one volatile week, not just thirty quiet ones, is what separates a genuine test from a formality.
A broker API is a well-built door to the exchange. What you build on the other side of that door — the backtest, the sizing, the risk controls — is what decides whether the system makes money over a hundred trading days or loses it over ten. Read more on what actually separates a tested option-selling system from a script in our breakdown of the best options backtesting software for Indian traders, and if you're weighing whether to automate at all, our honest look at the disadvantages of algo trading covers the failure modes we've measured directly, not the ones vendors list as footnotes.
