TradingView Webhook Automation

What a TradingView Webhook Sends

TradingView sends the alert message as an HTTP POST body to the configured URL. Valid JSON is sent with an application/json content type; other text uses text/plain. The receiver, not TradingView, decides what fields such as action, quantity or symbol mean. ^[S02]

Think of the webhook URL as the entrance to a specific execution route. Sending the same body to another service does not make the services interchangeable. One receiver may expect contracts, another lots, and another a cash amount. A syntactically valid message can still describe the wrong trade.

Before setup, collect three things from the intended receiver: its exact endpoint, its message specification and the account or route to which the endpoint belongs. Keep live and test destinations distinguishable. The comparison guide explains how these requirements differ between methods.

Webhook Requirements and Setup

TradingView's webhook documentation requires two-factor authentication, accepts ports 80 and 443, and states that IPv6 is not supported. It cancels a request when the remote server takes more than three seconds to respond. These are delivery requirements, not a promise that a broker fill occurs within three seconds. ^[S02]

Use the following setup sequence with a demo or paper execution destination:

1. Confirm that your TradingView account has access to webhook alerts and that two-factor authentication is enabled.
2. Create the destination route and confirm the selected account and market.
3. Choose the correct alert condition. A strategy order-fill message needs a strategy event; it is not interchangeable with a price alert.
4. Paste the receiver's URL and its supported message into the appropriate alert settings.
5. Trigger a controlled test and compare the TradingView alert record, receiver record and account result.

Do not diagnose a receiver by sending an arbitrary live buy command. A capture-only endpoint or a receiver's test function is a better first check. Keep passwords and brokerage credentials out of messages. Treat an execution URL as sensitive when possession of it can authorize instructions.

JSON Examples and Receiver-Specific Formats

Teaching payload: delivery inspection only

The following is an illustrative message for a capture-only test receiver. It is not a trading schema and must not be presented as a universal bot command.

{"event":"delivery_test","ticker":"{{ticker}}","chart_close":"{{close}}","sent_at":"{{timenow}}"}

After an alert fires, inspect the received body. The placeholder names should have become values in a compatible alert context. Check that the symbol is the intended chart symbol and that the timestamp describes this event, not an old copied message.

AlgoWay: a documented strategy message

AlgoWay's public pricing guide includes this basic MT5 message. It belongs on an appropriately configured AlgoWay route and uses strategy-order placeholders. ^[S18]

{"platform_name":"metatrader5","ticker":"{{ticker}}","order_action":"{{strategy.order.action}}","order_contracts":"{{strategy.order.contracts}}"}

The message does not establish that a TradingView quantity of one equals one broker lot. Confirm the destination's sizing settings with the MetaTrader guide and inspect a test fill. It also does not specify a protective stop; an entry example is not a complete risk-management configuration.

Platform-specific syntax

Keep a separate message template for each receiver. AlgoWay and TradersPost both document TradingView integration, but their field names are not identical: AlgoWay's example uses order_action and order_contracts; TradersPost's documentation uses action and quantity. Copying one into the other without translation is a schema change, not a connection change. ^{[S18] [S30]}

Do not add fields merely because another service accepts them. Extra properties may be ignored, rejected or interpreted differently. Work from the exact destination documentation and retain the payload that was actually delivered.

Placeholders, Quantities and Timestamps

TradingView's alert concepts distinguish script-generated dynamic messages from placeholders used in other alert contexts. In particular, alert() does not expand placeholders in its message string; dynamic values must be constructed by the script. ^[S29]

Choose numeric representation deliberately. Quoted placeholder values remain JSON strings after substitution. That is appropriate only when the receiver accepts strings for those fields. Never remove quotes mechanically: an empty value can make the whole message invalid.

Delivery Status, Timeouts and Resubmission

A delivery response belongs to the receiver connection. Read it alongside the receiver's application log. A successful response may mean “accepted for processing”; the subsequent account operation can still fail.

TradingView documents up to three resends, five seconds apart, for HTTP 500–599 responses except 504. That permits four deliveries of one trigger. It is not a general retry guarantee for every connection failure, and it says nothing about a service retrying a rejected broker order. ^[S03]

To investigate duplicates, compare payloads and event times first. Two deliveries of the same event require a different explanation from two separate strategy events. A timestamp by itself is not always a unique identity: a strategy can produce more than one legitimate event at the same time. The execution guide shows the records to compare.

Questions and Answers

Is there a universal trading webhook JSON format?

No. JSON supplies a data format, not standard trading semantics. Use the schema of the receiver attached to your route, including its quantity units and close-order rules.

Why is my JSON sent as plain text?

The delivered content may not be valid JSON. Check the final substituted body for missing values, smart quotes, trailing commas or unescaped quotation marks. Inspect the actual body rather than only the template.

Does TradingView retry failed webhooks?

It documents a limited HTTP-error resubmission policy, described above. Do not assume every missed request will return or that the receiving service has the same retry policy.

Can I paste strategy placeholders into an indicator alert?

Strategy-order placeholders require the appropriate strategy event. An indicator does not gain a strategy order history by containing a placeholder. Review alert types before choosing the message.