TradingView webhooks: setup and troubleshooting

Check the endpoint before creating the alert

• Enable two-factor authentication on TradingView and confirm your account exposes Webhook URL in alert settings.
• Use a public endpoint. Only ports 80 and 443 are accepted; choose HTTPS on 443. IPv6 is not supported.
• TradingView cancels requests that take longer than three seconds.
• A valid JSON message is sent as application/json, while other messages use text/plain.
• If a firewall needs an allowlist, the documented source addresses are 52.89.214.238, 34.212.75.30, 54.218.53.128, and 52.32.178.7. Recheck the official list before deployment.

Delivery can fail. Inspect Webhook status in the alert log. Official configuration requirements.

Receiver design recommendation: authenticate and validate the request, persist accepted work durably, then acknowledge promptly. Process slow downstream work separately. Returning success before saving the event can hide lost work.

Create the correct alert event

1. Set the chart symbol, timeframe, script, and inputs. Create an alert from that chart.
2. For an indicator using alert(), select Any alert() function call. Its code supplies the message and frequency. For alertcondition(), choose the named condition and set its message and frequency in the dialog.
3. For a strategy, select order fills, alert() calls, or both deliberately. These are different events; selecting both can create two messages for one trading idea.
4. Enable Webhook URL under Notifications, enter the test receiver URL, and create the alert. Inspect a realtime event and its received body.

Running script alerts keep a snapshot of the script, inputs, symbol, and timeframe. Recreate the alert after changing them. Historical bars do not trigger alerts. Pine alert behavior.

Generate the message in Pine Script v6

This indicator uses concatenation and str.tostring(). It sends a cross-up event on a confirmed chart bar. Configure the receiver to associate this fixed alert ID with its symbol and timeframe; assign a different ID for each deployment.

//@version=6
indicator("Webhook JSON demonstration", overlay = true)

fast = ta.ema(close, 9)
slow = ta.ema(close, 21)
crossUp = ta.crossover(fast, slow)
plot(fast, "Fast EMA", color.blue)
plot(slow, "Slow EMA", color.orange)

// Demonstration payload: bind this alert ID to its chart context at the receiver.
if crossUp and barstate.isconfirmed and not na(close)
    string payload = '{"schema_version":1,"alert_id":"paper-ema-cross-v1","event":"cross_up","price":' + str.tostring(close, format.mintick) + ',"bar_time_ms":' + str.tostring(time) + '}'
    alert(payload, alert.freq_once_per_bar_close)

The payload uses fixed strings and numeric values. If you add user-entered text, escape quotes, backslashes, and control characters for JSON. Pine's str.format() uses apostrophe-quoted literal braces, not doubled braces; concatenation avoids that extra formatting layer. Pine string formatting.

Custom messages on strategy fills

//@version=6
strategy("Webhook order-message demonstration", overlay = true)

fast = ta.sma(close, 14)
slow = ta.sma(close, 28)
crossUp = ta.crossover(fast, slow)
crossDown = ta.crossunder(fast, slow)
plot(fast, "Fast SMA", color.blue)
plot(slow, "Slow SMA", color.orange)

// Simulated orders only. The JSON is a custom notification schema.
if crossUp and barstate.isconfirmed
    strategy.entry("Long", strategy.long, qty = 1, alert_message = '{"schema_version":1,"alert_id":"paper-sma-orders-v1","event":"long_entry_fill"}')
if crossDown and barstate.isconfirmed
    strategy.close("Long", alert_message = '{"schema_version":1,"alert_id":"paper-sma-orders-v1","event":"long_exit_fill"}')

// Create an alert with Order fills only.
// Message: {{strategy.order.alert_message}}

Select Order fills only and put {{strategy.order.alert_message}} alone in Message. This example supplies a full JSON body on both order calls. Do not wrap it in another quoted JSON string. To use fill-price and quantity placeholders, use the preceding dialog template instead.

These educational examples are not trading recommendations or profitability tests. Chart-bar confirmation does not solve every form of repainting, including unconfirmed higher-timeframe inputs. A strategy order alert comes from the broker emulator and may occur after the signal bar.

Handle retries and duplicate events

TradingView documents resends after an HTTP 500 through 599 response, except 504: wait five seconds, with at most three resends, for up to four sends per trigger. That rule does not promise retries for every timeout, network failure, or 4xx response. Webhook resubmission policy.

Recommended receiver behavior: store an event identifier and processing state atomically, return the previous acceptance result for a duplicate, and avoid placing another order. An alert ID alone is not unique per event. Design the key for your event type; symbol plus bar time can collide when a strategy has multiple fills on one bar.

Reconcile uncertain broker responses before retrying downstream work. The receiver needs its own recovery policy after accepting the HTTP request; TradingView cannot observe the worker or broker state.

Authenticate the sender and restrict the receiver

TradingView documents a certificate sent with HTTPS webhook requests. Configure certificate verification at the receiver or its TLS terminator using the documented identity. Trust verified certificate information from your own proxy, not a client-supplied header that merely claims that identity. Webhook authentication.

Do not put passwords, broker keys, or login credentials in alert messages. Keep broker credentials at the receiver and follow your provider's documented authentication setup. Limit accepted events, symbols, quantities, and replay age; redact sensitive endpoint details from logs. TradingView credential guidance.

Reproduce failures without sending live orders

The following is a test procedure, not a report of a measured delivery test. Use a staging receiver with order routing disabled. Replace the reserved example hostname with an endpoint you control and configure its required authentication.

curl --include --max-time 3 \
  --request POST 'https://YOUR-STAGING-HOST.example/webhook' \
  --header 'Content-Type: application/json' \
  --data '{"schema_version":1,"alert_id":"diagnostic-only","event":"test","event_id":"test-001","price":123.45}'

1. Send the sample once. Inspect the status, body, validation result, and durable event record. This checks your HTTP path, not TradingView's source certificate or network.
2. Send the same event again. Verify that the receiver records a duplicate and does not repeat downstream work. Then send malformed JSON and confirm a logged rejection.
3. Create a separate TradingView test alert and capture its rendered message. Compare event time, Webhook status, proxy access log, and application event record.
4. In isolated staging, a controlled 500 response can test the documented resend behavior. Do not provoke retries against a live broker connection.

Match the observed message to TradingView's webhook error reference. For timing issues, continue with alert delay troubleshooting or bar-close frequency.

Common questions

Official documentation checked October 16, 2026. Examples require validation against your receiver's schema and deployment settings.

Write the alert logic with Pineify

Ask the Pine Script AI Coding Agent for an indicator or strategy using your conditions, event type, and receiver schema. Review its code, test the resulting payload, and recreate the TradingView alert after changes. Receiver hosting, authentication, and order execution remain your responsibility.

TradingView alerts guides · TradingView guide hub