TradingView Webhook to Binance: Crypto Automation 2026

jayadev rana Avatar

To automate crypto trades with a TradingView webhook to Binance, you fire a Pine Script alert that sends a JSON payload to a small relay server (a public HTTPS endpoint), and that relay signs and forwards the order to Binance’s REST API using your HMAC-SHA256 API keys. TradingView cannot call Binance directly — the relay in the middle is what turns an alert into a live order. As of July 2026, this three-part chain (Pine alert → relay → Binance /api/v3/order) is the standard, reliable pattern.

I’m Jayadev Rana, a TradingView-certified Pine Script developer. Over 8+ years I’ve built 7,700+ strategies and automation setups for traders in 14+ countries, and crypto webhook bridges are one of the most common builds that land on my desk. Below is exactly how the pipeline works in 2026, with valid Pine Script v6, a real webhook payload, and the relay-side signing that trips most people up.

How the TradingView → Binance webhook chain works

There are four moving parts, and understanding each one saves hours of debugging:

  • Pine Script alert — your strategy or indicator emits a signal and calls alert() with a JSON message.
  • TradingView webhook — when the alert triggers, TradingView sends an HTTP POST to a URL you set, with your JSON in the body. Webhook alerts require a paid TradingView plan (Essential tier and up) plus two-factor authentication.
  • Relay server — a public HTTPS endpoint you control that receives the POST, validates it, and calls Binance.
  • Binance REST API — the relay signs the order with your API key and secret and posts it to api.binance.com.

One security detail matters more than any other: TradingView does not sign its webhook requests. Any public URL that accepts webhooks is, in principle, reachable by the whole internet. The standard defense is to embed a long random secret inside the JSON body and have your relay reject any payload that doesn’t match. I treat this as non-negotiable on every build.

A note on Binance availability by region

Binance is accessible in 180+ countries, but coverage is not uniform, and you should confirm your own situation before wiring up capital. As of 2026, the global Binance.com platform is not available to United States residents, who use the separate Binance.US entity with a narrower product set. Derivatives and futures are unavailable in a number of markets, including the EU, UK, Canada, and Australia, and a handful of jurisdictions are fully restricted under international sanctions. None of this is trading advice — it’s simply the compliance reality you need to check against your Binance account and local rules before automating anything.

Step 1: The Pine Script v6 signal

Here’s a minimal, valid Pine Script v6 strategy that emits a clean BUY/SELL JSON for a Binance relay. It uses an EMA crossover purely as an example engine — swap in your own logic.

//@version=6
strategy("BTCUSDT EMA Bridge", overlay=true, initial_capital=1000)

fastLen = input.int(9,  "Fast EMA")
slowLen = input.int(21, "Slow EMA")
qty     = input.float(0.01, "Order qty (BTC)")
secret  = input.string("PUT_A_LONG_RANDOM_SECRET_HERE", "Webhook secret")

fastEma = ta.ema(close, fastLen)
slowEma = ta.ema(close, slowLen)

goLong = ta.crossover(fastEma, slowEma)
goExit = ta.crossunder(fastEma, slowEma)

// Build the JSON payload the relay will parse
buildMsg(string side) =>
    '{"secret":"' + secret + '","exchange":"binance","market":"spot","symbol":"' + syminfo.ticker + '","side":"' + side + '","type":"MARKET","qty":' + str.tostring(qty) + '}'

if goLong
    strategy.entry("Long", strategy.long)
    alert(buildMsg("BUY"), alert.freq_once_per_bar_close)

if goExit
    strategy.close("Long")
    alert(buildMsg("SELL"), alert.freq_once_per_bar_close)

plot(fastEma, "Fast EMA", color.aqua)
plot(slowEma, "Slow EMA", color.orange)

Why once-per-bar-close matters

Notice alert.freq_once_per_bar_close. Intrabar signals can repaint — the condition looks true mid-candle, then flips before the bar closes, and your relay has already fired a real order. Firing only on close trades a slight delay for reliability, which is almost always the right call for automation. I break down the trade-offs in detail in my guide on Pine Script alert frequencies. If you’re still on an older version, my note on the latest Pine Script version in 2026 covers what changed in v6.

Step 2: The webhook JSON payload

When you create the alert in TradingView, you either let the alert() calls above supply the message, or you paste a JSON template into the alert box using placeholders. A realistic Binance-bridge payload looks like this:

{
  "secret": "a2f9c7e1b4d8-keep-this-long-and-random",
  "exchange": "binance",
  "market": "spot",
  "symbol": "{{ticker}}",
  "side": "{{strategy.order.action}}",
  "type": "MARKET",
  "qty": "0.01",
  "price": "{{close}}",
  "time": "{{timenow}}"
}

TradingView replaces {{ticker}}, {{strategy.order.action}}, {{close}} and {{timenow}} with live values when the alert fires. Set the webhook URL to your relay endpoint under the alert’s Notifications tab, and make sure the message is valid JSON so TradingView sends an application/json content type.

Step 3: The relay that signs Binance orders

