TradingView Webhook Setup: Complete Walkthrough

By Stax Team

Setting up a TradingView webhook takes four steps: confirm your plan supports webhook alerts and enable two-factor authentication, prepare a publicly reachable HTTPS endpoint on port 80 or 443, create an alert with the webhook URL and a message body that is valid JSON, then test it against a request inspector before pointing it at anything that trades. Most failed setups trace to one of three causes: a plan without webhook support, a message body that is not valid JSON, or an endpoint that is not reachable from the public internet.

Step 1: Confirm your plan and enable 2FA

Webhook alerts require a paid TradingView plan. The free Basic plan cannot fire them at all — it supports on-screen and email notifications only, and this is the single most common reason a new setup silently does nothing.

Which paid tier is the entry point is reported inconsistently across third-party guides, and TradingView has restructured its tiers more than once. Some sources place webhooks at the lowest paid tier, others a step above. Rather than repeat a number that may be wrong for your account, check TradingView's own pricing page for the current tier that lists webhook support. If you are already on a paid plan and the webhook field is greyed out or absent in the alert dialog, that is your answer.

Two-factor authentication on your TradingView account is also required for webhook alerts. Enable it before you start rather than discovering it mid-setup.

Step 2: Prepare the receiving endpoint

TradingView needs somewhere to send the request, and its constraints are narrow.

Port 80 or 443 only. A service on any other port is unreachable. This catches people running an endpoint on a development port.

IPv4 only. No IPv6 support.

Three-second timeout. Your endpoint must respond inside that window. If your handler authenticates to a broker, constructs an order, submits it, and waits for confirmation before responding, you will exceed it. Acknowledge the request immediately and do the work asynchronously — accept, return 200, then process.

Publicly reachable. Not localhost, not a private network address. During development a tunnelling service works; in production it needs a real host.

On a self-hosted deployment the endpoint runs in your own cloud, which means the network policy and the uptime are both yours. These constraints are why the receiving endpoint is the part of the stack that actually needs engineering. In a Node client, responding fast while doing real work behind the response is a straightforward high-concurrency I/O pattern, and it is the difference between a webhook that works and one that times out under load.

Step 3: Create the alert

Open the alert dialog from the chart, from an indicator, or from a strategy.

Set the condition. A price level, an indicator condition, or a strategy's order events. Strategy alerts fire on the strategy's own entries and exits, which is what you want for full automation.

Choose the trigger frequency deliberately. Once per bar close is the safe default for automation, because once-per-bar can fire intrabar on a condition that later becomes false — a repainting signal that sends an order for a setup that did not actually complete.

Set the expiry. Alerts expire by default on most tiers, historically around two months, after which they stop firing silently. Non-expiring alerts are a higher-tier feature. Put a recurring reminder in your calendar to recreate them, because an expired alert produces exactly the same symptom as a broken endpoint: nothing happens.

Enable the webhook. Under notifications, tick the webhook option and paste your endpoint URL.

Write the message body. This is the payload. Make it valid JSON — TradingView sends an application/json content type only when the message parses as valid JSON, and otherwise sends text/plain, which most trading endpoints reject outright. A single trailing comma or unquoted key silently changes the content type and your endpoint returns an error you never see.

Step 4: Test before it can trade

Point the alert at a request inspector first — a service that captures and displays incoming HTTP requests. Fire the alert manually and read what actually arrived.

Check three things: that the request arrived at all, that the content type is application/json rather than text/plain, and that every placeholder resolved to a real value rather than appearing literally in the body.

Only after that is confirmed should the URL point at anything connected to a broker. And when it does, keep the first live tests small enough that a completely wrong order is affordable.

When it does not fire

Nothing arrives at all. In order of likelihood: plan does not support webhooks, 2FA not enabled, endpoint not publicly reachable, wrong port, alert expired, or the alert condition simply has not been met. Check the alert log in TradingView to distinguish did not fire from fired and was not received.

Arrives but is rejected. Almost always the message body is not valid JSON, so the content type is text/plain.

Arrives intermittently. Your endpoint is exceeding the three-second timeout under load, or returning non-2xx. Remember there is no retry — every one of those is a lost signal.

Placeholders appear literally. A typo in the placeholder name, or a strategy placeholder used in an alert that is not a strategy alert.

Fires more often than expected. Trigger frequency, or an intrabar condition that resolves differently by bar close.

The honest limits

A working webhook is a delivery mechanism, not a trading system. It sends one request and forgets it.

The lack of retry means signal loss is a permanent property of this design, not a bug you can configure away. Any strategy where a missed exit is unacceptable needs exits resting at the broker rather than depending on a future webhook arriving.

TradingView does not sign its requests, so a URL that reaches your endpoint is the only credential involved unless you add one yourself in the payload.

And correct setup has no bearing on whether the strategy works. Position sizing is what bounds loss — available trading capital divided by twenty as the ceiling on any single position, under the divide-by-20 rule. It constrains outcomes rather than predicting them.

Frequently asked questions

Do I need a paid TradingView plan for webhooks? Yes. The free Basic plan cannot send webhooks. Check TradingView's pricing page for the current entry tier, as third-party guides disagree and the tiers have been restructured.

Why is my webhook not firing? Most often the plan does not support webhooks, 2FA is not enabled, the endpoint is not publicly reachable on port 80 or 443, or the alert has expired.

Does my webhook message need to be JSON? Practically, yes. TradingView sends an application/json content type only when the message parses as valid JSON; otherwise it sends text/plain, which most endpoints reject.

Do TradingView alerts expire? On most tiers, yes — historically around two months. They stop firing silently. Non-expiring alerts are a higher-tier feature.

Can I test a webhook without a broker connected? Yes, and you should. Point it at a request inspector and confirm the payload before connecting anything that trades.


Disclaimer: This article is educational content about software engineering and trading automation. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security. Any instruments named are used solely to illustrate mechanics. Options trading involves substantial risk of loss and is not suitable for all investors. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading systems carry additional risks including software defects, missed or duplicated signals, network and connectivity failures, third-party service changes and outages, and unintended order behaviour that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no configuration, alert setup, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.

StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, their compliance with third-party terms of service, and every trade executed in their account. Third-party platform details described here reflect publicly available documentation as of publication and are subject to change without notice; always verify against current official documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.