TradingView Request Security: Complete Guide to Multi-Timeframe Data Analysis
The request.security() function is like a superpower for your TradingView scripts. Ever wanted to see what the daily chart is doing while you're looking at a 15-minute graph? Or compare how Apple's stock is moving relative to the overall market? This function makes it all possible.
It lets your script peek at data from different stocks, timeframes, and even different types of charts, bringing that information back to your main chart. It's the secret sauce for building indicators and strategies that are truly informed by the bigger picture.
What is the request.security() Function?
In simple terms, request.security() fetches data for you. You tell it what to look at (like a stock symbol), over what time period (like a "1D" for daily), and what information you want (like the closing price). The function then goes and gets that historical and live data, delivering it right to your script.
Here's a basic look at how you use it:
| Component | What It Does | Example |
|---|---|---|
| Symbol | The ticker you want data from. | "NASDAQ:AAPL" |
| Timeframe | The bar length to analyze. | "1D" (for 1 Day) |
| Expression | The specific data you want back. | close (the closing price) |
So, you can build a script on a 5-minute chart that quietly checks the daily trend in the background. This helps you make smarter decisions by understanding not just what's happening right now on your chart, but also what's happening in other contexts.
Understanding the Core Settings and Options
The request.security() function works with a few key settings that determine what data you get and how it's processed. Let me break down the most important ones for you.
The symbol is simply the ticker name of what you want to analyze. You can write it in a few ways: just the name like "AAPL", as an exchange-pair like "NASDAQ:AAPL", or even as a spread. While the simple name often works, specifying the exchange (like "NASDAQ:AAPL") is a good habit—it helps ensure you get the exact data you're looking for and avoids mix-ups.
The timeframe controls the "zoom level" of your data. Think of it as choosing between a daily, weekly, or minute-by-minute view. You use simple strings like "D" for daily, "W" for weekly, or "60" for a 60-minute chart.
The expression is where you tell the function what specific data to pull. This could be something straightforward like the closing price, or a more complex formula you've built yourself, perhaps involving a technical indicator like the Guppy EMA Indicator for multiple moving average analysis.
Now, the lookahead setting is super important because it deals with a common pitfall known as "repainting." Let's be clear about what this does:
barmerge.lookahead_off(The Safe Default): This setting guarantees the function never accidentally uses future data that wouldn't have been available in real-time. It's the safest choice to keep your strategy honest, though it can sometimes cause the most recent bar's values to adjust as new price data comes in.barmerge.lookahead_on(Use With Caution): This allows the function to see data from the future of the lower timeframe. It's powerful but can be dangerous. If you use this, you absolutely must implement it correctly with offsetting to avoid creating a strategy that looks amazing in hindsight but fails in live trading.
Common Use Cases and Practical Applications
One of the most popular ways traders use request.security() is to pull higher timeframe levels onto their intraday charts. Imagine you're day trading on a 5-minute chart, but you can see exactly where the daily or weekly highs and lows are plotted in real-time. This gives you a fantastic view of the major support and resistance zones that other traders watching those bigger timeframes are also paying attention to. It's like having a roadmap for your day trading, helping you spot better entry and exit points that are in sync with the larger trend.
Another incredibly powerful way to use this function is for comparing different assets. Your script can look at the current stock or currency you're charting and simultaneously pull in data from a market index, a related asset, or a leader in the same sector.
| Use Case | What It Helps You Do |
|---|---|
| Multi-Timeframe Analysis | Plot key daily/weekly support & resistance levels on intraday charts. |
| Multi-Symbol Analysis | Compare a stock's performance against an index or a sector peer to gauge relative strength or weakness. |
| Intrabar Analysis | Look inside a candle or bar to see the price action that formed it. |
This comparison can reveal if your asset is stronger or weaker than the overall market (relative strength), if it's moving out of sync (divergence), or if money is rotating into or out of a specific sector.
Finally, by using request.security_lower_tf(), your scripts can dig even deeper. This function returns an array of the individual price points that make up a single bar on your chart. This lets you analyze the detailed price action that happens within a 1-hour or 1-day candle, potentially revealing patterns and conditions that you'd otherwise miss if you only looked at the open, high, low, and close.
Avoiding Repainting Problems in Your Scripts
Repainting is one of those tricky issues that can really throw off your trading scripts when you're using request.security(). It happens when an indicator's values change after a bar has already closed—like getting a signal that wasn't actually there when you look back.
Here's why it happens: request.security() acts differently on past data versus what's happening right now. On historical bars, it only shows you the final, confirmed values. But on the current, real-time bar, it might show you values that are still changing.
How to Fix Repainting on Higher Timeframes
If you're pulling data from a higher timeframe (like using a daily average on a 1-hour chart), here's a solid way to prevent repainting:
- Offset your calculation by at least one bar using the history operator
[] - Set the
lookaheadparameter tobarmerge.lookahead_on
This one-two punch makes sure you're only ever working with finalized data from the higher timeframe, which keeps your backtests honest and your live trading in sync. If you're building complex strategies, you might want to explore tools like the Zero Lag EMA Indicator which can help minimize lag without introducing repainting issues.
Dealing with the Same Timeframe
What if you're using request.security() on the same timeframe your chart is on? Repainting can still happen because the function will give you a live, updating value while the bar is forming, and then a fixed one after it closes.
You have two main choices here:
- Stick to confirmed data by only referencing values from previous, closed bars.
- Just be aware that the real-time value will jump around until the bar finally closes and the value is locked in.
Write Faster, Smoother Scripts
Let's talk about making your scripts run faster. It's a bit like running errands—making one well-planned trip to the store is way more efficient than going back and forth five times for single items.
Your scripts can technically handle up to 40 request.*() calls, but you really want to keep that number as low as possible. Each call takes a little time and memory, and those bits add up.
Here's the key trick: instead of asking for different pieces of data from the same chart and timeframe separately, ask for them all at once. You can do this by bundling them into a tuple or a custom type. It's the difference between making three separate phone calls and one conference call.
Instead of this:
highValue = request.security(syminfo.tickerid, "D", high)
lowValue = request.security(syminfo.tickerid, "D", low)
closeValue = request.security(syminfo.tickerid, "D", close)
You can do this:
[highValue, lowValue, closeValue] = request.security(syminfo.tickerid, "D", [high, low, close])
By consolidating your requests, you're telling the system, "Hey, I need these three things from the same place, so get them for me in one go." Testing with TradingView's tools shows this simple change can slash your script's runtime by over 30% compared to using multiple separate calls.
Another simple setting that makes a big difference is calc_bars_count. Think of this as deciding how far back in history you need to look. If your script only cares about recent action, there's no need to process five years of data. Limiting this parameter is like saying, "Only calculate the last 500 bars," which lightens the load significantly without changing what your script does. It's a straightforward way to get a speed boost.
Advanced Techniques and Best Practices
Think of request.security() as a way to ask for data from another chart or timeframe. Now, imagine you could send a whole package of instructions along with that request. That's what happens when you pass a user-defined function to it. The really cool part is that all the calculations inside your function happen over there, on the other chart, and you just get the final result back. This is super helpful when you need to figure out several related numbers all at the same moment in time.
User-defined types take this idea even further. Instead of just asking for a single number, you can ask for a whole custom-built object. This object can hold multiple pieces of information—different kinds of numbers, price points, lists of data, or even other custom objects nested inside. It's like requesting a pre-assembled data package instead of having to collect all the pieces yourself.
Now, here's a common hurdle: using request.security() inside loops. You might run into a wall here because you can't call it dynamically inside a standard for loop. There is a feature called dynamic_requests that offers a bit of a workaround by letting you use a changing string as a parameter, but it's important to know that the function will run on every single chart update, even if your other logic says it shouldn't.
Common Pitfalls and How to Sidestep Them
When you're building scripts, it's easy to stumble on a few common hurdles. Let's walk through them so you can avoid the headaches down the line.
Forgetting the Exchange Prefix
This is a big one. If you don't tell the script which exchange a symbol is from, you can get messy data. This happens because the same ticker (like "AAPL") can be listed on multiple exchanges with slightly different price data. For reliable, consistent data—especially for strategies that will place real trades—always include the exchange identifier.
Think of it like this:
| Without Exchange | With Exchange (Better) |
|---|---|
request.security("AAPL", ...) | request.security("NASDAQ:AAPL", ...) |
Misusing the Lookahead Parameter
Misunderstanding barmerge.lookahead_on can seriously skew your backtest results. When you use it without properly offsetting your expressions, you're accidentally peeking into the future on historical bars. Your strategy will look amazing in a backtest because it's acting on data it shouldn't have known yet. In live trading, that "magic" disappears, and the strategy will perform completely differently. Always double-check that you aren't accidentally introducing future data.
Assuming request.security() is Conditional
Here's a subtle point that often trips people up. The request.security() function runs on every single tick, no matter what. Even if you place it inside an if statement or another conditional block, it will still execute. The script essentially grabs that data first, before running the rest of your logic. It's important to know this so you have accurate expectations about your script's performance.
Got Questions? Let's Break It Down.
What's the real difference between request.security() and request.security_lower_tf()?
Think of it like this: request.security() gives you a single, final piece of information from a different timeframe or symbol—like getting the final closing price for the day. On the other hand, request.security_lower_tf() gives you a whole list of data points from within that single bar, letting you see all the little moves that happened inside it. Use the first for the big picture and the second when you need to peek under the hood.
How do I stop my indicator from changing its mind (repainting) with request.security()?
This is a classic headache. When you're pulling data from a higher timeframe, a good trick is to offset your expression by one bar (using [1]) and turn on the barmerge.lookahead_on setting. This basically tells the script to only use data from bars that are fully confirmed and in the past. For the same timeframe, just be careful to only use data from completed bars, not the one that's still forming.
Can I grab data from several symbols at once using request.security()?
Absolutely, you can. You just make multiple request.security() calls, each for a different symbol. But a word of caution: each call adds a bit more work for the system. If you're checking a lot of things, it's smarter to bundle your requests together using tuples or custom types to keep things running smoothly.
Why does my request.security() call run even when I put it inside an 'if' statement?
This one trips up a lot of people. request.security() is processed before the rest of your script logic runs. It's like it does its homework first, no matter what. So, even if you wrap it in a condition, the function itself will still execute on every single price update. The condition only controls whether or not you use the result it gives you.
What kind of stuff can request.security() actually give back?
It's pretty flexible! It can return simple things like numbers, true/false values, and text. But it can also handle more complex stuff like lists of values (arrays), color codes, and even bundles of different information (tuples and user-defined objects). This lets you pull over some really sophisticated data, as long as the building blocks are of a supported type.
Your Next Steps
Alright, you've got a solid grasp of what request.security() can do and how to use it wisely. So, what's the real-world game plan? Let's break it down into manageable steps.
Start by getting your hands dirty with something straightforward. A great first project is to pull a daily average or a key level onto your 1-hour or 15-minute chart. Seeing that higher-timeframe context on your intraday view is a game-changer and a perfect way to get comfortable.
From there, you can level up. Try comparing the strength of one asset to another, or get creative by building an indicator that uses a completely custom timeframe, like a 2-hour or 6-hour bar. If you're looking for other powerful indicators to incorporate, check out our guide on day trading indicators that actually work for inspiration.
Your Pine Script Playground
The best way to learn is by doing. Fire up the TradingView Pine Script editor and just experiment.
- Tweak the Knobs: Play with all the different parameters in
request.security(). Change the timeframes and, most importantly, toggle thelookaheadsetting on and off. Watch how it changes your plots on the chart—this is the best way to truly understand how lookahead bias works. - Check the Speed: Use the built-in profiler to see how adding multiple
securitycalls affects your script's performance. If things start to slow down, see if you can combine or simplify your requests to make your code more efficient.
Don't Go It Alone
The TradingView community is a fantastic resource.
- Join the Conversation: Hop into the TradingView forums and Pine Script-focused groups. Share what you've built, even if it's simple. You'll be amazed at what you can learn from seeing other developers' code and getting their feedback on yours.
- Learn from the Pros: Find some popular open-source indicators that use
request.security()effectively. Peek under the hood to see how they handle complex logic and error-checking. It's like a free masterclass in real-world Pine Script.
Bringing It All Together
Your ultimate goal is to build a robust trading system. Use request.security() to add a layer of confirmation. For example, only take buy signals on your 5-minute chart when the daily trend is also pointing up. This multi-timeframe alignment can make your strategy much more resilient.
Finally, and this is crucial: test relentlessly.
- Backtest: See how your strategy would have performed historically.
- Paper Trade: Run it in real-time with fake money to make sure it behaves as expected.
- Verify: Double-check that none of your indicators are "repainting" (changing after the fact) because of incorrect lookahead settings.
Only after you're completely confident should you even think about deploying it with real capital. Happy coding
If you want to accelerate your Pine Script development even further, consider using Pineify - the best AI Pine Script generator and visual editor for TradingView. It eliminates the need for manual coding while ensuring error-free scripts. With Pineify's visual tools and AI assistant, you can build complex multi-timeframe strategies like the ones discussed in this article in minutes instead of hours, saving you both time and money on freelancers.