A multi-timeframe indicator can look clean in the editor and still stop with "Script requesting too many securities." You were not necessarily asking for too many visible plots. Pine is counting the separate data contexts requested behind the scenes. The Pine Editor on TradingView is deliberately strict, which is useful once you know what it is protecting you from, but not very comforting when you need one line fixed now.
request.security() is powerful because it retrieves another symbol or timeframe while your script runs on the current chart. It is also a constrained resource. A request is defined by its dataset context and expression, so repeating slightly different calls can consume more of the allowance than the code appears to at a glance.
What this error actually means
The error means the script has created more unique request contexts than the account and script environment allow. Exact limits can vary by plan and request type, so do not build a design around a single hard-coded number. Instead, reduce unnecessary unique combinations and combine related values that share the same symbol and timeframe.
Pine evaluates request calls over historical bars and must manage the resulting series data. A request for the same symbol, timeframe, and expression can be reused, while a different timeframe, ticker, or expression may be a distinct context. Nested functions and loops can hide the real request count, which makes this error feel surprising.
The code pattern that causes it
A common pattern is requesting each higher-timeframe value separately even though all values use the same symbol and timeframe. That creates several contexts where one tuple request can return the values together. The goal is not to remove useful analysis. It is to avoid asking for the same data environment repeatedly.
//@version=6
indicator("Separate requests")
dailyClose = request.security(syminfo.tickerid, "D", close)
dailyHigh = request.security(syminfo.tickerid, "D", high)
dailyLow = request.security(syminfo.tickerid, "D", low)Three requests may be manageable in a small script, but this pattern scales badly when repeated across symbols and timeframes. It also hides the relationship between values that all come from the same daily context. Consolidating related values reduces duplication and makes the source of the data clearer.
The smallest useful fix
//@version=6
indicator("Combined request")
[dailyClose, dailyHigh, dailyLow] = request.security(
syminfo.tickerid, "D", [close, high, low]
)The tuple expression requests values from one shared context. It is not a universal cure, because distinct symbols and timeframes are still distinct contexts, but it is the first optimisation to make when related values come from the same place. Test the result carefully after each consolidation so you preserve the intended timing and non-repainting behavior.
Pine v6 supports dynamic requests by default in many cases, which makes loops and symbol arrays more flexible, not unlimited. A loop can still create many unique contexts when its symbols or timeframes vary. Build a fixed, intentional watchlist and inspect every request path rather than assuming a loop makes requests free.
How to diagnose it without guessing
List each request.security call with its symbol, timeframe, and expression. Include calls inside helpers, loops, and imported libraries. Group calls that use the same symbol and timeframe, then look for duplicate or combinable expressions. This inventory often reveals that a feature added months later is requesting data already available elsewhere.
Design multi-timeframe features around a small explicit set of contexts. Combine related values in tuple requests, reuse calculated series where possible, and avoid calling request.security inside a calculation that executes more often than necessary. Our dynamic requests in Pine Script v6 guide explains the flexible side of the feature in more detail.
Dynamic requests add flexibility, not unlimited contexts
Pine v6 can make request contexts dynamic, which is useful when a loop iterates through a controlled list of symbols or timeframes. It does not remove request limits. A script must still establish the contexts it needs predictably on historical bars before it asks for a new context in realtime. Treat a dynamic watchlist as data architecture, not as a way to generate an unbounded scanner from user input.
Combine only values that truly share the same symbol, timeframe, and timing requirements. A tuple request is helpful for daily close, high, and low from one symbol. It is not a reason to merge requests with different lookahead choices or different confirmation rules. After consolidation, compare the plotted values and alert conditions on both historical and realtime bars so a performance fix does not introduce repainting.
Treat every request as part of a budget
Before adding a request, write down the symbol, timeframe, expression, lookahead setting, and why the value cannot be calculated on the chart timeframe. This small inventory prevents accidental duplicates when a script grows. It also reveals when a helper function hides a request that is called from several features. A request budget is easier to maintain than a last-minute search for whichever line pushed the script over a platform limit.
Use one request to retrieve values that share a context, then calculate related values locally when the semantics allow it. For example, requesting daily close once and applying a simple comparison on the chart is often clearer than requesting several nearly identical daily expressions. Do not move a calculation locally if it changes the intended higher-timeframe behavior. Correct timing is more important than reducing a call count by one.
If you truly need many symbols, make the list explicit and expose a sensible maximum rather than accepting arbitrary user text. Explain the limit in the script settings and fail gracefully when an optional group cannot be enabled. That is better engineering than promising a universal scanner that depends on request contexts the platform may not permit. It also makes future performance work much more predictable.
Preserve timing while you reduce request count
A request budget is not only about the number of calls. It is also about when requested values become available. Higher-timeframe data can change while its source bar is still forming, and different request settings can change whether a value is confirmed. Before combining or moving a request, write down whether the result is intended for a live display, a confirmed alert, or historical analysis. A smaller request count is not an improvement if it silently changes the timing of a signal.
Keep the expression inside request.security as narrow as possible when several downstream features need the same raw data. Retrieve the shared close, high, low, or a well-defined indicator value, then give the returned series a clear name. Calculate chart-timeframe-only logic outside the request. This makes it easier to see which code is truly higher-timeframe and prevents the same context from being recreated under slightly different expressions.
When a watchlist is optional, separate required symbols from optional symbols in the code and settings. Request the core context first, then add optional groups only when the user enables them. This makes the platform limit an explicit design constraint rather than a runtime surprise. It also gives you a straightforward way to test each group and document the maximum supported configuration without overstating what Pine can scan.
After consolidation, compare the old and new versions on a fixed set of chart bars. Check the first available higher-timeframe bar, a normal historical section, and the latest unconfirmed bar. If an alert depends on the value, check its condition separately from the plot. This review proves that the optimization preserved the data contract rather than merely removing the error message.
When a request reduction changes the script, document the remaining contexts in a short comment near the request section. State the symbol source, timeframe, and why each request is needed. That comment is not an excuse for unclear code. It is a map for the next maintenance edit, when a new feature may otherwise add a duplicate request because the existing data dependency is hidden several functions away.
Optimize requests without obscuring the change
A large AI rewrite can hide the most important part of this repair: which data contexts were removed, combined, or moved. If a script is near a platform limit, you want an auditable diff and a clear inventory, not a new version that happens to compile but silently loses a symbol or timeframe.
PineScripter can help make focused edits after an in-app lint finding, preserve the existing script around those edits, and keep the conversation with the code in one workspace. Its manual context is useful for request syntax, but it cannot replace the needed visual and non-repainting checks. Review the diff and test the final requests in the Pine Editor.
For the underlying language rule, consult TradingView documentation on other timeframes and data. Related reading: dynamic requests in v6, non-repainting multi-timeframe analysis, Pine Script performance fixes.
A practical checklist before you paste again
Inventory every request, group shared symbol-timeframe combinations, combine related values, remove duplicates, and re-check the output on historical and realtime bars. Do not solve a request-limit error by silently dropping a condition you still rely on.
This limit is a signal to make the data model explicit. A smaller, intentional set of request contexts is easier to maintain, easier to explain, and less likely to fail when you extend the script later.
Disclaimer: PineScripter is a coding tool for Pine Script development. It does not provide financial advice and does not guarantee trading profits. Always backtest strategies thoroughly and understand the risks before live trading.