TradingView Footprint Data in Pine Script: The Real Limits

You just found out Pine Script can pull real footprint data now, and your first instinct is to slap a delta-divergence strategy on EUR/USD. Don't. Footprint data (the buy and sell volume printed at each price level inside a single bar, inst

You just found out Pine Script can pull real footprint data now, and your first instinct is to slap a delta-divergence strategy on EUR/USD. Don't. Footprint data (the buy and sell volume printed at each price level inside a single bar, instead of one lump total) is one of the more interesting things TradingView shipped this year, but it only exists where a market actually reports its trades, and a huge share of what retail trades every day doesn't. request.footprint() puts real order-flow data inside your own script for the first time, and it is structurally blind on the one asset class most beginners reach for first.

Footprint charts used to mean buying different software

A footprint chart shows you both sides of a bar's volume: how much traded at the ask (aggressive buying) and how much traded at the bid (aggressive selling), broken out by price, not just netted into one number. For years, getting that view meant leaving TradingView entirely for specialist platforms like Bookmap, ATAS, or an order-flow add-on bolted onto Sierra Chart.

That changed in January 2026, when TradingView added request.footprint() and two new data types, footprint and volume_row, to Pine Script. For the first time, you can pull genuine order-flow data into a script you wrote yourself, instead of reading it off someone else's proprietary chart.

What request.footprint() actually hands your script

Call the function on a bar and, when the data exists, you get an object back with the bar's total buy volume, total sell volume, and the delta (buy minus sell, the tug-of-war result for that bar). You also get the Point of Control, the single price level inside that bar with the most volume, plus the Value Area High and Value Area Low marking the price band around it that absorbed most of the trading.

Underneath that, the volume_row type gives you the same breakdown one price tick at a time: volume, delta, and buying or selling imbalances at each individual row. A normal volume bar is a receipt showing what got spent in total. Footprint data is the itemized version, every line, showing exactly who paid up and who got run over.

The na check that separates a working script from a broken one

Here's the line in TradingView's own footprint documentation that actually matters more than the feature list: if no footprint data is available for a given bar, the function returns na. Not zero, not an empty object, na, undefined.

Skip the check and your script doesn't just misbehave on the edge case. It misbehaves on an entire category of instruments, silently, which is worse. Every footprint script needs to confirm the object isn't na before it touches a single field.

Forex pairs return na, and that is not a bug

This is where the excitement runs into the wall nobody mentions in the launch thread. Footprint data requires real trade-level volume: an actual tape of executions at actual prices. Spot forex trades over the counter across a scattered web of banks and liquidity providers, with no single consolidated tape anywhere. There's nothing to itemize because there was never one register ringing up every trade in the first place.

request.footprint() requires a Premium or Ultimate TradingView plan on top of that. So the two ways this feature can disappoint you are stacked: pay for a tier you might not have, then discover the market you actually trade doesn't produce the data type the function needs, regardless of plan.

Where the data is actually real: futures, listed stocks, liquid crypto

Footprint data works where trades genuinely clear through a small number of reporting venues: CME-listed futures, exchange-listed stocks, and crypto pairs on the larger centralized exchanges. Those markets have an actual tape, so the buy and sell split at each price row means something real rather than being reconstructed from tick direction guesses.

That narrows the honest use case considerably. If your edge lives on index futures or a handful of liquid large-cap names, this is a genuinely new tool. If it lives on currency pairs, the feature just isn't built for your market yet, and no amount of clever Pine will change what data physically exists.

Treat new data like a new instrument, not a shortcut

You can't order-flow a market that never tells you who traded.

— The Tradoki desk note

None of this means footprint data is a gimmick on the instruments where it does work. Delta divergence, absorption at a level, imbalance clusters at a price: these are real, tradeable observations when the underlying tape is real too. But a new data source deserves the same skepticism as a new indicator. It describes what already happened at that price. It doesn't predict what happens next, and neither does anything else on your chart.

Run it on demo first, on the actual instrument you plan to trade, across more than one session before it ever touches size. Watch for the na bars. If you're writing the script itself with an AI assistant rather than by hand, that na-check is exactly the kind of edge case those tools tend to skip unless you spec it explicitly. The imbalance reading that looked like a clean signal on Monday's futures session is worth nothing if half your test data was actually silent forex bars returning nothing at all.

● FAQ

What is request.footprint() in Pine Script?

It's a function TradingView added to Pine Script in January 2026 that returns a footprint object for the current bar: total buy volume, total sell volume, the volume delta, and the bar's Point of Control, Value Area High, and Value Area Low, plus per-price-row detail through a companion volume_row type.

Do I need a paid TradingView plan to use it?

Yes. request.footprint() only works on a Premium or Ultimate TradingView plan, per TradingView's own documentation. You can write and compile the code on a lower tier, but the function returns na on every bar.

Why does request.footprint() return na on forex charts?

Because footprint data is built from real trade-level volume, and spot forex trades over the counter across many venues with no single consolidated tape. TradingView's own footprint documentation states the function returns na when no footprint data is available for a bar, and a market with no real trade tape has none to give.

Is footprint data the same thing as the Volume Profile indicator?

Related, not identical. Volume Profile plots historical volume by price directly on the chart for you to read. request.footprint() hands that same category of data, plus buy/sell splits and row-level imbalances, to your own script bar by bar, so you can build logic around it instead of just eyeballing it.

Should I build a live strategy around footprint data right away?

No. Treat any new data source the way you'd treat a new instrument: run it on a demo account first, across more than one session and more than one symbol, before it touches real risk.