TradingView Webhook Automation: The Complete Reference

There is a considerable distance between a line crossing on a chart and a filled order resting at a broker, and almost everything that can go wrong lives in that gap. Most traders describe webhooks as connecting TradingView to my broker, which is a comfortable description and a misleading one. A webhook is not a connection. It is an unauthenticated HTTP POST sent by a third party to a public endpoint that you own and operate, delivered once with no guarantee, with a hard three-second budget for your server to respond. TradingView fires and forgets. Everything that determines whether that fire-and-forget becomes a correct, safe, timely order is infrastructure you are responsible for building.

This matters more in 2026 than it did a few years ago. The June 4 elimination of the pattern day trader rule removed the equity floor that constrained retail intraday activity for a quarter century, same-day options now account for roughly half of S&P 500 options volume, and the market reprices in milliseconds. Automation has become accessible enough that the bottleneck is no longer whether you can build this — it is whether you build it correctly. This is the complete reference for doing that: the alert-to-order flow end to end, payload design, the security model, and the failure modes that only appear once real money is behind them.

What a Webhook Actually Is

A webhook inverts the normal direction of an API call. Instead of your software asking a server for data on a schedule, the server calls you when something happens. Push, not pull. That inversion has four consequences that shape every design decision downstream.

You must always be listening. There is no queue waiting patiently for you to come back online; if your endpoint is down when the alert fires, the alert is simply gone. You do not control retries. You do not control ordering — two alerts fired seconds apart can arrive out of sequence, and nothing in the protocol prevents it. And you cannot ask for it again; there is no replay endpoint, no history to reconcile against. A webhook is a one-shot message from a system that has no obligation to your reliability. Every good design in this guide follows from accepting that.

The Alert-to-Order Flow, End to End

Stage one: condition evaluation. Your alert condition is evaluated on TradingView's servers, not in your browser. The critical choice here is whether the alert triggers on bar close or intrabar. Intrabar alerts fire the instant a condition is met, which is faster and less reliable — a condition satisfied mid-bar can be unsatisfied by the time the bar closes, and an indicator that repaints will happily fire an alert for a signal that later does not exist on the chart. Bar-close alerts are slower and honest. For automation, that trade-off deserves a deliberate decision rather than a default.

Stage two: message rendering. When the condition triggers, TradingView takes the message template you configured and substitutes placeholder values, producing the body it will send.

Stage three: transport. TradingView issues an HTTPS POST to your configured URL. Several hard constraints apply: only ports 80 and 443 are accepted and requests to other ports are rejected, IPv6 is not currently supported, and if your server takes longer than three seconds to process the request, the request is cancelled. That three-second ceiling is the single most important architectural fact in this entire guide, and it dictates the shape of everything behind the URL.

Stage four: authenticate and validate. Your endpoint receives an anonymous POST. Before anything else happens, it must establish that this request is legitimate and well-formed. Not after queuing it, not after parsing it into a trade intent — first.

Stage five: acknowledge and enqueue. Having verified the request, return a fast success response and push the work onto a queue. Anything that involves a network round trip to a broker cannot happen inside the three-second window reliably. The pattern is accept-then-process, and the ordering matters: verify authenticity, then acknowledge, then process asynchronously. Acknowledging before verification means you have just returned a friendly 200 to an attacker.

Stage six: deduplicate. Before acting, check whether you have already processed this event. Duplicates arrive for mundane reasons, and an order placed twice is a real position twice.

Stage seven: map to intent. Translate the payload into an internal order intent — which strategy, which instrument, which direction, open or close. This is a translation layer, and it is where symbol-format mismatches surface.

Stage eight: risk gating. The intent is checked against limits that can veto it unconditionally: maximum capital per trade, maximum concurrent positions, daily loss limit, trading-hours window, symbol filters, minimum time between trades. This layer sits between signal and order deliberately, because a risk limit that strategy logic can argue with is not a limit.

Stage nine: order construction and submission. Build the broker-specific order and submit it with a client-assigned order identifier so a timed-out response can be resolved by querying rather than by blindly retrying.

