request.security() in Pine Script evaluates an expression on another symbol, timeframe or data context and maps the result onto the chart. For higher-timeframe data, lookahead_on without a historical offset can expose future values on historical bars. TradingView's documented pattern uses the previous higher-timeframe value, such as close[1], with barmerge.lookahead_on to keep its availability consistent between historical and realtime bars.
request.security() at a glance
As of 25 September 2026, TradingView documents the following behaviour.[1] The Pine Script library connects these data requests to conditions, strategies and alerts.
Scroll horizontally to read every column.
| Item | Meaning |
|---|---|
symbol and timeframe
|
The context in which the expression is calculated, such as the chart's symbol on hourly bars. |
expression |
The value or calculation to request, evaluated in that context. |
lookahead |
Controls historical alignment. Default: barmerge.lookahead_off. |
gaps |
Controls missing values between updates. Default: barmerge.gaps_off. |
| Confirmed higher-timeframe pattern | Offset the expression by one requested bar and use barmerge.lookahead_on. |
| Important limit | A closed chart bar does not necessarily mean the requested higher-timeframe bar has closed. |
What is the request.security() signature?
request.security(symbol, timeframe, expression, gaps, lookahead, ignore_invalid_symbol, currency, calc_bars_count)
The first three arguments identify the data and calculation. The remaining arguments are optional. A scalar price expression returns a price series; the function also supports other types and tuples.[1]
-
Symbol: an exchange-qualified ticker identifies the feed.
syminfo.tickeriduses the chart's ticker ID. -
Timeframe: a Pine timeframe string.
"60"means 60 minutes;"1D"means one day. -
Expression:
closerequests that context's close.close[1]requests its previous bar's close, not the previous chart bar's close. -
Other options:
ignore_invalid_symbolcontrols whether an invalid request returnsnainstead of stopping with an error.currencycontrols currency conversion, andcalc_bars_countlimits the requested calculation history.
Keep the offset inside the request. Appending [1] to the completed request.security() result shifts the already mapped chart series by one chart bar. Those operations use different clocks.[1]
Why can lookahead_on leak future data?
On historical bars, TradingView already has the completed higher-timeframe bar. With an unoffset expression and lookahead_on, the request can place that bar's final value at the start of its period. A realtime script could not have known that final value then.[2]
lookahead_off avoids that historical future leak, but it does not freeze the requested value during realtime execution. A current hourly close can change while an hourly bar develops, including at intermediate chart-bar closes. Reloading the script can therefore change its earlier displayed values.[1]
The two questions are separate: does history use information too early? And can the input change before its own bar closes? A request can avoid the first problem while still having the second.
Worked example: an hourly close on a 15-minute chart
Illustrative values, not recommended settings. Assume continuous, aligned bars in one timezone. The 08:00–09:00 hourly close is 100. During 09:00–10:00, price is 104 at 09:15 and eventually closes at 110. The hour contains 60 ÷ 15 = four chart bars.
| Hourly request | At 09:15 in realtime | The 09:00 chart bar after reload |
|---|---|---|
close, lookahead off |
104, an unfinished hourly close | 100; the new hourly close maps to the period's last chart bar |
close, lookahead on |
104; the final 110 is still unknown | 110, placed before it was knowable |
close[1], lookahead on |
100, the previous completed hour | 100, the same completed hour |
All three rows assume gaps_off. The offset pattern holds 100 through the 09:00 hourly period and makes 110 available in the next period, beginning at 10:00. A script that only evaluates at chart-bar close will act at its next eligible calculation.[1]
What is the documented non-repainting HTF pattern?
Use the last confirmed higher-timeframe value with consistent mapping. The offset and lookahead_on belong together; removing either changes the behaviour.[2] This example also rejects timeframes that are not higher than the chart's.
Illustrative sketch; not compiled or tested. Paste into the TradingView Pine Editor. The hourly input illustrates timing, not a trading rule. Function definitions are in the Pine Script v6 Reference Manual.[3]
//@version=6
indicator("Confirmed HTF close", overlay = true)
htf = input.timeframe("60", "Higher timeframe")
if timeframe.in_seconds(htf) <= timeframe.in_seconds()
runtime.error("Select a timeframe higher than the chart.")
confirmedClose = request.security(syminfo.tickerid, htf, close[1],
gaps = barmerge.gaps_off, lookahead = barmerge.lookahead_on)
plot(confirmedClose, "Previous HTF close")
The trade-off is explicit: the rule uses the completed previous higher-timeframe bar. It does not react to the developing current one. For a tuple of requested prices, TradingView's example offsets every element separately.[1]
What do gaps_on and gaps_off change?
barmerge.gaps_on returns na where no new confirmed requested value is available. barmerge.gaps_off fills intervening chart bars with the available value. With an unoffset request, that can mean the last confirmed value historically but a developing value in realtime.[1]
Filling a gap is not confirmation. Conversely, replacing an intentional na with zero invents an observation. The nz() and missing-values guide explains why a replacement needs a defined meaning.
How does higher-timeframe data affect alerts and PineConnector?
barstate.isconfirmed concerns the chart bar. Combining it with a developing hourly request on a 15-minute chart does not make the hourly value final. Define both which requested bar supplies the input and when the chart evaluates the alert condition.[1][2]
TradingView alerts trigger only in realtime. An alert using alert.freq_once_per_bar_close also needs its alert() call to execute on the closing update. A historical marker is not evidence that such an alert was sent.[4]
For a PineConnector workflow, follow the documented demo verification steps: inspect the TradingView alert log, then the PineConnector processing record, then the broker account.[5] The condition, alert trigger, webhook delivery, processing and EA order request are separate stages. Broker acceptance, a deal and the resulting position require their own evidence.[6]
Which mistakes does this pattern not fix?
-
Lower-timeframe requests: this is a higher-timeframe pattern.
request.security()returns a selected intrabar when requesting lower timeframes;request.security_lower_tf()returns arrays of available intrabars.[1] - Another repainting input: a stable requested close does not stabilise every other condition in the script.
- Revised data: TradingView identifies feed revisions and changes in available history as other causes of changed results.[2]
- Stale alerts: editing the chart script does not update the copy saved in a running alert. Recreate affected alerts after checking the new logic.[4]
Frequently asked questions
What does request.security() do in Pine Script?
request.security() evaluates an expression using another symbol, timeframe or data context and maps the result onto the chart. The expression runs in the requested context, so close[1] means the previous requested bar's close. The function retrieves data; it does not create an alert or send a broker order.
Does barmerge.lookahead_on always repaint?
No. For a higher-timeframe request, lookahead_on paired with an unoffset price expression leaks future values into historical bars. TradingView documents a different use: offset the expression by one requested bar and combine it with lookahead_on. That pattern consistently returns the previous confirmed higher-timeframe value.
Does lookahead_off prevent higher-timeframe repainting?
lookahead_off prevents a current higher-timeframe bar's final value from appearing prematurely in history. It can still return developing higher-timeframe values during realtime execution. Those values may differ after a reload. A closed lower-timeframe chart bar does not by itself confirm the higher-timeframe input.
Why does close[1] belong inside request.security()?
Inside request.security(), the history offset operates on bars of the requested context. Outside the call, the offset operates on the series already mapped onto chart bars. On a 15-minute chart requesting hourly data, the first refers to a previous hour and the second shifts the mapped output by one 15-minute bar.
Reviewed 25 September 2026. Facts were checked against the linked sources on that date. Nothing in this article was tested on a trading account and no code was compiled.
Related reading
- Pine Script guide and function library
- barstate.isconfirmed and bar-close alerts
- Pivot confirmation and plotting in the past
- alertcondition() versus alert()
Sources
- TradingView – Other timeframes and data, accessed 25 September 2026.
- TradingView – Repainting, accessed 25 September 2026.
- TradingView – Pine Script v6 Reference Manual, accessed 25 September 2026.
- TradingView – Alerts, accessed 25 September 2026.
- PineConnector – Test your setup, accessed 25 September 2026.
- MetaQuotes – Basic principles: orders, deals and positions, accessed 25 September 2026.
PineConnector executes the instructions you send it. It does not select trades, manage money, or hold funds. Trading carries risk, and past performance of any strategy does not indicate future results.
