Algo Trading With Your Broker's API: Zerodha, Dhan, Upstox and Groww

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 quotes no brokerage or trading charges. The only prices on it are the API-access prices the brokers themselves print. 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 or support pages on 20 October 2026 and re-checked on 9 November 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.

Two things have moved since this page was first written, and both matter more than any endpoint list. First, since 1 April 2026 an order placed through an API has to come from a static IP address you have registered with your broker. Plenty of home setups and default cloud servers stopped working that week. Second, the free ride is mostly over for data: placing orders is free or nearly free on all four, but live prices, the option chain and history cost roughly Rs 500 a month on the three that print a price. Both are covered in their own sections below.

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.

The static IP rule that came in on 1 April 2026

If you built a broker API setup last year and it quietly stopped placing orders in April, start here. Under the retail algo framework, orders sent through a client API must now come from a static IP address that your broker has on file. Zerodha's support page gives 1 April 2026 as the start date and says it applies to placing orders only. Websocket prices and read-only calls such as the order book and positions can still be reached from any IP. Upstox lists the calls it checks: place, modify and cancel order, multi-order, and GTT.

The exchange's own FAQ (NSE, November 2025) adds three points worth knowing. A client static IP is required for a "tech savvy" investor placing orders through an API. Every order that arrives through a client API counts as an algo order and gets tagged as one, even below the threshold of 10 orders per second. And a tech-savvy client who runs the algo on their own static IP, instead of on the broker's server, is not required to join the monthly mock trading sessions. If you want the framework itself, our page on SEBI's algo trading regulations goes through it.

Family sharing is allowed in a limited way. Zerodha lets you cover a spouse, dependent children and dependent parents under one developer account if you accept a declaration that the IPs are used only by you and your immediate family. An Upstox community reply dated 7 May 2026 says family members can now share static IPs too, after an earlier reply had said each account's mapping was unique. Treat the community reply as softer than the announcement and confirm with Upstox support.

The part that catches people is hosting. A home broadband line usually changes its IP now and then, and a cloud server's default public address is often not static either, so you have to reserve one. Once you do, remember you can change the registered IP only about once a week. A typo in that box can cost you a week of trading. Paste carefully, then place one small test order right after saving. I would also register the secondary IP on a second machine you can fail over to, instead of leaving it empty. Upstox reports a blocked order as a 403 with error code UDAPI1154, which at least tells you the IP is the problem and not your code.

Upstox's 1 April notice has three more changes in the same post. Only one active API app per user is allowed. Algos above 10 orders per second need exchange registration, and until that process opens only strategies at or below the threshold are permitted. And market orders are no longer allowed, with market protection applied to market and SL-M orders. A candle-driven option-selling strategy sends a handful of orders a session, so the 10 per second line is nowhere near you. The market-order change is the one to check in your code, because plenty of exit logic still assumes a plain market order.

The daily token, side by side

Everything above sits on top of a login that expires every day. Here is what each broker's documentation says about it, read on 9 November 2026.

Do not hard-code "valid until 6 AM" anywhere. Read the expiry from the response where the broker gives one, and have a job that checks the token well before the open, not at 9:14. A token that died quietly at 3:30 AM is the most common reason a morning run does nothing.

What API access costs, November 2026

These are the prices for API access only. They are not brokerage, and we quote no trading charges for any broker. Read from the broker's own pages on 9 November 2026.

The practical reading for an option seller is simple. Sending orders is free or close to it. The moment you want live prices, the option chain or old candles from the same API, you are paying about Rs 500 a month on Dhan, Groww or Zerodha, and that is the real entry price for a working system. You can take prices from a separate data vendor instead, but that adds a second thing that can break before the open.

What each API publicly documents

Alphabetical order. Everything in this section was read from the broker's own developer documentation on 20 October 2026, and the token, static IP and price details were re-checked on 9 November 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.

Static IP and cost. Dhan says static IP whitelisting is mandatory under SEBI and exchange rules, and only for order placement APIs. You can set a primary and a secondary IP, and after you set one it cannot be changed for 7 days. On the token side, the TOTP route is what lets a server get a fresh token with no one at the keyboard, which answers the daily-token question better than most. Note that RenewToken works only on tokens created from Dhan Web. Trading APIs are free. The data side is Rs 499 plus taxes a month, so the option chain call that makes Dhan attractive for option sellers sits behind that subscription.

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 and cost. An active Trading API subscription is required, bought from the Groww API page. As of 30 September 2026 Groww lists a Free Trial at Rs 0 that excludes the Live Data and Backtesting APIs, a monthly plan at Rs 499 plus tax, and a yearly plan at Rs 4,999 plus tax. The paid plans renew automatically from your Groww balance. Orders must come from a static IP you whitelist on the API Keys page, with a backup address allowed. Two further details from the documentation: the checksum timestamp is valid for 10 minutes, and the live feed allows up to 1,000 subscriptions at a time. One conflict to test on your own account: Groww's curl page says the TOTP flow needs daily approval, while its Python SDK page lists the TOTP flow as "No Expiry".

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. The authentication pages do not print a fixed token lifetime. Each token comes back with its own expires_at, and the approval request itself lapses at 3:30 AM the following day if the customer has not approved it, so your daily approval step has to be finished before then.

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.

Static IP and the April changes. Upstox requires a registered static IP for place, modify, cancel, multi-order and GTT calls. The primary IP is required, the secondary is optional, and either can be IPv4 or IPv6. You can change them once per calendar week, and a successful change invalidates your access token. The same 1 April notice limits you to one active app per user, says algos above 10 orders per second need exchange registration, and says market orders are no longer allowed. We found no API-access price on Upstox's own developer pages, so we state none.

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. The access token expires at 6 AM the next day, which the documentation calls a regulatory requirement. It ends sooner if you log out through the API or do a master-logout from Kite web. The documentation describes a TokenException, preceded by a 403 header, as the sign of an expired or invalidated session.

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. Like Dhan, it also caps modifications at 25 per order, after which the order has to be cancelled and placed again.

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.

