Can Pine Script Read Option Chain Data? The Limits and the Workaround

Pine Script can read option chain data only in a very narrow sense: a script can request the price series of a specific option contract whose symbol is written as a constant, and it can do that at most about forty times per script. It cannot compute a strike at runtime (say, the at-the-money strike from today's open) and then fetch that strike's premium, because every data request needs a symbol string known when the script compiles. It cannot pull the whole chain, implied volatility per strike, open interest across strikes, or Greeks. So for anything that looks like real option-chain analysis, the honest answer is no, and the workaround is to do that work outside Pine against a broker API.

I hit this wall building an index-options setup for a client. The strategy needed to watch two legs chosen from the 09:15 open on the strike grid and chart their premiums against the index. That is impossible in Pine, and the project that came out of the wall is a multi-user options terminal. Below is exactly where the limits are, what you can still do inside TradingView, and how the terminal does what Pine cannot. Live-trading context applies: this is engineering, not advice, and traders use their own accounts at their own risk.

Why can't Pine Script request a strike it computes at runtime?

Because of how the data request function is designed. The symbol argument must be a value the compiler can resolve, and while string concatenation is allowed, the practical constraint is that the set of symbols a script requests must be fixed at compile time so TradingView can load those series before the script runs. You can build a ticker string from input values (a user types the strike), but you cannot build it from a series value such as today's open. The reference for the function is at https://www.tradingview.com/pine-script-reference/v6/#fun_request.security.

Two consequences follow. First, an "ATM option premium" plot that re-selects its strike each day is not expressible. Second, a script that wants to cover a grid of strikes must list every one of them explicitly, which runs straight into the second limit.

How many option symbols can one script request?

Roughly forty data requests per script, counting every call to any request function. A 37-strike chain for calls alone uses 37 of them; calls and puts together need 74; add the index itself and a higher timeframe and you are well past the cap. So even a "static" chain for a single expiry is out of reach, and you have to choose a handful of strikes by hand each day, re-edit the inputs, and accept that your chart is stale by the time the first large move happens.

That is the reality behind the word "limits" in this post's title: a hard cap on symbols plus no runtime symbol selection equals no option chain.

What option data can Pine Script actually use?

Within the limits, some useful things are possible:

• A fixed contract's premium, typed in by the user as an input, plotted against the underlying and used for ratios or spreads.
• Index-level derived signals such as the India VIX series, which is a normal symbol.
• Two or three legs of a spread with constant symbols, enough to chart a specific straddle or strangle for its life.
• Expiry-aware logic using calendar functions, so a script knows how many days remain and can adjust what it plots.

What stays impossible: live chain tables, PCR across strikes, max-pain, IV smile, OI build-up heatmaps, or any strategy that picks its strike from the day's price action. For those you need a process with API access to a broker's option chain.

How does a broker API option chain differ from TradingView's data?

A broker API gives you the full instrument master (every strike and expiry with its token), quote endpoints that return bid, ask, last price, volume and open interest for any list of tokens, and websocket streams for live premiums. The strike you want can be chosen by code at any moment, because the lookup happens at runtime against the master. Indian brokers such as Zerodha (Kite Connect) and Angel One (SmartAPI) both offer this, with documentation at https://kite.trade/docs/connect/v3/ and https://smartapi.angelbroking.com/docs.

What you give up is the chart. You now have to align option premiums to the index on shared timestamps, build candles from ticks or pull interval data, and render them yourself. That is a day's work with a browser charting library, and the result is a chart that shows what Pine structurally cannot: the premium of whichever strike your rule selected this morning. If you are deciding which broker to build on in India, the comparison in best broker for TradingView automation in India covers the API and whitelisting differences.

Why does the 09:15 open matter for an options rule?

Because many intraday index-options setups define their legs relative to the opening price: round the open to the strike grid, pick the call and put a fixed number of steps away, and trade a rule on those two premiums for the rest of the day. The strike selection is a runtime computation, which is exactly what Pine forbids, and it has a subtle trap of its own: rounding. The rounding helper that maps an open price to a strike must be a single source of truth used by every part of the system. In my build, a mismatch between two rounding paths produced legs one strike apart in two places and was only caught by comparing them side by side. One function, used everywhere, fixed it.

How I built this: CE/PE Options Terminal: Multi-User Index-Options Automation

The CE/PE Options Terminal exists because Pine could not do the job. It is a FastAPI application that pulls real premiums for any strike from a broker API, aligns them to the index on shared timestamps, charts them with a lightweight browser charting library, scores a four-setup CE/PE rule and, for clients who enable it, runs live Zerodha order automation. The build went like this:

1. Escape the limit. Replace Pine's constant-symbol requests with runtime lookups against the broker instrument master, so the strike is chosen from the 09:15 open on the strike grid by a single rounding helper.
2. Chart what Pine cannot. Premium series for the selected legs are aligned to the index and rendered in the browser with lightweight-charts, with the setup score overlaid.
3. Measure honestly first. Early sessions were evaluated as given; the spec lost money, and two structural reasons were documented for the client before any automation was added.
4. Make it multi-user. An admin issues client logins with access windows; the admin's own broker session acts as the market-data donor so clients do not each need a data subscription.
5. Satisfy broker whitelisting. Because the broker refuses one IP whitelisted against two trading accounts, each client gets a dedicated reserved egress address, provisioned on demand by a root-owned timer since the service itself runs without privilege escalation.
6. Trade on rules, not clicks. At 09:15 the two legs are fixed from the open; the engine streams premiums, scores the setup and places at most one trade per day per client; positions are exited on rules even if the client's access window has expired mid-trade.
7. Deploy safely. A deploy script backs up, refuses to proceed if any user has an active trade, and restarts the service.

The decisions I would defend: a single source of truth for strike rounding after the mismatch was found, the measured-negative result reported before automation, hard privilege separation between the provisioning timer and the app, and a deploy that refuses while money is on the table. The outcome is a production multi-user terminal that charts real option-chain premiums where Pine cannot, with per-client egress addresses that keep broker whitelisting happy.

FAQ

Can I at least plot one option contract in Pine Script?

Yes. Type the contract's TradingView symbol into an input and request it like any other series. It will work for that contract's life, and you will re-type it at every expiry or strike change.

Will TradingView add option chain support to Pine?

I cannot predict their roadmap. The forty-request cap and compile-time symbols are deep design constraints, so I would not plan a project around a future change.

Can a webhook from TradingView select the strike for me?

Partly. A Pine alert can send the index price in its message, and a receiving service can compute the strike and place the order. That moves the strike logic out of Pine, which is the right place for it, but the chart in TradingView still cannot show the premium you ended up trading.

Which broker APIs give option chain data in India?

Zerodha Kite Connect, Angel One SmartAPI, Upstox, Dhan and Fyers all expose instrument masters and quotes for option contracts. Market-data entitlement, historical candle availability and IP whitelisting rules differ, so check those before choosing.

If you want option-chain charting or a rules-based options terminal built against your broker, tell me about it on the contact page.