Stage ten: confirm and reconcile. Await the fill, record actual filled quantity and price — which may differ from what was requested — and update internal state to match broker truth.

Stage eleven: handoff. The filled position enters the exit stack: initial fixed stop, trailing trigger, multi-tier trailing, break-even protection, and OCO brackets resting at the broker. From here the webhook's job is finished and position management takes over.

Payload Structure

Send JSON. If your alert message parses as valid JSON, TradingView transmits it with an application/json content type; if it does not, it is sent as plain text, which most trading endpoints will reject outright. A single stray character breaks this silently, so validating the message body before going live is worth the thirty seconds it takes.

TradingView exposes placeholders that are substituted at fire time. The market-data set covers instrument and bar context — {{ticker}}, {{exchange}}, {{interval}}, {{open}}, {{high}}, {{low}}, {{close}}, {{volume}}, {{time}} for the bar time and {{timenow}} for the moment the alert fired. Strategy alerts expose a richer set describing the intended action, including {{strategy.order.action}}, {{strategy.order.contracts}}, {{strategy.order.id}}, {{strategy.position_size}}, and {{strategy.market_position}}. Indicator plot values are available as {{plot_0}} and similar. New placeholders are added over time, so treat any published list — including this one — as a snapshot and verify against TradingView's current documentation.

The more consequential question is what belongs in the payload at all, and there is a principle worth stating plainly: the alert describes what happened; your system decides what to do about it. A payload should carry event information — which strategy fired, on what instrument, in which direction, at what time — and should not carry position sizing. If the payload dictates quantity, then anyone who can forge a payload can dictate your position size, and your risk parameters live in a chart alert box rather than in your risk layer. Sizing belongs to the system, derived from account capital and your own rules. This separation is both a security boundary and a correctness one.

A workable schema carries a shared secret, a strategy identifier, an action, a symbol, a timestamp, a unique event identifier for deduplication, and a schema version so you can evolve the format without breaking older alerts. Version it from day one; retrofitting versioning across dozens of live alerts is miserable.

Two practical notes. First, symbol format is the most common single point of failure in the entire pipeline: TradingView will happily send NASDAQ:AAPL to a broker that expects AAPL, and the resulting rejection looks like a webhook problem when it is a mapping problem. Normalize symbols explicitly in your translation layer. Second, TradingView's own documentation warns against including sensitive information such as login credentials or passwords in the webhook body. Never put broker API keys in a payload or a URL. Credentials belong in secure storage on the receiving side, and nowhere else.

The Security Model

This is the section that matters most, and it begins with an uncomfortable fact that most TradingView guides skip entirely.

TradingView does not sign its webhook requests. Across the wider webhook ecosystem, the primary security control is HMAC signature verification: the sender computes a cryptographic signature over the raw request body using a shared secret and includes it as a header, and the receiver recomputes it and compares. That mechanism proves both who sent the message and that it was not modified. TradingView provides no such signature header. The industry-standard control is simply not available to you.

The practical consequence is that every TradingView webhook setup falls back to a shared secret carried inside the payload. Understand what that is: a bearer token, not a proof of integrity. It demonstrates that whoever sent the request knew the secret; it does not cryptographically bind the secret to the message contents. It is meaningfully weaker than a signature, and the honest response is not to pretend otherwise but to compensate with layers.

Layer one: HTTPS, without exception. Since a shared secret travels inside the body, transport encryption is what keeps it from being readable in transit. Given the port constraint, use 443.

Layer two: an unguessable path. A long random path segment is obscurity rather than security, but it removes your endpoint from casual scanning. It costs nothing.

Layer three: the shared secret, compared correctly. Validate the secret server-side before any processing, and compare it in constant time. A naive equality comparison leaks information byte by byte through timing and is a real, exploited weakness — use the timing-safe comparison your runtime provides, such as crypto.timingSafeEqual in Node. Store the secret in environment variables or a secret manager, rotate it periodically, and never log it. Structured logging frameworks capture more context than people expect.

