TradingView Alerts and Webhooks: A Complete Setup Guide for Automated Trade Workflows

Overview

A TradingView webhook is an HTTP request sent when an alert is triggered. The receiving application may be a custom server, broker integration, trade automation platform, or trading bot. TradingView remains the signal source; the receiving system decides how to authenticate, validate, interpret, and execute the message.

That separation is important. An alert is not automatically a complete trading strategy, and a webhook is not a guarantee that an order will be accepted. Network delays, invalid symbols, exchange restrictions, insufficient buying power, duplicate messages, market closures, and application errors can all interrupt the workflow. Treat the system as a chain with several independent checkpoints:

1. Signal logic: the indicator or Pine Script condition identifies an event.
2. Alert configuration: TradingView evaluates the condition at the selected frequency.
3. Message delivery: the webhook request reaches the destination.
4. Validation: the receiving application checks the message and authorization.
5. Order handling: the broker or bot converts the instruction into an order.
6. Monitoring: logs and notifications confirm what happened.

Before building automation, define the intended behavior in plain language. For example: “When the confirmed bar closes above the moving average, send one long-entry signal; risk no more than the predetermined account fraction; reject the signal if an open position already exists.” This specification is easier to test than a vague goal such as “automate my strategy.” For background on systematic testing, see the TradingView paper trading guide.

What to track

Alert conditions and timing

Record the exact script, symbol, exchange, timeframe, and alert condition used. A crossover can behave differently depending on whether it is evaluated intrabar or only after a candle closes. For many rule-based systems, confirming signals at bar close reduces the risk of acting on a condition that disappears before the candle is complete. It can also make execution later than an intrabar approach, so the choice should match the strategy and be documented.

Track the alert frequency as well. A condition that can trigger every time it remains true is materially different from one that triggers once per bar or once per bar close. Review whether the alert can fire repeatedly while a position is open. If the strategy requires one entry per setup, that restriction should exist in the strategy logic or receiving system rather than being assumed.

Message structure

Use a consistent, machine-readable format. A JSON message might include an event identifier, action, symbol, timeframe, signal timestamp, strategy name, and risk instructions. A generic structure could look like this:

{"event_id":"unique-signal-id","action":"buy","symbol":"EXAMPLE","timeframe":"60","signal_time":"{{time}}","strategy":"trend-entry","risk_mode":"fixed-size"}

Use TradingView placeholders only where the selected alert context supports them, and confirm the resulting message by inspecting a test request. Do not assume that a placeholder represents an exchange-specific symbol, a broker symbol, or a fully calculated position size. The receiving application should validate required fields, reject unknown actions, and handle missing or malformed values safely.

Risk and position data

Decide where position sizing occurs. A Pine Script strategy may calculate a theoretical quantity, while the execution service may calculate size from account equity, stop distance, and a risk limit. Mixing both approaches can cause unintended exposure. If size is calculated downstream, send the intended stop distance or a strategy reference rather than an unchecked quantity.

For a volatility-based process, document the relationship between stop distance and share or contract size. The ATR position sizing guide provides a useful framework for keeping those decisions separate from the alert transport layer.

Delivery and execution health

Maintain a simple log containing the alert time, event ID, delivery status, response status, parsed action, broker order ID, fill status, and error message. Track missing alerts as well as rejected orders. A system that reports only successful trades can hide silent failures.

Cadence and checkpoints

A reliable TradingView webhook setup benefits from scheduled reviews rather than attention only after a loss. Use the following cadence as a starting point and adjust it to the strategy’s activity level.

Before every deployment

• Confirm the chart symbol, timeframe, exchange, and script version.
• Verify whether signals require bar-close confirmation.
• Send a test alert with a harmless action, such as a paper-trading event.
• Check that the endpoint receives valid JSON and returns an expected response.
• Confirm that duplicate event IDs are rejected or safely ignored.
• Verify position limits, maximum order size, and an emergency disable procedure.

Weekly or after a meaningful strategy change

Compare the TradingView alert log with the receiving system’s log. Investigate alerts that have no corresponding application entry, messages that were parsed differently than expected, and orders that differ from the signal. Review recent changes to Pine Script, alert settings, broker mappings, and symbol conventions. A script edit may not automatically change an existing alert, so confirm the alert is attached to the intended version using the platform’s current interface.

Monthly or quarterly

Review the full workflow as an operational system. Test a disabled or paper environment, rotate credentials according to your security process, check access logs, confirm error notifications still work, and remove unused endpoints. Reconcile the strategy’s intended position with the broker’s actual position. Also review slippage, rejected orders, duplicate signals, and periods when the market or data feed was unavailable.

How to interpret changes

When live results differ from a backtest, do not immediately change the entry rules. First classify the difference. It may come from signal timing, unavailable historical assumptions, spread or slippage, partial fills, contract specifications, position-sizing rules, or a message-processing error.

A useful diagnostic sequence is:

1. Signal check: Did the condition occur on the intended bar and timeframe?
2. Transport check: Was a request sent, received, and acknowledged?
3. Parsing check: Did the application interpret the action, symbol, and quantity correctly?
4. Risk check: Did safeguards reduce, reject, or alter the requested order?
5. Execution check: Was the order accepted, filled, partially filled, or canceled?
6. Reconciliation check: Does the actual position match the system’s recorded position?

Repeated alerts may indicate an overly broad condition, an unsuitable alert frequency, a script that recalculates intrabar, or a receiver that does not enforce idempotency. Missing alerts may indicate a disabled alert, an expired configuration, a changed script, a delivery problem, or a condition that never became confirmed. Treat each explanation as a hypothesis and use timestamps and logs to test it.

Security changes deserve the same attention as trading changes. Keep webhook credentials and API keys out of Pine Script, chart screenshots, public code, and alert messages where possible. Use an HTTPS endpoint, validate an authentication token or signature, restrict permitted actions, and avoid allowing an incoming message to specify arbitrary account or order parameters. If a secret is exposed, replace it promptly and review recent requests.

When to revisit

Revisit this setup monthly or quarterly, and immediately after any change to the Pine Script, alert condition, timeframe, broker connection, symbol mapping, webhook server, or risk model. Platform interfaces and integration requirements can change, so verify the current alert labels, supported placeholders, and receiving service documentation before relying on an old checklist.

Use a written change record with five fields: what changed, why it changed, which environment was tested, what result was expected, and who approved live activation. Keep paper trading enabled while validating changes. A practical rollout is to begin with alerts only, then paper execution, then a small and predefined live allocation, with a manual kill switch available at every stage. The risk-reward and position-sizing guide can help formalize the limits used in that rollout.

Before going live, run at least one complete test from signal creation through position reconciliation. Confirm that a rejected order creates an actionable notification, that a repeated event does not create a second position, and that the system stops safely when the endpoint or broker is unavailable. Automation should reduce avoidable manual steps without removing oversight. Rechecking the workflow on a regular schedule keeps the trading bot aligned with the strategy it is meant to execute.