Open any alert on TradingView, scroll to the notifications tab, and there is a checkbox called Webhook URL. Tick it, paste an address, and every time that alert triggers TradingView sends an HTTP POST to the address with the alert message as the request body. That is the whole feature. No authentication headers, no retry policy you control, no response handling. A single POST, fired once, to a URL you supplied.
Everything people build on top of it, signal relays into Telegram, order routers, journaling systems, portfolio dashboards, is a service sitting at the other end of that POST deciding what the message means.
The message is the contract
The alert message field is plain text, and Pine placeholders inside it are substituted at fire time. Send free prose and your receiver has to parse English. Send JSON and it has a structured object to work with. The second approach is the one that survives contact with a live account.
A workable payload names the instrument, the side, the price the alert saw, the timeframe and a shared secret. Common placeholders you can drop into the message include:
{{ticker}}for the symbol and{{exchange}}for the venue{{close}},{{open}},{{high}},{{low}}for the bar values at trigger{{interval}}for the chart timeframe{{time}}and{{timenow}}for the bar time and the fire time in UTC{{strategy.order.action}}and the related strategy fields when the alert comes from a strategy rather than an indicator
If the alert is fired from Pine with alert() rather than alertcondition(), the message is built in code, which means the script can assemble the JSON itself and include values the placeholder list does not expose. That is the pattern almost every serious setup ends up using, and it is worth learning the basics of Pine Script for that reason alone.
Settings that decide whether it fires at all
Two options cause most of the confusion. The trigger frequency, Once Per Bar versus Once Per Bar Close, determines whether the alert fires the instant the condition becomes true intrabar or waits for the candle to complete. Intrabar firing is faster and repaints: a condition true at minute three of a fifteen minute bar can be false by the close, and your receiver has already acted. For anything that places an order, use bar close unless you have a specific reason not to.
The second is that an alert is bound to the version of the script it was created from. Edit the indicator, republish it, and the running alert keeps executing the old logic silently. There is no warning. Delete and recreate the alert after every meaningful script change, then verify the first delivery actually lands. The rest of the alert dialog is covered in our walkthrough of setting up TradingView alerts.
TradingView sends the POST once and does not guarantee delivery. If your endpoint is down, slow to respond or returns an error, the alert is gone. Any system where a missed message leaves an unbalanced position needs its own reconciliation against the broker, not blind trust in the webhook.
Your URL is your password
The endpoint has to be publicly reachable over HTTPS, which means anyone who learns the address can post to it. Treat the URL as a credential: long random path, never pasted into a screenshot, never shared in a support chat. Then add a shared secret inside the JSON body and reject any request without it.
Two more controls are worth the hour they take. Restrict inbound traffic to the source addresses TradingView publishes for alert delivery, and make the handler idempotent so a duplicate message with the same bar time and symbol does not open a second position. Duplicate protection matters more than people expect, because a chart left open in two browsers with two copies of the same alert is a mistake everybody makes once. The wider set of failure modes sits in webhook automation safety.
Relaying is easier than executing
There is a large gap between a webhook that posts a message into a Telegram channel and one that sends orders to a live account. The relay case is forgiving: a delayed message is a slightly late notification. The execution case has to handle position sizing, existing exposure, partial fills, rejected orders, symbol name differences between TradingView and your broker, and what to do when the account is already at its risk limit.
Most retail setups underestimate the third of those. TradingView's XAUUSD is not necessarily your broker's symbol string, and an order router that cannot map instruments will fail at the worst moment. Signal services solve it by keeping a human in the loop: the engine fires an alert, the webhook relays entry, stop and target to subscribers, and each trader executes on their own platform with their own sizing. That is how GoldAlgo distributes its gold setups, and it is a deliberately simpler architecture than automated order placement.
What to test before you trust it
Fire the alert manually against a logging endpoint and read the raw body. Confirm the JSON parses, the numbers are the ones you expect, and the timestamps are UTC. Then run it for a week without any action attached, comparing every delivered message against the chart. Alerts that never arrive, arrive twice, or arrive with the previous bar's price are all common, and you want to find them while nothing is at stake. Automation removes the delay between a signal and an order. It does not make the signal correct, and leveraged trading remains high risk whether a human or a script presses the button.
"A webhook is a doorbell, not a doorman. If you have not written the part that decides who gets in and what happens when the same person rings twice, you have not built an automation, you have built an accident."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- The webhook field sends a single HTTP POST with the alert message as the body; all logic lives in the service you point it at.
- Send JSON with placeholders rather than prose, and prefer Once Per Bar Close so the condition cannot repaint after you act on it.
- Alerts keep running the script version they were created from, so recreate them after every edit to the indicator.
- Guard the endpoint with a secret in the payload and make the handler idempotent, because delivery is one attempt with no retry.
Frequently Asked Questions
Do I need a paid TradingView plan for webhooks?
Yes. The webhook URL field in the alert dialog is a paid plan feature, and the number of active alerts you can keep running also depends on the plan tier. Check the current plan comparison on TradingView before building anything that depends on a specific alert count.
Can a TradingView webhook place a trade directly with my broker?
Not on its own. TradingView sends an HTTP POST to a URL you control; something at that URL has to receive the message and call the broker or platform API. That receiver is your own service or a third party bridge, and it is where authentication, position sizing and duplicate protection have to live.
Why did my alert stop firing after I edited the indicator?
An alert is bound to the version of the script that existed when the alert was created, so editing or republishing the indicator does not update alerts already running. Delete the alert and create it again from the updated script on the correct symbol and timeframe, then confirm the first delivery reaches your endpoint.