Layer four: IP allowlisting. TradingView publishes the IP addresses it sends POST requests from, and restricting inbound traffic to those ranges at the firewall is genuine defense in depth. Two honest caveats: provider IP ranges change, so this needs re-checking on a schedule or your automation dies quietly one day; and because the list changes, it should never be your only control. Pull the current addresses from TradingView's own configuration documentation rather than from any third-party guide, this one included.

Layer five: strict schema validation. Treat every payload as untrusted input. Enforce an explicit schema — required fields, expected types, permitted values for action and symbol — and reject anything that does not conform exactly. Verifying that a request came from a legitimate source does not sanitize its contents, and a handler that passes unvalidated payload data to downstream systems can chain into injection problems at the next hop.

Layer six: timestamp freshness. Include a timestamp and reject requests outside a narrow window, on the order of a few minutes. This bounds the window in which a captured request can be replayed.

Layer seven: idempotency. Track processed event identifiers in a fast store and reject repeats. Where the sender provides no stable identifier, derive one from a hash of the raw body plus key headers. Idempotency is usually discussed as a correctness feature — do not place the order twice — but it is equally a security feature: combined with timestamp validation, it reduces the impact of a replayed request to zero.

Layer eight: rate limiting at the edge. A public endpoint attracts traffic. Cap request rates so a flood cannot exhaust your processing capacity at the moment you need it.

Layer nine, and the one that actually bounds the damage: broker key scoping. Assume every layer above fails and an attacker can post arbitrary valid-looking alerts to your endpoint. What is the worst outcome? If your broker API key is scoped to trading only — able to place and manage orders, unable to withdraw or transfer funds — then the answer is unwanted trading activity in your account. That is serious and potentially expensive. It is not the loss of your funds, because your broker's permission system will reject a withdrawal request regardless of what any compromised software attempts. This is why key scoping is the foundation beneath everything else: it converts an unbounded catastrophe into a bounded one, and it is enforced by a third party rather than by your own code.

Reliability: What Breaks in Production

The three-second ceiling. Everything about receiver design flows from it. A handler that authenticates, validates, records the payload, and returns is comfortably inside the budget. A handler that calls a broker API inline, waits for a fill, and then responds is gambling with a limit it will eventually lose to. Verify, acknowledge, queue, process.

Alerts expire. TradingView alerts expire after roughly two months by default. If you do not set them to open-ended, your automation stops one morning with no error, no alert, and no obvious cause. This is one of the most common silent failures in the entire category and it is a checkbox.

Delivery is not guaranteed and ordering is not guaranteed. Design for missed messages and out-of-order arrival. If your logic assumes an entry alert always precedes its corresponding exit alert, an inverted pair will produce a state your system has no path out of. State machines should be defensive about impossible transitions rather than assuming they cannot happen.

Cold starts. Serverless functions that scale to zero can take longer than three seconds to wake. A platform choice made for cost can quietly become a reliability problem that only manifests on your first alert after a quiet period — precisely the alert you were waiting for.

The three classic misconfigurations. When an order does not appear, it is usually one of three things: the ticker format does not match what the broker expects, the account lacks buying power for the requested size, or the system is pointed at a live endpoint with paper credentials or the reverse. Log the broker's exact error response and read it before assuming the webhook failed.

Log every raw payload. Persist the unmodified body of every request you receive, with a timestamp and the verification result. This is your audit trail when a trade appears that you did not expect, and your only real debugging tool when something intermittent goes wrong.

Test with an inspection endpoint first. Point the alert at a request-inspection service to see exactly what TradingView sends before writing any parsing logic, then move to a broker paper account with full API parity before risking capital.

Architecture of a Receiver Built for This

The workload is a large number of short, unpredictable, I/O-bound requests with occasional heavy computation behind them, and the response budget is three seconds. That shape argues for a non-blocking, event-driven runtime — a Node.js and Express service handling high-concurrency I/O can absorb a burst of simultaneous alerts at an open without a thread per request, provided nothing blocks the event loop. Heavy work — backtests, analytics, anything CPU-bound — belongs in worker thread pools via worker_threads, so a computation never delays an inbound alert. An idempotency store in Redis handles deduplication at speed. Database-backed configuration lets you change gating rules on a running process without restarting it and dropping alerts. And running the whole thing on self-hosted, low-latency nodes keeps the signal-to-fill path short and under your control rather than queued behind other tenants.

