TradingView webhooks to your broker API

Section 01 · How it fits together

Four pieces, one loop

The whole workflow runs on four tools that each do one job. TradingView decides when to trade. GitHub stores the receiver code. TradingHost runs that code in the cloud and hosts the webhook URL. The broker executes the order. Once you can name which tool does what, every other section here is a detail you can skim.

Section 02 · At a glance

At a glance

Section 03 · Write Pine Script with AI

Pair-write the strategy with Claude or ChatGPT

Pine Script is a small, well-documented language and the current generation of large language models have all read TradingView’s public Pine Script v6 reference. Describe the strategy in plain English in Claude or ChatGPT (or in Cursor with either model behind it): what to monitor, what triggers a long, what triggers a short, how to size the order, when to exit. Paste the generated code into TradingView’s Pine Editor and let the editor flag syntax issues.

Two things to be explicit about with the model. First, ask for a Pine Script strategy script (it must declare strategy() rather than indicator()), because only strategies expose the {{strategy.order.action}} and {{strategy.order.contracts}} placeholders you will need in the webhook body. Second, ask the model to fire its entries with strategy.entry() and exits with strategy.close(), and to write any ad-hoc notifications with the alert() function rather than alertcondition(); the modern alert() function exposes the same strategy placeholders and accepts a freq argument that controls whether the alert fires on every tick, once per bar, or once per bar close.

Read every line the model writes. Trading code is unforgiving of subtle bugs around order sizing, position state and intra-bar behaviour. Ask the model to explain any non-obvious calculation before you accept it. If you want a deeper AI-IDE flow (Pine plus a Python or Go receiver, both in one editor), the Cursor workflow page covers the IDE side of the same loop.

Section 04 · Backtest before going live

Run the Strategy Tester before you wire the webhook

TradingView’s Strategy Tester runs your Pine Script strategy across the chart’s available history, reporting net profit, profit factor, drawdown, win rate and a full list of synthetic trades. The Performance Summary, List of Trades and Properties tabs give you enough to decide whether the strategy is worth wiring up to a real broker.

Do this step before you create any TradingView alert with a webhook URL. A live webhook on an unvalidated strategy is the most expensive way to discover a bug.

Section 05 · Alerts and webhooks

Configure the TradingView alert and webhook URL

Open the Create Alert dialog on your chart, pick the strategy as the condition, then switch to the Notifications tab and tick Webhook URL. Paste the TradingHost webhook endpoint as the URL. The body you type into the Message field is what TradingView will POST to that URL when the alert fires.

Write the Message as JSON. TradingView detects valid JSON automatically and sets the request Content-Type to application/json, which is what your receiver expects. A minimal strategy alert body carries the ticker, the side (from {{strategy.order.action}}), the size (from {{strategy.order.contracts}}), and a shared secret that your receiver checks before forwarding anything to the broker.

Section 06 · Receive on TradingHost

Host the webhook URL on a runtime, not on your laptop

The webhook URL TradingView posts to has to be online whenever the market is open. A laptop is the wrong place for it; a desktop machine with a flaky internet connection is the wrong place for it; and a generic Windows VPS works, but only as long as you remember to keep it patched and the relevant terminal running.

TradingHost gives you a Kubernetes-backed Linux container that runs from a GitHub repo and exposes a stable HTTPS endpoint. Your receiver code is whatever you want (a Python FastAPI handler, a Node Express route, a Go net/http server), as long as it speaks HTTP on port 443 and responds inside TradingView’s three-second window. When you push code to GitHub, TradingHost rebuilds the container and redeploys; the webhook URL stays the same.

Broker API credentials live as encrypted secrets on the runtime, not inside your GitHub repo. The shared secret you put in the TradingView Message body lives there too. Your receiver validates the shared secret on every inbound request, then reads the broker credentials from the environment and calls the broker API.

Logs are streamed back so you can see, in order: TradingView posted, payload parsed, order submitted, broker confirmed. If anything fails, the log line says where.

Section 07 · Execute on the broker

Any broker with an API; the receiver shape does not change

TradingHost is broker-agnostic. The TradingHost container does not care which broker sits behind the REST endpoint it calls; the same receiver shape works whether the destination is a forex broker, a stock broker, a futures broker, or a crypto exchange. What differs is the authentication scheme, the instrument symbology, and the order-type vocabulary the broker exposes. Everything else stays the same.

Section 07.5 · Operational safety

Things that bite you when real money is on the line

TradingView alert delivery is best-effort. Webhooks can be dropped, repeated, or delayed. Broker APIs can return retries that look the same as a fresh order. Pine Script bugs can produce position sizes far outside the strategy’s intended risk. The receiver is where you put the seatbelt. Six guardrails below; each is a small piece of receiver code that prevents a failure mode the trader cannot fix once it has shipped.

Section 08 · Vs PineConnector + MT4/MT5

Why route a webhook through a cloud runtime instead of a MetaTrader EA

The most common existing path from a TradingView alert to a real order goes through PineConnector, a third-party bridge that forwards alerts to an Expert Advisor inside a MetaTrader 4 or MetaTrader 5 terminal. The EA submits the order through MetaTrader, so the terminal has to stay running on a Windows machine. TradingHost removes that leg entirely: the webhook lands on a container, the container calls the broker REST API, and there is no MetaTrader terminal, no MQL Expert Advisor, GitHub as the source of truth, and a Linux container running in a managed region rather than a Windows desktop you have to keep awake.