TradingView alerts through the relay

Planned

The relay and the alert format are planned. Nothing on this page works yet. TradingView’s requirements below are from TradingView, “About webhooks”, read 6 Oct 2026.

Why a relay

TradingView sends a webhook as an HTTP POST from its servers. Its rules:

• only ports 80 and 443 are accepted;
• the server must answer within three seconds, or the request is cancelled;
• no IPv6;
• webhooks need two-factor authentication on the TradingView account;
• webhooks “may occasionally fail” to arrive.

Guard listens on 127.0.0.1:8547, on your machine. TradingView cannot reach it, and you should not open your machine to the internet to change that. So alerts go to a relay instead.

How it works

TradingView ──HTTPS POST──▶ Zunder Relay ══WebSocket (opened by your Guard)══▶ your Guard ──▶ Hyperliquid
            your personal URL              forwards the alert text only       nine rules, signs

1. Your Guard opens an outbound WebSocket to the relay. You open no port.
2. You paste your personal relay URL into the TradingView alert’s webhook field.
3. TradingView posts the alert message to the relay. The relay forwards the text to your Guard and answers TradingView at once.
4. Your Guard parses the alert, applies the nine rules, signs with your API wallet and sends to Hyperliquid.

The relay holds no key and no funds and cannot place an order. Details: The relay.

The alert message

{
  "zunder": 1,
  "secret": "your-alert-secret",
  "coin": "{{ticker}}",
  "side": "buy",
  "stop": 58800,
  "price": {{close}}
}

Field	Meaning
zunder	format version
secret	a passphrase only your Guard knows; an alert without it is dropped
coin	Hyperliquid coin name, for example BTC. {{ticker}} works only if your chart’s ticker matches
side	buy, sell or close
stop	the stop price. Guard sizes from it; there is no size field
price	the reference price; Guard bounds the order’s worst fill around it

Draft

The field names are a draft and will change before release. Two design points are open: how the alert is authenticated (TradingView cannot sign a request, so the relay URL and the secret are bearer secrets: anyone who has both can send alerts, which still pass your rules), and how replayed alerts are refused. See Threat model.

Example. A breakout alert fires on BTC with "stop": 58800 at a close of 60,000. Guard sizes the entry so that the stop loses at most 2% of equity, places the entry and its stop together, and records the decision. If the daily loss stop has fired, the alert is refused and the refusal is in your Guard’s log, not TradingView’s.

Limits

• Your Guard must be running and connected. An alert that arrives while it is offline is not stored for later; a stale entry is worse than a missed one.
• TradingView sees only that the relay answered, not Guard’s decision. Use Guard’s own alerts (Telegram, planned) to see fills and refusals.
• Latency. TradingView to relay to Guard adds network time. Alerts suit decisions on closed bars, not speed.