TradingView Webhook Alerts: Every Field, With Working JSON

Search “tradingview webhook alerts official documentation” and you land on posts that read the same way: a paragraph about what webhooks are, a screenshot of the alert box, a vague mention of JSON near the bottom.

[ORIGINAL DATA] Eight near-identical variations of that search, “documentation,” “official docs,” “webhook alerts docs,” currently rank positions 7 through 9 across PickMyTrade’s tracked keywords. Combined, they generate zero clicks.

That’s a format problem, not a ranking problem. Someone searching “documentation” wants a table, not a story, and wants to know if quantity is a string or a number before pasting anything into an alert tied to a funded account. This page answers that: every field TradingView and a webhook platform like PickMyTrade use, its type, whether it’s required, and a working example.

Key Takeaways
• TradingView’s alert placeholders ({{ticker}}, {{close}}, {{strategy.order.action}}, and roughly 20 others) are TradingView’s mechanism. The JSON body, symbol, data, quantity, token, is defined by whichever platform receives the webhook, not by TradingView.
• [ORIGINAL DATA] Eight related “official documentation” search phrasings rank position 7 to 9 combined, with zero recorded clicks, which is why this page leads with tables.
• TradingView’s Basic plan doesn’t include webhook notifications. You need Essential or higher, plus 2-factor authentication turned on regardless of plan.
• A webhook alert has a 3-second processing window on TradingView’s side. If the receiving server doesn’t respond in time, TradingView cancels the request.
• Only four fields are effectively required for a working order: symbol, data, quantity or risk_percentage, and a token. Everything else has a default.

Why Does This Need a Reference, Not Another Tutorial?

Most “how to set up TradingView webhooks” content is written for a first-timer, so it spends 800 words explaining what an alert is before showing a single field name. Useful once. Useless the fifth time, when you’re debugging why a live alert sent "quantity": null instead of a number.

A webhook is simple: one system posts data to a URL the moment something happens, instead of the receiving system asking for it repeatedly (en.wikipedia.org/wiki/Webhook, checked 2026-09-04). TradingView supports several notification methods, and webhook URLs are one, posting to trigger external bots or scripts the instant an alert fires (tradingview.com/support/solutions/43000520149-about-webhooks, checked 2026-09-04). The alert box gives you one text field and expects valid JSON typed by hand, with zero validation.

The fix isn’t a better explanation of what a webhook is. It’s a table you can scan in ten seconds to confirm a field name, its type, and whether it’s required.

In short: Webhook alerts fail less from misunderstanding the concept and more from typos in field names, wrong data types, or missing required fields inside a JSON body TradingView never validates. A reference table catches that faster than a tutorial, especially once you’re debugging a live order instead of learning the basics.

What Does a TradingView Webhook Alert Actually Send?

When an alert fires, TradingView sends a standard HTTP POST to whatever URL you configured, with the alert message as the body. Valid JSON gets tagged Content-Type: application/json; plain text goes out as text/plain (tradingview.com/support/solutions/43000529348-webhooks, checked 2026-09-04). There’s no separate “webhook API.” The body is whatever you typed into the message box, with placeholders swapped for live values.

TradingView documents hard technical limits that don’t show up in most walkthroughs, but matter on a funded account:

That timeout line matters more than it looks. If the receiving platform is slow to acknowledge, TradingView doesn’t retry. It cancels.

[UNIQUE INSIGHT] In practice, “the alert fired in my TradingView log but nothing happened downstream” is almost never a TradingView problem. Response time on the receiving end is the first thing worth checking.

In short: TradingView’s webhook mechanism is a plain HTTP POST with no built-in retry logic, a 3-second timeout, and a hard requirement for 2-factor authentication. None of that is configurable from the alert box, and none of it is optional if you want the alert to reach its destination reliably.

Which TradingView Plans Actually Support Webhook Alerts?

This part goes stale fast; TradingView renamed its plan tiers. The current lineup is Basic, Essential, Plus, Premium, and Ultimate (tradingview.com/pricing, checked 2026-09-04). Per TradingView’s comparison table, webhook notifications are included from Essential upward. Basic doesn’t have this feature.

Worth being honest: some older guides reference previous plan names (Pro, Pro+, Premium), and legacy subscriptions might still show those. Either way, a free account can’t send webhook alerts, and you’ll need 2FA on before the webhook option appears in the alert dialog.