What Webhooks Are and Are Not Good For

Webhooks are excellent at decoupling signal generation from execution. They let a Pine Script indicator, a Python model, a Discord alert, or any other source drive the same execution and risk infrastructure through one documented interface. That is the entire bring-your-own-strategy proposition, and it is a genuinely good architecture: your strategy research and your execution layer evolve independently.

They are not a low-latency mechanism. The path runs from TradingView's servers, across the public internet, to your endpoint, then out to your broker's API. That is tens to hundreds of milliseconds in the ordinary case, and it is not competitive with colocated execution. Anyone describing webhook automation as high-frequency trading is confused about what the term means. Webhooks are fast enough to beat a human clicking an order ticket by a wide margin, and they are not fast enough to compete with professionals whose entire business is latency.

They are also not a risk layer. A webhook is transport. It delivers whatever fired, with complete indifference to whether the signal has an edge, whether the size is sane, or whether you have already lost more than you intended today. Everything protective happens after the payload arrives, in code you write. A webhook will faithfully and instantly transmit a losing strategy, which is precisely why the risk gating between signal and order is not an optional refinement.

Go Deeper: The Cluster

This reference is the map from alert to order. These go deep on what happens on either side of it.

• Automated Options Trading: A Complete Technical Guide — the companion hub covering the full automation pipeline, architecture, and what automation does and does not solve.
• How Automated Exit Logic Actually Works — what happens after the order fills: the fixed stop, trailing trigger, multi-tier trailing, break-even, and OCO brackets.
• What It Means That the Software Never Touches Your Money — broker API key permissions in depth, and how to verify the access scope that bounds your webhook's worst case.
• Position Sizing: Fixed-Dollar vs. Percent-of-Account — the risk layer the payload should never be allowed to override.
• Real-Time Config Without a Restart — changing gating rules on a running receiver without dropping alerts.
• Shipping UI to a Live Trading Client Without a Redeploy — the self-hosted client architecture that surrounds the receiver.

The Bottom Line

A TradingView webhook is a one-shot, unauthenticated, unsigned HTTP POST with a three-second response budget and no delivery guarantee. Stated that plainly, the engineering requirements are obvious: verify before you acknowledge, acknowledge before you process, deduplicate everything, validate every field, gate every order through risk limits the payload cannot override, and scope your broker key so that the worst case of total compromise is bounded. None of it is exotic. All of it is skipped constantly.

The deeper point is the same one that applies to every layer of automation: the webhook is transport, not intelligence. It carries a signal from wherever you generate it to the system that executes it, faithfully and quickly, and it has no opinion whatsoever about whether that signal is any good. That remains your problem — which is exactly why StaxInvesting is built as Software — Not Signals: self-hosted in your own environment with zero account access, executing on your own connected brokerage, with webhook ingestion, risk gating, and exit management as infrastructure you control and point at a strategy you chose. In a post-PDT trading environment where more participants can automate intraday than ever before, the infrastructure is the easy part to obtain and the hard part to get right.

This article is a technical reference and is not financial advice or a recommendation to buy or sell any security or options contract. Options trading involves substantial risk of loss and is not suitable for all investors; automation does not create profitability, guarantee execution, or prevent losses. Third-party platform details — including plan requirements, placeholder syntax, IP ranges, timeouts, and port restrictions — reflect publicly available documentation as of July 2026 and change over time; verify all technical specifications against TradingView's official documentation and your broker's API documentation before relying on them. Security practices described here reduce risk but do not eliminate it, and no configuration guarantees a system cannot be compromised. StaxInvesting provides self-hosted trading software — not signals, financial advice, or a managed account — that runs on the member's own connected brokerage; StaxInvesting never accesses member funds, credentials, or trades.