Written by Rajeev Gupta, founder of EliteAlgo. Our desk has been building and running systematic NIFTY and SENSEX option-selling strategies since 2006, across manual execution, third-party platforms and our own engine.
Paper trade before any of this touches live capital. This page is a factual reference on what four broker APIs publicly document. It is not a broker comparison, it ranks nothing, it recommends no broker, and it contains no charges or pricing of any kind. It recommends no strategy, no strike and no structure, reports no expected return, and is analysis rather than advice. Every figure below was read from the broker's own developer documentation on 20 October 2026, and all of it is subject to change without notice — check the live documentation before you build on any of it.
Quick Answer
All four of these brokers publish a documented trading API, and at the level that matters to someone automating index option selling they are more alike than different: each gives you order placement, positions and holdings, a market quote endpoint, historical candles and a websocket feed for live data. The differences that will actually affect your build are narrower and more boring than most people expect — how long your access token lives and what you must do each day to get a new one, the documented request limits per endpoint category, which exchange segments the API accepts for order placement, and whether the API exposes derivative-specific data like an option chain or expired-contract history. Those four things determine the shape of your code. Everything else is a question for the broker, not for us.
We are not ranking these APIs and we will not tell you which broker to use. That choice depends on where your account and capital already sit, what segments you are activated for, and what your own strategy needs — and it involves charges, which we do not publish for other brokers. What this page does is set out what each API publicly documents, so that you can read your own requirements against it. Brokers below are in alphabetical order, deliberately, so that the sequence carries no judgement.
Before any of this: whether you should be on the self-coded route at all is a prior question, answered in our guide to algo trading in India, which also covers the legal position and the regulatory framework that governs API-based orders. This page assumes you have read that and chosen this route.
What to look for in a broker API before you compare anything
Work out your own requirements first. If you walk into broker documentation without a list, you will be impressed by feature names and miss the two or three things that will actually cost you a rewrite.
1. The authentication model, and specifically the daily part
Nearly every Indian broker API issues a short-lived access token rather than a permanent key. That single design fact shapes your whole deployment, because something has to obtain a fresh token before the market opens, every single trading day, without you being awake. So the questions are: how long does a token live, what exactly has to happen to get a new one, and can that step be automated within the broker's own documented rules? The answers differ meaningfully between the four, and this is the item most likely to surprise you after you have written everything else.
2. Documented rate limits, per endpoint category
Limits are not one number. Every one of these APIs documents different ceilings for order placement, for quotes, for historical data and for everything else — and quote endpoints are routinely the tightest. That matters because the naive design polls for prices in a loop, which is exactly the pattern a 1-request-per-second quote limit is there to stop. Read the limits before you design your data flow, not after, and prefer a subscription over polling wherever the API offers one.
3. Which exchange segments the order API accepts
Check the documented list of accepted exchange values against the index you actually trade. NSE F&O and BSE F&O are different segments, so if you trade SENSEX options you must confirm the constant exists in that API's documentation and that your account is activated for it. Do not assume it from the fact that the broker's app shows you the contract — the app and the API are different surfaces, and the documented constant list is the authority.
4. Derivative-specific data endpoints
Generic APIs give you quotes and candles. Option-selling work often needs more: an option chain in one call rather than assembled instrument by instrument, full market depth rather than just the top of the book, and history on contracts that have already expired. Those three are not universal, and whether an API has them changes how much you have to build yourself.
5. Order varieties and product types
Whether the API exposes the order types your rules need — stop-loss variants in particular — and which product type you must use for F&O. Also worth checking: whether the API documents a cap on how many times a single order can be modified, because a trailing-stop design that modifies an order every few seconds can run into a per-order ceiling that has nothing to do with your request rate.
6. An order-update stream
Does the API push order status changes to you, or must you ask? A push stream is substantially better for a multi-leg system, because it tells you about a partial fill when it happens rather than when you next get round to looking. If there is no push, your polling has to live inside the rate limit from point two, and your partial-fill handling gets slower.
Those six are the list. Notice that none of them is "which broker is best" — they are all "does this API do the thing my code needs", which is a question only you can answer because only you know your rules.
What each API publicly documents
Alphabetical order. Everything in this section was read from the broker's own developer documentation on 20 October 2026. Where the documentation did not state something, this page says so rather than filling the gap — and in several places it did not state something we would have liked to report. Treat every number here as a snapshot: all of these terms are revised from time to time, and the broker's live documentation is the only authority.
Dhan — DhanHQ v2
The documented name is DhanHQ, currently at version 2.
What it documents. On the trading side: Orders, Super Order, Forever Order, Conditional Trigger, Portfolio and Positions, EDIS, Trader's Control, Funds and Margin, Statement, Postback, and Live Order Update. On the data side: Market Quote, Live Market Feed, Full Market Depth, Historical Data, Expired Options Data, and Option Chain.
Authentication. Every request carries a client ID and an access token in the header. The documentation describes three ways to get that token: an individual trader can generate it directly from the Dhan web platform; it can be generated programmatically if TOTP is enabled on the account; or a partner platform can use a documented three-step consent flow. The documented access-token validity is 24 hours, and there is a documented refresh call which expires the current token and returns a new one with another 24 hours. Separately, the documentation states that an API key and secret pair is valid for 12 months from generation.
Documented rate limits. Order APIs: 10 per second, 250 per minute, 1,000 per hour, 7,000 per day. Data APIs: 5 per second, with a documented ceiling of 100,000 per day. Quote APIs: 1 per second. Non-trading APIs: 20 per second. The documentation also states that order modifications are capped at 25 modifications per order.
Practical implication for option selling. Three things stand out as facts rather than judgements. The documented Option Chain and Expired Options Data endpoints are directly relevant to derivative work — getting a chain in one call and reaching expired-contract history through the same API removes build work that you would otherwise do yourself. The documented Live Order Update is a push stream, which is what you want for multi-leg fill handling. And the 25-modifications-per-order cap is a real design constraint for anyone planning to trail a stop by repeatedly amending the same order; if your design does that, count your amendments against that number before you write it. The 24-hour token with a documented refresh path means your daily-token problem has a documented answer, which is not true everywhere.
Check the current DhanHQ documentation before relying on any of the above — the endpoint set, the limits and the token rules are all subject to revision.
Groww — Groww Trading API
The documented name is the Groww Trading API. There is a documented Python SDK installable with pip install growwapi, alongside plain REST documentation.
What it documents. Endpoint groups for Instruments, Orders, Smart Orders (documented as including GTT and OCO), Portfolio, Margin, Live Data, Historical Data, Backtesting, User and Annexures. The Live Data group documents quotes, last traded price and option chain, and there is a documented feed for live subscription covering equity and derivatives with callback functions.
Authentication. Three documented approaches. A plain access token, which the documentation states expires daily at 6:00 AM. An API key and secret flow, documented as requiring daily approval and using a SHA256 checksum. And a TOTP flow, also documented as requiring daily approval. There is a documented limit of 150 requests per 24 hours on the token endpoint itself.
Documented rate limits, per second and per minute: Authentication 5 and 30; Orders 10 and 250; Live Data 10 and 300; Non-Trading 20 and 500.
Segments. The documentation states the platform supports equity (CASH) and derivatives (FNO) trading only, and explicitly states that commodities trading is not available. If you only trade index options, FNO is the segment you need and it is documented.
Activation. The documentation states that an active Trading API subscription is required, enabled from the profile settings on the Groww platform. We are not publishing what that costs and we are not comparing it to anything — take the current terms from Groww. One honest caveat, stated because leaving it out would be misleading: a subscription requirement was documented in the Groww pages we read and we did not separately verify the equivalent position for the other three brokers on this page. That is a gap in what we checked, not a difference we are asserting. Check each broker's own terms.
Practical implication for option selling. The documented 6:00 AM daily token expiry, together with the documented daily-approval step on both the key-and-secret and TOTP flows, is the detail to design around — it means your morning token step has to be in place and working well before the open, every day. The documented option chain and derivatives feed are useful for option work. The documented Backtesting endpoint group is unusual among these four and worth looking at if it matches your needs, though what a backtest from any API is worth depends entirely on method, which we cover in how to backtest an option selling strategy.
Check the current Groww Trading API documentation before relying on any of the above.
Upstox — Developer API
The documented name is the Upstox Developer API.
What it documents. The developer documentation describes APIs to execute real-time orders, manage user portfolios and stream live market data over websockets.
Authentication. A documented OAuth 2.0 authorization code flow: your app sends the customer to Upstox, the customer logs in, Upstox returns a single-use authorization code, and your server exchanges that code for an access token. You need an API key (documented as client_id) and an API secret (client_secret), obtained by creating an app on the Upstox developer apps portal. The documentation notes that the authorization code is valid for a single use regardless of whether the token exchange succeeds. We did not find a documented access-token validity duration on the authentication pages we read, so we are not stating one — check it directly, because as point one above explains, it decides how your daily token step works.
Documented rate limits, stated as enforced per API and per user. This is the one documented distinction on this page that connects straight to the regulatory layer, so it is worth quoting carefully. For order-placement APIs the documentation gives two tiers: "Regular Algos" at 10 requests per second, 500 per minute and 2,000 per 30 minutes; and "SEBI-Registered Algos" at 50 requests per second, 500 per minute and 2,000 per 30 minutes. Standard APIs are documented at 50 per second, 500 per minute and 2,000 per 30 minutes. TOTP login is documented at 1 per second, 10 per minute and 60 per 30 minutes.
Practical implication for option selling. The two-tier order-placement limit is the thing to understand here, and it is a factual observation rather than a complaint about anyone: the documented per-second ceiling for a retail algo differs from the one for a registered algo. For a candle-driven option-selling strategy that sends a handful of orders a session, neither tier is anywhere near binding, so this is unlikely to constrain you — but it is a concrete illustration that the regulatory classification of your algo is now visible in the API layer itself, not just in the paperwork. What that classification is and how the retail algo framework works is covered in the main guide, and Upstox publishes its own notice on regulatory changes for API and algo trading in its developer documentation, which is worth reading at the source because this area is moving.
Check the current Upstox developer documentation before relying on any of the above.
Zerodha — Kite Connect 3
The documented name is Kite Connect, currently version 3. We cover this API in depth separately, so this section is the capability summary only — the full treatment, including what Kite Connect is and is not and what the setup process actually involves, is in automating an option-selling strategy with the Zerodha Kite API.
What it documents. Order execution in real time, portfolio management, live market data streamed over websockets, historical candle data, GTT orders, alerts, and margin calculation.
Authentication. An api_key and api_secret pair is issued, and a redirect URL must be registered; the user is sent through a login flow and returned to that URL. The documentation is explicit that the api_secret should never be embedded in the app. On session expiry, the documentation describes a TokenException, preceded by a 403 header, as indicating the expiry or invalidation of an authenticated session. We did not find a documented token validity duration on the pages we read, so we are not stating one.
Documented rate limits. Quote: 1 request per second. Historical candle: 3 per second. Order placement: 10 per second. All other endpoints: 10 per second. The documentation additionally states limitations of 400 orders per minute and 10 orders per second, and that a single user or API key cannot place more than 5,000 orders per day.
Documented order constants. Accepted exchange values are documented as NSE, BSE, NFO, CDS, BCD and MCX. Order types are documented as MARKET, LIMIT, SL (stop-loss) and SL-M (stop-loss market). Product types are documented as CNC for equity cash and carry, NRML for normal futures and options, MIS for margin intraday square-off, and MTF. Order varieties are documented as regular, amo, co, iceberg and auction.
Practical implication for option selling. Two useful facts. First, NRML and MIS are both documented for futures and options, and which one your rules require is a margin and holding-period question rather than an API question. Second, the documented exchange constant list is exactly the sort of thing to check against your own index before you build — read the current list in the documentation and confirm the segment you trade is in it, rather than assuming it from what the trading app displays. The 1-request-per-second quote limit is also a direct argument for using the websocket feed rather than polling quotes, which is the design point made in our page on building the system itself.
Check the current Kite Connect documentation before relying on any of the above.
What is genuinely the same across all four
Having gone through them individually, the honest summary is that the common ground is large. All four document order placement, positions and holdings, a quote endpoint, historical candles and a websocket market-data feed. All four use a short-lived token rather than a permanent credential, so all four require a daily token step in your deployment. All four document rate limits that are tighter on quotes than on orders, so all four reward a subscription-based data design over a polling one. And none of them removes any of the work described in building the system — the API gives you a way to send an order and read a price, and everything about reconnects, partial fills, order-state reconciliation, risk limits and state after a restart is still yours to write.
That last point is the one worth sitting with, because it is where expectations usually go wrong. An API is a door, not a system. Choosing a different door does not reduce the amount of building on the other side of it.
What the API will not give you
Four things, none of which is any broker's fault, and all four of which people expect anyway.
- A strategy. Obvious when stated, routinely assumed in practice. The API executes; what to execute is a research question, and the method for answering it is in how to backtest an option selling strategy.
- Protection from your own code. An order that your logic got wrong is still a valid order. The pre-send sanity check — quantity in bounds, instrument in the expected segment and expiry, price within a plausible band — lives in your code, because the API has no way to know what you meant.
- Risk management. No API knows your daily loss limit. Our own logged record across 163 expiry sessions showed a median 42.8% peak-to-close give-back — our measured number, stated as ours, with the full account in is algorithmic trading profitable, our own data. Much of a session's outcome is decided after the entry decision, and nothing in any API layer governs that window. Your risk layer does.
- Permission to skip the regulatory layer. API-based orders sit inside a framework, and the fact that an endpoint accepts your request does not settle your obligations. That is covered in the main guide and in our page on SEBI's algo trading regulations, and the broker's own notices are the place to track changes.
A checklist to run against any broker API
Take this to the documentation of whichever broker you already hold your account with, and answer each from the documentation rather than from a forum post.
- What is the documented access-token validity, and exactly what must happen each day to obtain a new one?
- Can that daily step be automated within the broker's documented rules, and what is the documented limit on the token endpoint itself?
- What are the documented rate limits for order placement, quotes, historical data and everything else — as separate numbers?
- Is there a documented daily order cap, and a documented cap on modifications per order?
- Which exchange constants does the order API accept, and is the segment for the index you trade among them?
- Which order types and product types are documented, and do they include the stop variant your rules need?
- Is there a documented push stream for order updates, or must you poll inside the rate limit?
- Does the API document an option chain call, full market depth, and history on expired contracts?
- What activation does your account need — segment activation, API subscription, TOTP, a registered redirect URL, a static IP?
- Where is the changelog, and how will you find out when any of the above changes?
Item ten is the one people never do, and it is the one that breaks working systems. These terms change. A system built on a number you read once and never checked again is a system with a quiet dependency on that number staying put.
Frequently Asked Questions
Which Indian brokers offer an API for algo trading?
Zerodha, Dhan, Upstox and Groww all publish documented trading APIs, and they are not the only Indian brokers that do. Zerodha's is documented as Kite Connect, currently version 3. Dhan's is documented as DhanHQ, currently version 2. Upstox publishes what its documentation calls the Upstox Developer API. Groww publishes the Groww Trading API, with a documented Python SDK alongside plain REST documentation. We are listing these alphabetically and we are not ranking them or recommending one over another — that choice depends on where your account and capital already sit, which segments you are activated for, and what your own rules need. Note also that offering an API is not the same as your account being able to use it: each broker documents its own activation requirements, and those need checking against your specific account.
What should I check in a broker API before building an algo on it?
Six things, and work out your own requirements before you open anyone's documentation. First, the authentication model and specifically the daily part — nearly all of these issue a short-lived token, so something has to obtain a fresh one before the open every trading day without you being awake. Second, documented rate limits per endpoint category, because they are not one number and quote endpoints are routinely the tightest. Third, which exchange constants the order API accepts, checked against the index you actually trade, since NSE and BSE derivatives are different segments. Fourth, whether derivative-specific endpoints exist — an option chain in one call, full market depth, history on expired contracts. Fifth, which order types and product types are documented, including the stop variant your rules need, and whether there is a cap on modifications per order. Sixth, whether order updates are pushed to you or must be polled.
Does Dhan have an API for algo trading?
Yes. The documented name is DhanHQ, currently version 2. On the trading side its documentation covers Orders, Super Order, Forever Order, Conditional Trigger, Portfolio and Positions, EDIS, Trader's Control, Funds and Margin, Statement, Postback and Live Order Update. On the data side it documents Market Quote, Live Market Feed, Full Market Depth, Historical Data, Expired Options Data and Option Chain. Authentication uses a client ID and access token in the header of every request, with a documented 24-hour token validity and a documented refresh call that expires the current token and issues a new one; the documentation also states that an API key and secret pair is valid for 12 months. Documented rate limits are 10 order requests per second, 5 data requests per second and 1 quote request per second, with order modifications capped at 25 per order. All of this is from Dhan's own documentation as read on 20 October 2026 and is subject to change — check the live docs.
Does Groww have an algo trading API?
Yes. It is documented as the Groww Trading API, with a documented Python SDK installable via pip install growwapi as well as plain REST documentation. The documented endpoint groups are Instruments, Orders, Smart Orders including GTT and OCO, Portfolio, Margin, Live Data, Historical Data, Backtesting, User and Annexures, and there is a documented live feed covering equity and derivatives with callback functions. The documentation states the platform supports equity (CASH) and derivatives (FNO) trading only, with commodities explicitly not available. On authentication it documents an access token that expires daily at 6:00 AM, plus an API key and secret flow and a TOTP flow, both documented as requiring daily approval, with a documented limit of 150 requests per 24 hours on the token endpoint. The documentation also states that an active Trading API subscription is required, enabled from your profile settings on the Groww platform; take the current terms from Groww.
Can I do algo trading with Upstox?
Upstox publishes what its documentation calls the Upstox Developer API, described as providing real-time order execution, portfolio management and live market data streamed over websockets. Authentication is a documented OAuth 2.0 authorization code flow: your app sends the customer to Upstox, the customer logs in, Upstox returns a single-use authorization code, and your server exchanges that for an access token, using an API key and secret obtained by creating an app on the Upstox developer apps portal. We did not find a documented access-token validity duration on the authentication pages we read, so we are not stating one — check it at the source, because token lifetime decides how your daily refresh step has to work. On rate limits, the documentation gives two tiers for order placement: Regular Algos at 10 requests per second and SEBI-Registered Algos at 50 requests per second, both at 500 per minute and 2,000 per 30 minutes.
Is Zerodha's Kite Connect good for automating option selling?
We do not rate or rank broker APIs, so here is what Kite Connect version 3 documents and you can read it against your own requirements. It documents real-time order execution, portfolio management, live market data over websockets, historical candle data, GTT orders, alerts and margin calculation. Authentication issues an api_key and api_secret pair with a registered redirect URL, and the documentation is explicit that the secret should never be embedded in the app. Documented rate limits are 1 quote request per second, 3 historical candle requests per second and 10 requests per second for order placement and all other endpoints, with documented limitations of 400 orders per minute, 10 orders per second and a maximum of 5,000 orders per day per user or API key. Documented product types include NRML and MIS for futures and options, and documented order types include SL and SL-M. We cover this API in much more depth on our dedicated Zerodha Kite API page.
Why do broker APIs expire the access token every day?
It is a security design, and from your side it is the single most consequential thing about the authentication model, because it means a permanent credential is not available to you and something must obtain a fresh token before every market open. Dhan documents a 24-hour token validity with a refresh call that expires the current token and issues a new one. Groww documents an access token that expires daily at 6:00 AM, plus a daily approval step on both its API key and secret flow and its TOTP flow. Zerodha's documentation describes a TokenException preceded by a 403 to indicate an expired or invalidated session, though we did not find a stated duration on the pages we read, and we likewise did not find one in Upstox's authentication documentation. Design the daily token step first, make it observable so you know when it has failed, and confirm what the broker's documentation permits in terms of automating it.
What rate limits do Indian broker APIs have?
They differ per broker and per endpoint category, which is why a single number is never the answer. From each broker's own documentation as read on 20 October 2026: Zerodha documents 1 quote request per second, 3 historical candle requests per second and 10 per second for order placement and all other endpoints, plus 400 orders per minute and 5,000 orders per day per user or API key. Dhan documents 10 order requests per second with 250 per minute, 1,000 per hour and 7,000 per day, 5 data requests per second, 1 quote request per second, and 25 modifications per order. Groww documents 10 orders per second and 250 per minute, 10 live data requests per second and 300 per minute, and 150 requests per 24 hours on its token endpoint. Upstox documents order placement at 10 per second for regular algos and 50 per second for SEBI-registered algos. All of these are revised from time to time — read the live documentation.
Does using a broker API make my algo trading legal?
The fact that an endpoint accepts your request does not settle your regulatory obligations, and the two questions are genuinely separate. API-based algo orders in India sit inside a framework that covers how algos are tagged and approved, thresholds on order rates, and requirements that apply to particular routes. One concrete sign of how closely the two layers now sit together: Upstox's documented order-placement rate limits distinguish Regular Algos from SEBI-Registered Algos, which means the regulatory classification of your algo is visible in the API layer itself rather than only in paperwork. We cover the legal position, who regulates what, and the retail algo framework in our main guide to algo trading in India and in our page on SEBI's algo trading regulations, and your broker's own developer notices are the right place to track changes, because this area is moving.
Will a broker API give me everything I need to run an algo?
No, and this is where expectations most often go wrong. An API is a door, not a system. It gives you a way to send an order and read a price; it does not give you a strategy, which is a research question answered by testing rather than by picking an endpoint. It gives you no protection from your own code, because an order your logic got wrong is still a valid order, so the pre-send sanity check on quantity, segment, expiry and price band has to live in your code. It provides no risk management, since no API knows your daily loss limit or your square-off discipline. And everything else that decides whether a live system survives is still yours to write: reconnect handling that does not evaluate across a data gap, a written partial-fill policy, reconciliation of order state against the broker's order book rather than trust in an HTTP response, and a correct belief about your own positions after a restart. Choosing a different door does not reduce the building on the other side.
The Bottom Line
Zerodha, Dhan, Upstox and Groww all publish documented trading APIs, and for automating index option selling they overlap heavily: order placement, positions and holdings, a quote endpoint, historical candles and a websocket feed, in every case. The differences that will actually shape your code are narrow and specific. Token lifetime and the daily step needed to refresh it — Dhan documents a 24-hour token with a documented refresh call, Groww documents an access token that expires daily at 6:00 AM along with a daily approval step on its key-and-secret and TOTP flows, and neither Zerodha's nor Upstox's pages that we read documented a duration, so check those at the source. Rate limits, which are per endpoint category and are consistently tightest on quotes — 1 request per second on both Zerodha's and Dhan's documented quote endpoints — which is a direct argument for subscribing to a feed rather than polling. Hard ceilings worth designing around, such as Zerodha's documented 5,000 orders per day and Dhan's documented 25 modifications per order. And derivative-specific endpoints, where Dhan documents an option chain, full market depth and expired options data, and Groww documents an option chain and a derivatives feed. We are not ranking these and we publish no charges for other brokers; where your account and capital already sit will reasonably decide this for you. Run the ten-point checklist above against your own broker's current documentation, note item ten in particular, and remember the thing that no API changes: the door is not the building. Everything about reconnects, partial fills, order reconciliation, risk limits and restart state is still yours to write.
This article is for educational and informational purposes only and does not constitute investment advice. EliteAlgo is proprietary trading research and analytical software; it is not a SEBI-registered investment adviser and does not provide investment advice, strike or strategy recommendations, or trading tips. This page is a factual reference on publicly documented API capability. It is not a broker comparison or recommendation, it ranks nothing, it contains no brokerage charges, fees or pricing, it makes no claim about any broker's reliability or service quality, and it implies no partnership, integration or endorsement. No broker, API, platform, strategy, strike, expiry or structure mentioned or implied above is recommended. All broker-specific statements were read from that broker's own public developer documentation on 20 October 2026 and are reproduced as documented facts; API capabilities, endpoints, authentication rules, token validity and rate limits are set by the broker and are revised from time to time, so verify everything against the live documentation before relying on it. Brokerage, statutory charges, securities transaction tax, lot sizes, freeze quantities, margin requirements, expiry calendars and settlement procedures are set by the exchanges, SEBI, the government and your broker and are revised from time to time — take all current figures from the source. Selling options involves substantial risk of loss and is not suitable for all investors. Paper trade before deploying live capital and consult a SEBI-registered investment advisor before trading derivatives.