In short: Webhook alerts require at least TradingView’s Essential tier, previously called Pro, plus 2-factor authentication turned on. The free Basic plan cannot send webhook alerts under any configuration, no matter how correctly the JSON body itself is written or formatted.

What Placeholders Can You Use Inside the Alert Message?

Placeholders are tokens typed into the message box that get swapped for real values when an alert fires. TradingView documents around two dozen (tradingview.com/support/solutions/43000531021-list-of-placeholders, checked 2026-09-04). The ones that show up in almost every webhook payload:

There’s a longer list, including per-plot placeholders like {{plot_0}} through {{plot_19}}, and a full set of strategy.* variables for order IDs, comments, and prior position state. This page sticks to what shows up in a standard order payload.

One thing trips people up constantly: placeholders only populate with real values on live bars. On a backtest, {{strategy.order.action}} comes back blank, because there’s no real order yet.

In short: General placeholders like {{ticker}} and {{close}} work in any alert type, strategy or indicator. strategy.* placeholders only populate on realtime order fills, never on historical or backtested bars, which is a common source of “the alert looks broken but isn’t” confusion during setup.

What Fields Belong in the JSON Payload Itself?

This is where TradingView’s documentation stops and the receiving platform’s starts. TradingView sends whatever text you put in the message box; it doesn’t define trading-specific JSON. The fields below are what a webhook platform like PickMyTrade reads out of that body (docs.pickmytrade.trade/docs/tradingview-json-alert-configuration, checked 2026-09-04).

Core fields, present in essentially every working alert:

*quantity isn’t strictly required if you supply risk_percentage instead; the platform calculates position size from account risk.

Order and pricing fields:

The data field catches people off guard, doing the job you’d expect a field named action to do. In a Pine strategy, it holds {{strategy.order.action}} so TradingView fills in "buy" or "sell". In an indicator alert with no strategy object behind it, you write the action yourself, as a plain string.

In short: A minimal working payload needs symbol, data, enough to size the trade (quantity or risk_percentage), and a token. order_type defaults to a market order unless price is supplied, which switches the order to a limit order instead.

How Do You Add Risk Management Fields?

Take profit, stop loss, and trailing logic live in the same JSON body as optional fields. Skipping them means sending naked market orders with no exit attached.

Trailing stops are separate, and only apply to indicator-based alerts; a Pine strategy handles trailing in the script itself:

Pick one method per trade. Mixing tp with percentage_tp in the same payload doesn’t average the two; it just creates ambiguity worth catching in testing.

In short: Exits are optional fields, so a payload missing them still executes, just without a stop loss attached. Pick one take-profit format and one stop-loss format per alert, and treat trailing stops as an indicator-only feature, not something a Pine strategy alert can send through JSON.

How Do Strategy Alerts Differ From Indicator Alerts in the JSON?

This decides which fields you can use, and it’s easy to miss since both alert types get typed into the same message box.

pyramid controls what happens when a second signal fires in the same direction as an open position. With pyramid: true, the new signal stacks on the existing one, matching how a Pine strategy naturally behaves. With pyramid: false, a same-direction signal closes the existing position first, the safer default for indicator alerts.

There’s also reverse_order_close: when true, an opposite-direction signal always closes the existing position first, regardless of pyramid.

In short: Strategy alerts lean on TradingView’s own strategy.* placeholders and default to stacking positions on same-direction signals. Indicator alerts require writing the action explicitly, default to closing before re-entering, and are the only alert type that supports trailing stop fields inside the JSON payload.

Working JSON Examples You Can Copy

These follow the structure documented for PickMyTrade’s webhook endpoint (docs.pickmytrade.trade/docs/tradingview-json-alert-configuration, checked 2026-09-04). Swap in your own token and account_id before using any of these live.

Strategy alert, using TradingView’s own placeholders for action, quantity, and price:

{
    "symbol": "NQ",
    "date": "{{timenow}}",
    "data": "{{strategy.order.action}}",
    "quantity": "{{strategy.order.contracts}}",
    "risk_percentage": 0,
    "price": "{{close}}",
    "tp": 0,
    "sl": 0,
    "token": "your_token_here",
    "pyramid": true,
    "account_id": "your_account_id"
}

Indicator alert, with a fixed quantity, dollar-based exits, and a trailing stop:

{
    "symbol": "NQ",
    "date": "{{timenow}}",
    "data": "buy",
    "quantity": 10,
    "price": "{{close}}",
    "dollar_tp": 10,
    "dollar_sl": 5,
    "trail": 1,
    "trail_stop": 3.75,
    "token": "your_token_here",
    "pyramid": false,
    "reverse_order_close": true,
    "account_id": "your_account_id"
}

Multi-account execution, one alert sent to several accounts with different sizing on each:

{
    "symbol": "NQ",
    "date": "{{timenow}}",
    "data": "{{strategy.order.action}}",
    "price": "{{close}}",
    "multiple_accounts": [
        {
            "token": "token_account_one",
            "account_id": "FFFF",
            "risk_percentage": 0,
            "quantity_multiplier": 1
        },
        {
            "token": "token_account_two",
            "account_id": "GGGG",
            "risk_percentage": 1,
            "quantity_multiplier": 2
        }
    ]
}

All three are valid JSON per RFC 8259 (rfc-editor.org/rfc/rfc8259): double-quoted keys, no trailing commas, no comments. TradingView won’t say which line broke a malformed payload; it just fails to send application/json headers and treats the whole thing as plain text.

For the full step-by-step setup, including where to paste the generated code inside TradingView’s alert dialog, PickMyTrade’s setup guide walks through the process screen by screen (docs.pickmytrade.trade/docs/tradingview-alerts-setup).

What Commonly Breaks a Webhook Alert?

Most failures aren’t exotic. They’re the same handful of mistakes, repeated:

• Wrong data type. quantity sent as a quoted string when a number is expected can silently misfire depending on how the receiving system parses it.
• Symbol mismatch. {{ticker}} for a futures contract often doesn’t match the exact format your broker account expects, a common cause of “symbol/account mismatch” errors.
• 2FA not enabled. The webhook URL field doesn’t appear until 2-factor authentication is on.
• Stale alert logic. Editing your Pine script doesn’t update an alert already running. Delete and recreate it, or it keeps firing against old code.
• Slow receiving server. Given the 3-second window, a delayed response, cold starts, queued jobs, can get the request cancelled before it completes.
• Free-plan webhooks. Basic doesn’t include webhook notifications, so an alert configured that way on a free account simply won’t fire.

None of these are edge cases. They’re the first things worth checking, roughly in this order, before assuming the JSON structure is wrong. For a deeper walk-through of connecting TradingView to Tradovate, PickMyTrade’s guide covers the full flow (blog.pickmytrade.trade/tradingview-to-tradovate-webhook-guide-2026-no-code).

In short: Most broken webhook alerts trace back to a data-type mismatch, a symbol that doesn’t match the broker’s format, 2FA being off, or an alert still running old Pine logic, not a fundamentally wrong JSON structure or a bug in the receiving platform itself.

Frequently Asked Questions

Is there one official JSON schema TradingView publishes for webhook alerts?

No. TradingView’s docs cover the mechanics (POST request, timeout, IP addresses, 2FA) but don’t define trading-specific fields like quantity or stop_loss. Those come from whichever platform receives the alert.

What’s the difference between a placeholder and a JSON field?

A placeholder, like {{close}}, is TradingView’s syntax for a live value. A JSON field, like "quantity", is a key the receiving platform reads. You usually assign a placeholder as a field’s value.

Do I need a paid TradingView plan to send webhook alerts?

Yes. The free Basic plan doesn’t include webhook notifications. You need at least Essential, plus 2FA enabled before the option appears in the alert dialog.

What happens if I leave the quantity field out entirely?

Supply risk_percentage instead, and size is calculated from account equity automatically. Leave out both, and the order won’t have enough information to size correctly.

Can I test a strategy alert’s JSON without placing a real trade?

Not really. strategy.* placeholders only populate on realtime fills, staying blank on historical bars, so a small live position beats a backtest for checking payload structure.

The Short Version

A TradingView webhook alert has two vocabularies stacked together, and most confusion comes from treating them as one thing. TradingView’s placeholders are the input side, {{ticker}}, {{close}}, {{strategy.order.action}}, all documented, none trading-specific by themselves. The JSON payload is the output side, defined by whatever platform reads it, built from fields like symbol, data, quantity, and token.

Knowing which vocabulary a given field belongs to is what turns a copied JSON snippet into something you can debug when a fill doesn’t match what you expected. Check the field type and the plan tier before assuming the strategy logic itself is broken.