This is where most DIY setups break. Binance’s trading endpoints require an HMAC-SHA256 signature: you sign the request parameters with your API secret and send your API key in the X-MBX-APIKEY header. A minimal Python relay handler looks like this:

import time, hmac, hashlib, urllib.parse, requests

API_KEY    = "your_api_key"
API_SECRET = b"your_api_secret"
BASE       = "https://api.binance.com"

def place_market_order(symbol, side, qty):
    params = {
        "symbol": symbol,
        "side": side,            # BUY or SELL
        "type": "MARKET",
        "quantity": qty,
        "recvWindow": 5000,
        "timestamp": int(time.time() * 1000),
    }
    # Since 2026-01-15, percent-encode params BEFORE signing
    query = urllib.parse.urlencode(params)
    sig   = hmac.new(API_SECRET, query.encode(), hashlib.sha256).hexdigest()
    url   = f"{BASE}/api/v3/order?{query}&signature={sig}"
    return requests.post(url, headers={"X-MBX-APIKEY": API_KEY}).json()

Two current details to get right in 2026:

  • Percent-encode before signing. Since roughly 15 January 2026, Binance requires the payload to be percent-encoded before you compute the signature. Get the order wrong and the API rejects the request with -1022 INVALID_SIGNATURE. This was the first thing that broke in my own relay after the change — Python’s urllib.parse.urlencode handles it, but hand-rolled query strings often don’t.
  • Rate limits. Binance’s REQUEST_WEIGHT budget is 6,000 per minute, counted per IP address rather than per API key. A single market order is cheap, but if your relay polls balances or order status in a loop you can burn through the budget fast. Cache and back off.

For USDT-margined futures the pattern is the same but the endpoint is POST /fapi/v1/order on fapi.binance.com. Note a December 2025 change: conditional orders such as STOP_MARKET and TAKE_PROFIT_MARKET now have to go through the newer /fapi/v1/algoOrder endpoint instead of the plain order endpoint. If you’re porting an old futures bot, that’s a common breakage.

Want this built and hardened for your exact strategy rather than wrestling with signatures yourself? Message me on WhatsApp at +91 77352 68199 and I’ll scope it with you.

Hosted relay vs self-hosted: pick your trade-off

You don’t have to write the relay yourself. Here’s how the common routes compare.

Approach Control Latency Best for
Self-hosted VPS relay Full (your code, your keys) Lowest Serious automation, custom logic
No-code hosted relay Limited Adds a hop Getting started, no coding
Open-source relay (self-run) High Low Devs who want a head start

The same webhook-and-relay architecture powers non-crypto automation too — I use an almost identical chain in my guide on automating TradingView alerts to Interactive Brokers. Only the broker adapter changes.

Hardening checklist before you risk real capital

  • Validate the secret on every inbound webhook and drop anything that fails.
  • Restrict API key permissions — enable spot/futures trading, never withdrawals, and use Binance’s IP allowlist so the key only works from your relay’s IP.
  • Test on the Binance testnet first, then go live with tiny size.
  • Log every fill and add an alert (Telegram works well) so you know instantly if an order fails.
  • Handle idempotency — a retried webhook should not double your position.

If you’d rather have a certified developer design the Pine Script signal and the bridge end-to-end, that’s exactly what my Pine Script development and strategy development services cover.

FAQ

Can TradingView connect to Binance directly?

No. TradingView can only send a webhook (an HTTP POST) to a URL. It cannot authenticate to Binance on its own, so you always need a relay in between that holds your API keys and signs the order.

Do I need a paid TradingView plan for Binance webhooks?

Yes. Webhook alerts start at the Essential tier and require two-factor authentication on your TradingView account. Free plans cannot send webhooks.

Is TradingView-to-Binance automation legal where I live?

Automation itself is a normal API use, but Binance’s availability and product access vary by country, and some regions restrict futures or the platform entirely. Check Binance’s current terms for your jurisdiction and your local regulations before trading.

Why does my Binance order return -1022 INVALID_SIGNATURE?

Almost always a signing mistake. Since January 2026 you must percent-encode the parameters before computing the HMAC-SHA256 signature, sign the exact string you send, and keep your system clock in sync so the timestamp is within recvWindow.

Spot or futures for a first automation?

Spot is simpler and lower-risk to learn on — no leverage, no liquidation. Futures adds margin, funding, and the newer algo-order endpoint for stops. Start on spot, on testnet, with size you can afford to lose.

Ready to automate your Binance strategy the right way? Send me your rules on WhatsApp at +91 77352 68199 and I’ll help you get a tested bridge live.

Risk disclaimer: Cryptocurrency trading is highly volatile and can result in the loss of your entire capital. Automated systems can fail, misfire, or execute unintended orders due to bugs, connectivity issues, or exchange outages. Nothing here is financial advice or a promise of profit — no strategy or bridge is guaranteed to be profitable. Test thoroughly on a testnet, use only risk capital, and confirm Binance’s availability and rules in your jurisdiction before trading live.

Leave a Reply

Your email address will not be published. Required fields are marked *