Static IP and cost. From 1 April 2026 Zerodha requires a static IP for API order placement. Add the primary IP, and an optional second, under IP Whitelist on the Profile page of your Kite Connect developer account. The change limit is one per calendar week. The Personal plan is free and covers orders, GTT, alerts, margin and portfolio. The Connect plan is Rs 500 a month and adds realtime websocket streaming and historical candles, which is what a live option-selling system needs. If you automate on Zerodha, the plan choice is therefore really a data choice.

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. All four now also require a registered static IP for order placement. 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. If you would rather pay for a platform than write against the API, our paid algo trading software comparison prices the options.

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.

The free and open-source route: OpenAlgo and similar bridges

If you do not want to write four separate broker integrations, there is a middle path. OpenAlgo is an open-source, self-hosted platform released under AGPL-3.0 that puts one API in front of your broker. Its site says it supports more than 35 brokers, connects to TradingView, Amibroker, ChartInk, Excel and Python, and includes a sandbox that trades on live data with 1 crore of virtual capital. It also lists per-leg stops, a basket lock-profit floor and a daily loss limit among its risk controls. We have not run it ourselves, so take this as what the project says about itself, not as a review. Two cautions are fair. A bridge sits between your code and the broker, so it is one more thing that has to survive the token refresh and the static IP rule every day. And you are the one hosting it, so the static IP is still yours to sort out. If that suits you, the sandbox is a sensible place to paper trade the logic before any real order goes out.

If you would rather pay a platform than host anything, our comparison of paid algo trading software prices the options, and the older Zerodha, Fyers and Angel One API comparison covers the brokers this page does not.

Where an API setup breaks on an ordinary day

Most failures I have seen described are dull, and none of them is about the strategy. They are worth writing down before you go live.

The token job fails and nobody knows. The login step runs at 8:55, the broker changes a page or the approval lapses, and the strategy simply never starts. Make that job report success or failure to your phone by 9:00, every day.

The feed drops and the last price looks fresh. Websocket disconnects during a fast move are a common complaint in broker API guides. If your code does not stamp the time of the last tick and refuse to act on an old one, it will happily decide on a price from ninety seconds ago.

Another login kicks your bot out. Some setups limit you to one session. Before you go live, check whether opening the broker's web or mobile app while the bot runs ends the API session.

The IP changes. Orders return a 403, and everything that reads data still works, so the system looks healthy while it cannot trade. Alert on the first rejected order, not the fifth.

The trailing stop hits the modification cap. Zerodha and Dhan both cap modifications at 25 per order. A stop that amends itself every few seconds reaches that in minutes on a busy day. Design the trail to cancel and re-place, or to amend less often.

An exit that assumes a market order. Upstox says market orders are no longer allowed, and exchange rules on algo orders keep tightening. Use a limit order with a sensible price band for exits, and test the exit path as hard as the entry path. The wider list of what goes wrong with automation is in our page on the disadvantages of algo trading.

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.

1. What is the documented access-token validity, and exactly what must happen each day to obtain a new one?
2. Can that daily step be automated within the broker's documented rules, and what is the documented limit on the token endpoint itself?
3. What are the documented rate limits for order placement, quotes, historical data and everything else — as separate numbers?
4. Is there a documented daily order cap, and a documented cap on modifications per order?
5. Which exchange constants does the order API accept, and is the segment for the index you trade among them?
6. Which order types and product types are documented, and do they include the stop variant your rules need?
7. Is there a documented push stream for order updates, or must you poll inside the rate limit?
8. Does the API document an option chain call, full market depth, and history on expired contracts?
9. What activation does your account need — segment activation, API subscription, TOTP, a registered redirect URL, a static IP?
10. Does order placement need a static IP, how many can you register, and how often can you change them?
11. What does the data side cost per month, and does the free plan include the live prices and option chain you need?
12. Where is the changelog, and how will you find out when any of the above changes?

The last item 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

The Bottom Line

If you would rather not write against an API at all, a no-code tool such as Streak sits on top of one; our Streak alternatives guide shows what it does and does not cover. 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 shape your code are narrow. Token life: Zerodha's expires at 6 AM the next day, Dhan's lasts 24 hours and can be generated with a TOTP, Groww's expires daily at 6:00 AM, and Upstox hands you an expiry with each token. Rate limits are per endpoint category and tightest on quotes, 1 request per second on both Zerodha and Dhan, which is the argument for subscribing to a feed instead of polling. Hard ceilings: Zerodha's 5,000 orders a day and the 25 modifications per order on both Zerodha and Dhan. Derivative data: Dhan documents an option chain, full market depth and expired options data, and Groww documents an option chain and a derivatives feed. Since 1 April 2026 all four need a registered static IP for orders, changeable about once a week. And the data side costs about Rs 500 a month on Dhan, Groww and Zerodha, while we found no printed price for Upstox. We are not ranking these, and where your account and capital already sit will reasonably decide it. Run the twelve-point checklist above against your own broker's current documentation, put the last item in your calendar, and remember what no API changes: the door is not the building. Reconnects, partial fills, order reconciliation, risk limits and restart state are 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 quotes no brokerage or trading charges (the only prices on it are the brokers' published API-access prices), 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 or support pages on 20 October 2026 and re-checked on 9 November 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.