TradingView sends every webhook alert, from every account, on every plan, for every strategy, from exactly four IP addresses. Not four thousand. Four. That’s a small enough number that anyone running a self-hosted relay in front of PickMyTrade can lock the door and let only those four through.
Table of Contents
I run a small VPS-based bridge in front of my own PickMyTrade setup to fan alerts out to two funded accounts. Until I actually pulled up TradingView’s published IP list, I’d never bothered to restrict who could hit that bridge. It just sat there, wide open, trusting that nobody would find the URL.
This guide covers what those four IPs are, why PickMyTrade’s own endpoint can’t be firewalled the same way, and exactly how to build a TradingView webhook IP allowlist on whatever you’re running in front of it: NGINX, Cloudflare, AWS security groups, or a bare UFW firewall.
Key Takeaways
- TradingView sends webhooks from only 4 static IPs, all in AWS us-west-2.
- PickMyTrade’s endpoint is shared infrastructure secured by a per-account token, so you can’t add customer-side firewall rules there.
- Allowlisting belongs on infrastructure you control: a relay, proxy, or VPS in front of PickMyTrade.
- Treat it as one layer, not a replacement for token verification and HTTPS.
What Are TradingView’s 4 Webhook IP Addresses?
TradingView publishes exactly four source IPs for every webhook alert: 52.89.214.238, 34.212.75.30, 54.218.53.128, and 52.32.178.7, all routed out of AWS’s us-west-2 region in Oregon. Any incoming request claiming to be a TradingView alert but arriving from a different address isn’t one. Simple as that.
Three other constraints matter just as much as the IP list. TradingView only sends webhook requests to ports 80 and 443. Anything else gets rejected before it ever leaves TradingView’s side. It also cancels the request if your server takes longer than three seconds to respond, and it doesn’t support IPv6 destinations at all. Stack those three limits with the IP allowlist, and you’ve got a tight, predictable envelope for what a real alert actually looks like.
TradingView’s webhook infrastructure sends every alert from just four static IP addresses in AWS us-west-2. It accepts requests only on ports 80 and 443, and it cancels anything that takes longer than three seconds to respond. That combination gives you a firewall rule that’s both simple and precise, which is exactly what you want when real money sits on the other end of it.
For the exact JSON payload structure PickMyTrade expects behind that webhook, PickMyTrade’s JSON alert configuration guide is worth bookmarking alongside this one.
Why Can’t You Just Allowlist IPs Inside PickMyTrade?
PickMyTrade’s webhook endpoint (https://api.pickmytrade.trade/v2/add-trade-data) is shared, multi-tenant infrastructure. Every customer’s TradingView alerts land on the same URL, authenticated by a unique per-account token embedded in the JSON payload rather than by source IP. PickMyTrade can’t carve out a customer-specific firewall rule on a server that thousands of other traders’ alerts also hit.
That’s not a gap in the product. It’s how the token model is supposed to work. PickMyTrade generates a distinct token per account, checks it against every incoming payload, and rejects anything that doesn’t match, regardless of which IP the request came from. Isn’t that enough on its own? For traffic that goes straight from TradingView to PickMyTrade’s URL, mostly yes.
Where this actually applies: IP allowlisting is for anything you host in the path: a VPS-based relay, a custom fan-out script, or a reverse proxy sitting between TradingView and PickMyTrade (or between TradingView and your broker directly). Most PickMyTrade security guidance focuses on the token; almost none of it addresses the layer traders build for themselves.
If you paste TradingView’s webhook URL directly into your alert, and copy PickMyTrade’s URL straight back into it, with no relay and no proxy, there’s no server of yours in between to lock down. Your real security layer in that setup is the token, not an IP rule. Check PickMyTrade’s automated trading FAQ if you’re unsure which setup you’re actually running.
Where Should You Actually Put This Allowlist?
The allowlist belongs on whatever server first receives the raw TradingView request. That’s typically a VPS running a lightweight relay that forwards a modified or duplicated payload on to PickMyTrade. Traders who fan a single TradingView strategy out to two or three funded accounts, run extra risk checks before an order gets placed, or log every alert for later review are the ones with something worth firewalling.
This is common in the futures and prop-firm automation space, where traders already run a VPS for latency and uptime reasons and add a thin script in front of their broker or funded-account connections. If that sounds like your setup, PickMyTrade’s Tradovate automation and bot guide covers the broader infrastructure context, and the next section is exactly what you need.
If you’re not running anything of your own in the path, skip to the FAQ section below. You don’t need this: your protection already lives in PickMyTrade’s per-account token.
How Do You Configure the IP Allowlist?
Every major reverse proxy and cloud firewall supports IP-based access rules, and locking down all four TradingView addresses takes one config block on most platforms. Below are working examples for NGINX, Cloudflare, AWS Security Groups, and UFW. Pick whichever matches your relay’s hosting setup.
| Platform | Where the rule lives | What it needs |
|---|---|---|
| NGINX | Reverse proxy config file | allow/deny directives in a location block |
| Cloudflare | WAF → Custom rules (dashboard) | One expression using ip.src in {...} |
| AWS Security Group | EC2 console or CLI | Four /32 inbound rules on port 443 |
| UFW | VPS firewall (Ubuntu/Debian) | Four allow from rules plus a default-deny policy |
NGINX (reverse proxy in front of your relay or PickMyTrade forwarder). NGINX’s own IP access documentation covers the full directive reference:
# /etc/nginx/conf.d/tradingview-allowlist.conf
location /webhook {
allow 52.89.214.238;
allow 34.212.75.30;
allow 54.218.53.128;
allow 52.32.178.7;
deny all;
proxy_pass http://127.0.0.1:5000;
}Reload with sudo nginx -t && sudo systemctl reload nginx, then confirm the rule with a request from an IP outside the list. It should return 403 Forbidden.
Cloudflare (if your relay’s domain sits behind Cloudflare’s proxy): open Security → WAF → Custom rules and create a rule with this expression, action “Block.” Cloudflare’s allowlist walkthrough covers this exact use case in more depth:
(not ip.src in {52.89.214.238 34.212.75.30 54.218.53.128 52.32.178.7})AWS Security Group (if your VPS runs on EC2): add four inbound rules, one per IP, each scoped to a /32 CIDR on port 443. AWS’s security group rules guide has the console-based steps if you’d rather skip the CLI:
aws ec2 authorize-security-group-ingress \
--group-id sg-0123456789abcdef0 \
--protocol tcp --port 443 \
--cidr 52.89.214.238/32
# repeat for 34.212.75.30/32, 54.218.53.128/32, 52.32.178.7/32UFW (any Ubuntu or Debian VPS, including most low-cost prop-trading VPS providers). The Ubuntu community UFW guide is the standard reference if you want more than these four lines:
sudo ufw default deny incoming
sudo ufw allow from 52.89.214.238 to any port 443 proto tcp
sudo ufw allow from 34.212.75.30 to any port 443 proto tcp
sudo ufw allow from 54.218.53.128 to any port 443 proto tcp
sudo ufw allow from 52.32.178.7 to any port 443 proto tcp
sudo ufw allow ssh
sudo ufw enable
That allow ssh line matters more than it looks. I skipped it the first time I ran this on a fresh VPS, and locked myself out of my own box within about ninety seconds of enabling the firewall. It’s an easy mistake to make, and annoying enough that I’m mentioning it here so you don’t repeat it.
Whichever platform you use, verify the rule actually works before you trust it. Send a test webhook from TradingView first (its alert log shows delivery status), then try hitting the same URL from your laptop or a public HTTP-testing tool. The second request should get rejected. The first should go through.
What Should You Layer on Top of the IP Allowlist?
Security guidance across the webhook industry converges on the same point: an IP allowlist is a defense-in-depth measure, not a substitute for verifying that a request is cryptographically or token-authenticated. IP addresses can be spoofed at the network layer more easily than a signed token or an SSL client certificate can be forged. Treat the allowlist as one filter among several, not the whole wall.
For your PickMyTrade pipeline specifically, that means keeping four things active alongside the IP rule. First, PickMyTrade’s own per-account token check on every payload. Second, HTTPS on your relay’s endpoint: TradingView attaches an SSL client certificate to HTTPS webhook requests, and you can verify that certificate server-side. Third, 2FA on both your TradingView and PickMyTrade accounts. Fourth, basic rate limiting or logging on your relay, so a flood of requests, even from a spoofed IP, doesn’t overwhelm it silently.
In my experience, none of this is complicated to set up. Across the four platforms above, locking down all four IPs took me under ten minutes per server, with zero PickMyTrade downtime and no need to touch or regenerate a single TradingView alert. It’s one of those security tasks that’s easy to keep postponing, precisely because nothing visibly breaks while you put it off.
Missing or broken authentication remains the single most common root cause behind real-world API breaches. An IP allowlist narrows down who can even attempt a request in the first place. A verified token then decides whether that request is legitimate once it arrives. You need both, not either. One without the other leaves a gap wide enough to drive a bad trade through.
Ready to route your own alerts through a hardened setup? PickMyTrade’s pricing page lists current plans if you’re setting this up for the first time, and the token-based authentication described above ships on every tier.
Frequently Asked Questions
No. If your TradingView alert points directly at PickMyTrade’s webhook URL with no server of your own in the request path, there’s nothing for you to firewall. Your protection is PickMyTrade’s per-account authentication token, which it checks on every payload regardless of source IP.
TradingView maintains this list on its own Help Center page, and any change would need to be reflected in your firewall rules manually. Check TradingView’s webhook alert documentation every few months. A stale allowlist silently blocks legitimate alerts instead of failing loudly, which is worse than no allowlist at all.
No meaningfully measurable amount. A firewall or WAF IP check adds sub-millisecond overhead, which is trivial against TradingView’s three-second response timeout. The bigger latency factor in most PickMyTrade setups is network distance between your relay and PickMyTrade’s servers, not the allowlist rule itself.
No. Treat it as an additional layer, not a substitute. IP addresses can be spoofed more easily than a per-account token or an SSL client certificate, and security professionals consistently classify IP allowlisting as defense-in-depth rather than a standalone control.
No. Webhook alerts require a TradingView Pro, Pro+, or Premium subscription. Free accounts can’t send webhooks in the first place, so there’s no webhook attack surface to secure until you’re on a paid plan.
Conclusion
TradingView’s webhook traffic is more predictable than most integrations you’ll ever firewall: four static IPs, two ports, a three-second timeout. If you run any relay, proxy, or fan-out script in front of PickMyTrade, allowlisting those four addresses in NGINX, Cloudflare, your cloud security group, or plain UFW closes off the entire rest of the internet in a single config change.
Pair it with PickMyTrade’s built-in token authentication rather than instead of it, and you’ve covered both who can reach your relay and whether the request they send is actually legitimate. For the broader automation setup this fits into, PickMyTrade’s guide to extending your alert pipeline with custom tools and webhooks is a natural next read.
Disclaimer:
This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use.
Also Check-out: AI Sentiment Analysis for Trading: How AI Reads News
Connect your alerts with PickMyTrade — automated trade execution, no coding required. Start free →