Webhook Trading Security: Protecting Your URL and Account

Webhook trading security comes down to one idea: the address your alerts post to is, in practice, a password. Anyone who holds it and knows the message format can ask your automation to act. This article covers how to treat the webhook URL as a secret, what TradingView itself says about security and delivery limits, what a leaked URL could do, how to restrict and monitor access, and a table of the mistakes that cause most problems.

It assumes you already know the basics of alert-driven automation. If not, start with Automating TradingView Alerts with Webhooks, then come back.

Why the URL is the weak point

In a typical setup, TradingView sends an HTTP POST to a URL when an alert fires. The receiving service cannot tell, from the URL alone, whether the request came from your TradingView account or from someone who found the address. In WeCore, each strategy subscription has its own private webhook URL, shown in the dashboard, and the documentation is direct about it: never share it publicly, because anyone who has it can send orders.

Several things sit behind that URL even so. In WeCore, an incoming alert goes through a rate limit, an optional IP allowlist, a plan and strategy check, contract resolution, a one-position-per-symbol rule, sizing and risk checks, and only then to the broker. Those layers reduce the damage a stray message can do, but they are not a reason to relax about the URL.

Treat the URL as a secret

Practical habits:

• Never paste the URL into screenshots, forum posts, chat groups, support tickets in public channels or shared documents.
• Do not store it in a spreadsheet that is shared with others. Use a password manager or a private note.
• When you screen-share or record a tutorial, hide the alert dialog's Webhook URL field.
• Use a separate URL for each strategy so that a leak affects one strategy, not everything.

If it leaks, regenerate it

If you think the URL has been exposed, regenerate it. In WeCore, open the strategy and use Regenerate; the old URL stops working immediately. The consequence is that every TradingView alert using the old address must be edited to use the new one, so keep a short list of which alerts point where. Regenerating is cheap; leaving a possibly exposed URL active is not.

What TradingView says about security

TradingView's help page on webhooks (read 11 October 2026) sets out several conditions that have security and reliability effects:

• Two-factor authentication must be enabled on your TradingView account to use webhooks.
• Only ports 80 and 443 are accepted for the webhook URL, and IPv6 is not supported.
• A request that takes longer than three seconds is cancelled.
• Webhooks may occasionally fail to reach the URL.
• TradingView advises against putting credentials in the message body, because the message travels as the body of an ordinary web request.

That last point deserves emphasis. The alert message should describe the trade instruction, not your identity. Do not put broker passwords, API keys or account logins in it. A well-designed receiver identifies you by the private URL (and optionally by source IP), not by secrets typed into messages. WeCore, for example, needs no TradingView username in the alert.

Turn on 2FA for TradingView itself

Because the alert is created and edited inside your TradingView account, someone who takes over that account can create alerts or read the URLs stored in them. Two-factor authentication is required for webhooks anyway; use an authenticator app, keep your recovery codes offline, and use a unique password.

IP allowlisting

TradingView publishes the IP addresses its webhook requests come from, and its help page lists four: 52.89.214.238, 34.212.75.30, 54.218.53.128 and 52.32.178.7 (checked 11 October 2026). If your receiver supports an allowlist, restricting it to these addresses means a request from anywhere else is refused even if the URL leaks.

In WeCore the webhook has an optional IP allowlist with choices such as everything or TradingView's official IPs. Some caveats:

• An allowlist is a second lock, not a replacement for keeping the URL secret. Anyone able to make TradingView send a request, for example from their own TradingView account, would originate from an allowed address.
• A custom list that omits a current address can block your own alerts. If alerts suddenly stop after changing the list, revert it first, then compare with TradingView's current published addresses, which can change over time.
• Check the page again from time to time rather than assuming the list is permanent.

What a leaked URL could do

Nothing here is a prediction of what will happen; it is a way to think about worst cases so you can limit them.

• It could submit orders in the strategy's name: buys, sells, adds, exits, cancels.
• It could submit them in bursts, which is why rate limits and one-position-per-symbol rules matter.
• It could close a position you wanted to keep, because exit actions are intended to pass risk blocks.
• It cannot withdraw money. WeCore is a bridge, not a broker, and never holds funds. Orders go only to the connected trading account.

