TradingView to Broker Automation: The Complete End-to-End Guide
TradingView to broker automation explained end to end: alerts, webhooks, the bridge with risk rules, broker API, order types, testing in simulation and a pre-live checklist.
TradingView to broker automation sounds like one step, but it is really a chain of five or six, and every link can fail on its own. A chart condition fires, a message leaves TradingView, something receives and checks it, a broker API accepts an order, and only then does a position appear in your account. This guide walks the chain and marks the decision at each stage. For the concept of a webhook read automating TradingView alerts with webhooks, and for the product steps read how to connect TradingView alerts with WeCore.
The architecture in one picture
Think of five components, left to right:
- Signal source. A strategy or indicator running on a TradingView chart.
- Alert. TradingView's alert engine, which decides when to send and what text to send.
- Webhook. An HTTPS request from TradingView's servers to an address you chose.
- Bridge. Software that receives the message, validates it, applies your risk rules, resolves the contract and sizes the order.
- Broker API and account. The interface through which the order reaches your broker or prop-firm account, where the fill actually happens.
TradingView only covers steps 1 to 3. Everything that protects your account lives in steps 4 and 5. WeCore is one such bridge: it is software, not a broker, it never holds your money, and orders are placed in your own account.
Decision 1: indicator alert or strategy alert
| Indicator or condition alert | Strategy alert | |
|---|---|---|
| Fires when | A condition on the chart is met | The strategy engine generates an order |
| Message content | Whatever text you type, or an alert message from Pine code | Can use order placeholders such as `{{strategy.order.action}}` and `{{strategy.order.contracts}}` |
| Position awareness | None, the alert does not know your position | Knows `{{strategy.market_position}}` and `{{strategy.position_size}}` |
| Typical risk | Duplicate or missing signals if you do not design exits | Behavior differs from the backtest if settings differ |
According to TradingView's strategy alert documentation, strategy alerts fire only for real-time orders, not for historical bars, and they run on TradingView's servers from a copy of the strategy. That has a practical consequence: if you edit the strategy on your chart, an alert that is already running does not change. Delete the alert and create it again. TradingView also stops a strategy alert that triggers more than 15 times within 3 minutes, so a strategy that flips constantly will be switched off by the platform rather than by you.
What TradingView requires
Before you design anything, confirm these points on TradingView's own pages (read on 11 October 2026):
- Webhooks require two-factor authentication on your TradingView account.
- Only ports 80 and 443 are accepted for the URL.
- A request that takes longer than 3 seconds is cancelled, so the receiver must answer fast and do slow work afterwards.
- IPv6 is not supported.
- TradingView notes that webhooks may occasionally fail to reach the URL, so treat delivery as best effort.
- A valid JSON message is sent as application/json, anything else as text/plain.
- TradingView publishes a list of source IP addresses that can be allowlisted on the receiving side.
- Standard alerts expire (the maximum is two months), while Premium and Ultimate allow open-ended alerts. An expired alert simply stops sending.
The delivery status of each webhook is visible in the alert log, the first place to look when nothing arrives.
Decision 2: message design
The message is the contract between TradingView and your bridge. Good messages are explicit and boring.
What a message should carry
For WeCore the alert message is JSON with these fields: `ticker` (or `symbol`), `action` (buy, sell, exit, add, cancel, breakeven or protect), `quantity`, `orderType`, `limitPrice`, and optionally `stopLoss` and `takeProfit` objects with the distance in points. Other bridges use other field names, so always copy the template from the documentation of the one you use.
Two habits help. Make intent explicit: an exit should say it is an exit, not be inferred from "sell" and a position size you assume. And open the alert log, read the message that was actually sent, and compare it field by field with what the bridge recorded. Use placeholders for values that change and constants for the rest.
Decision 3: symbols and contracts
Futures have expiry months. A TradingView continuous symbol such as NQ1! tracks the front contract, but a broker trades a dated contract. Either the bridge translates, or you maintain the alert yourself. WeCore accepts continuous tickers such as MNQ1!, MES1!, MGC1!, NQ1!, ES1! and GC1!, and resolves them to the front month automatically, which spares you an alert update at each roll. See futures contract rollover.
The error that no bridge can fix for you is mini versus micro. NQ and MNQ, or ES and MES, differ by a factor of ten in value per point. Read micro vs mini futures and then write the symbol deliberately; a "ten times too large" position usually traces back to one letter.
Decision 4: order types, stops and exits
Market orders are the simplest and the most exposed to slippage, especially when the message crosses the internet and waits in a queue. A limit order with an explicit price caps the price you accept, at the cost of sometimes not being filled. WeCore recommends limit orders for this reason, and a limit order needs `limitPrice` in the message.
For protection, decide where the stop lives:
- In the message, as `stopLoss` and `takeProfit` distances in points, so the protective orders go out with the entry.
- As a default on the bridge, set per strategy, with the alert allowed or not allowed to override it.
- In your head only. This is the option to avoid, because an automated entry without a stop is a position nobody is watching.
Stop distances are converted to broker ticks only for known futures contracts. For an unknown symbol a careful bridge attaches nothing rather than guessing, so test that your stop really appears at the broker. Exits (close, cancel) should always pass through, even when a risk block would stop a new entry. More on this in risk management for algo traders and position sizing methods.
The risk layer
The bridge is where you write the rules that no chart script will enforce. At a minimum:
- Maximum daily loss and, where the platform supports it, an automatic close when it is hit.
- Maximum position size per order, maximum open positions and an allowed-symbol list.
- Trading-hour restrictions that match your sessions (see futures trading sessions).
In WeCore these are set per account under Risk, and live trading cannot be switched on until they have been saved at least once. On prop accounts keep them inside the firm's own limits; see daily loss limits explained.
Testing in simulation
Every WeCore broker account starts in Simulation: signals are received, checked and recorded, but nothing is sent to the broker. Rehearse the whole chain. Over several trading days, confirm:
- Every alert that fired in TradingView has a matching recorded signal.
- Action, direction and quantity match the message.
- The contract resolved to the month you expect.
- The risk rules blocked what you expected them to block, and said why.
Simulation tests plumbing and rules, not real fills or latency, so the first live days should still use the smallest size. See backtesting vs live trading.
Monitoring and failure modes
Automation fails quietly, so list the failures before they happen.
| Failure | What you see | Where to look |
|---|---|---|
| Alert expired or stopped | No signals at all | TradingView alert list and alert log |
| Webhook not delivered | Alert fired, nothing at the bridge | Alert log delivery status, URL, 2FA |
| Duplicate message | Two orders for one idea | Trigger frequency, two alerts on one chart |
| Rejected by risk rules | Signal recorded, no order | Bridge activity log reason |
| Broker disconnected | Orders not acknowledged | Broker connection status |
| Wrong size or product | Position ten times off | Mini versus micro in the message |
| Leaked webhook URL | Orders you did not send | Regenerate the URL, update every alert |
Set notifications on a channel you read, and check the connection status each session. Rithmic allows one active login per username, so a second platform using the same credentials can disconnect the bridge.
Prop-firm policy check
Being able to connect an account is not permission to automate it. Policies differ widely and change, so read the firm's own page for the account stage you hold, including rules on remote servers and high-frequency trading. The sourced comparison is in prop firms that allow automation, and the broader rule structure in Apex, Topstep and Lucid rules overview. If unclear, ask the firm in writing.
Pre-live checklist
| Check | Done when |
|---|---|
| TradingView prerequisites | 2FA on, plan supports webhooks, alert not near expiry |
| Alert type chosen | Indicator or strategy alert chosen on purpose, recreated after any edit |
| Message | Valid JSON, explicit action, correct symbol and size, reviewed in the alert log |
| Webhook URL | Secret, stored safely, IP allowlist considered |
| Order type | Limit with a price, or market chosen knowingly |
| Stop and target | Confirmed to appear at the broker in a test |
| Risk rules | Saved: daily loss, size, positions, symbols, hours |
| Simulation | Several days, every alert matched to a signal |
| Monitoring | Notifications on, connection checked each session |
| Prop-firm policy | Read for your account stage, written answer saved |
Where to go from here
If you want a ready-made starting point instead of writing your own strategy, look at WeAlgo ready-made strategies, which run on your own trading server with your own broker data. If you prefer to connect your own TradingView alerts, you can view the plans and pricing or create an account and run a first alert in Simulation. A 7-day trial starts with a $5 (refunded immediately) card verification, and nothing goes live until you save risk rules and switch Simulation off yourself.
FAQ
Can TradingView send orders directly to a broker?
TradingView alerts send a message to a web address; they do not place orders by themselves. Some brokers integrate with TradingView directly for manual trading, but alert-driven automation normally needs a bridge between the webhook and the broker's API.
Do I need a paid TradingView plan for webhooks?
TradingView's help center says webhooks require two-factor authentication on the account, and webhook availability depends on your plan. Check TradingView's current pricing and alert pages before you build.
Why did my alert fire but no order appear?
Check the delivery status in the TradingView alert log first, then the bridge's activity log. Common causes are a risk rule that blocked the order, an account still in Simulation, a broker disconnection or a malformed message.
Should I use market or limit orders?
A limit order caps the price you accept but may not fill; a market order fills but can slip. WeCore recommends limit orders with an explicit price. Choose deliberately and test how your orders fill in the first live sessions.
Is automating a prop-firm account allowed?
It depends on the firm and the account stage. Some firms prohibit automation, others allow it with conditions. Read the firm's official page and ask support in writing before you automate.
This article is general information, not investment advice, and does not promise any result. TradingView requirements were read on its help pages on 11 October 2026 and may change. Futures trading carries a high risk of loss.