The practical protections are the ones you control: account-level risk limits (see how to set risk limits in WeCore and risk management for algo traders), a daily loss limit, a kill switch, small default size, and Simulation mode while you test. Exits always being allowed is a feature, not a flaw, but it means a stray exit can flatten a position.

Duplicates, retries and timing

Security and reliability overlap, because a duplicate is just an unwanted instruction.

Duplicate alerts

Two alerts on the same chart, an alert set to fire on every tick, or a Pine script calling `alert()` several times in a bar can all produce repeated messages. Pine's `alert()` frequency options are `alert.freq_once_per_bar`, `alert.freq_once_per_bar_close` and `alert.freq_all`; the last allows every call within a bar to fire. Pick the narrowest option your logic needs. A receiver rule such as one open position per symbol is a safety net, not a design.

Retries and the three-second limit

Because TradingView cancels requests that take longer than three seconds and warns that webhooks can occasionally fail to arrive, you should not build a system that assumes every message arrives exactly once. If a request is cancelled you may see a failure in TradingView's alert log while the receiver may or may not have acted. Check the app's signals and positions, not just the alert log, before re-sending anything by hand. Manually re-firing an alert that did arrive creates the duplicate you were trying to avoid.

Rate limits and the 15-in-3-minutes rule

Strategy alerts on TradingView stop triggering if they fire more than 15 times in 3 minutes. On the receiving side WeCore refuses more than 120 alerts per minute per webhook. Hitting either limit usually means a logic loop, such as a strategy flipping repeatedly, and is worth investigating rather than working around.

Monitoring

Security without monitoring is guesswork. A short routine helps:

1. Look at TradingView's alert log, which shows the delivery status of webhook requests.
2. Look at the Signals list in the WeCore app after each new alert type.
3. Turn on trade notifications (email or Telegram) so an unexpected order is noticed quickly.
4. Review open positions and orders at the start and end of the session.
5. Review which alerts exist. Expired standard alerts stop silently after a maximum of two months, according to TradingView, and stale alerts you no longer remember are a risk of their own.

For troubleshooting a quiet alert, see TradingView alert not firing.

Common mistakes

A short hardening checklist

1. Private URL stored in a password manager.
2. One URL per strategy; regenerate on any doubt.
3. 2FA on TradingView.
4. IP allowlist set to TradingView's official addresses, reviewed periodically.
5. No credentials in any message.
6. Risk limits and kill switch saved before live trading.
7. Alerts audited monthly.

If you want to see how this looks in practice, create a WeCore account and walk through a Simulation strategy; the plans page lists the options and the 7-day trial. You can also look at WeAlgo ready-made strategies, which run on your own trading server. For a step-by-step setup, see how to connect TradingView alerts to WeCore.

FAQ

Is a webhook URL really as sensitive as a password?

Practically yes. Whoever knows the URL and the message format can submit instructions to your automation. Keep it private and regenerate it if it might have been exposed.

What should I do first if I leaked my webhook URL?

Regenerate it in the strategy settings so the old address stops working, then update each TradingView alert with the new URL. Afterwards check recent signals and open positions for anything unexpected.

Which IP addresses does TradingView send webhooks from?

TradingView's webhook help page lists 52.89.214.238, 34.212.75.30, 54.218.53.128 and 52.32.178.7 (checked 11 October 2026). Verify the current list on TradingView's page before relying on it.

Can I put my broker login in the alert message?

No. TradingView advises against credentials in the message body, and a correctly designed receiver does not need them. WeCore identifies the strategy through its private URL.

Why did my webhook alert show as sent but nothing happened?

TradingView cancels requests over three seconds and notes that webhooks can occasionally fail to arrive. Check the signals and the allowlist, then see the troubleshooting article before re-firing.

This article is general information, not investment advice. It makes no promise of results, and futures trading carries a high risk of loss. Check your broker's and prop firm's current rules before automating.