TradingView to Binance: 5-Checkpoint Debug Guide

Connect TradingView signals to Binance (TradingView to Binance) for automatic order execution, but your alert triggers, the webhook fires, and yet your account doesn't move. The problem usually isn't at either end — we've already checked the alert and API key (the credential exchanges use to verify your identity). It's in the middle chain: frequency, payload, authentication, error codes, and execution reports. Miss any of these five checkpoints, and orders will silently disappear. This article walks through the configuration for each checkpoint and where to look for errors. This article does not cover how to write Pine Script (TradingView's strategy programming language), how to apply for API keys, or rejection details for OKX, Bitget, and Bybit.

Checkpoint 1: TradingView Alert Webhook Frequency — Three Interfaces Don't Share Settings

TradingView has three places where you can control alert frequency: the Create Alert dialog, alertcondition() in Pine Script (TradingView's strategy programming language), and alert() in Pine Script. The option names and defaults across these three interfaces are completely unrelated. Mixing them up is the prime suspect when "alerts appear to be running but signals arrive fewer than expected."

The UI dropdown offers four options: Once only, Once per bar, Once per bar close, and Once per minute or every time. Pine's alert() uses three constants for its freq parameter: alert.freq_all, alert.freq_once_per_bar, and alert.freq_once_per_bar_close. alertcondition() has no frequency parameter at all — it fires at most once per bar close.

The easiest thing to overlook is the default: if alert() is called without a freq argument, the code-level default is alert.freq_once_per_bar — not "fire every time." The same strategy can behave very differently depending on whether the alert was created via the UI or via Pine. We recommend confirming which interface your alert was built on before diving into debugging.

Checkpoint 2: Webhook Payload — Fields TVSBot Reads

A webhook is the mechanism by which TradingView POSTs a payload to a URL when an alert triggers. TVSBot gives each user a dedicated URL: /webhook/{user_webhook_token}, where the token is a random string generated at registration. The payload (the JSON being sent) also carries a secret field for a second layer of verification. Both layers must match, or the exchange will reject the request outright.

The message field in your TradingView alert settings is the raw JSON you send. TVSBot reads these required fields:

qty_type has five variants: fixed, usdt, percent, margin_pct, and margin_usdt. The most commonly misunderstood pair is usdt and margin_usdt — writing qty: 20 means a $20 position in one case, and $20 collateral multiplied by leverage in the other. A full breakdown is inthis qty_type trap article.

Two optional fields to watch: spot orders ignore leverage; futures margin_mode defaults to cross. Adding sl_pct / tp_pct to the payload will place stop-loss and take-profit orders on the exchange side — checkpoint 5 explains why this matters.

Checkpoint 3: 401 and 400 — Authentication and Schema's First Line of Defense

After a request reaches TVSBot, the first checkpoint is dual verification: the URL token plus the payload secret, both must match. A wrong secret returns HTTP 401; missing fields or type mismatches in the payload return HTTP 400, along with detailed error descriptions — this is the most common cause of "silent failures." Many people only check whether the HTTP status is 200 and ignore the response body. If you can't even receive a 401 (meaning the alert never sent out), walk through the debugging flow inthis webhook not responding article first, then come back to this checkpoint.

After passing verification and schema checks, TVSBot returns 200 with queued — meaning "received and enqueued," not "order executed." The actual order result is found in Telegram notifications and the dashboard, not in the HTTP response.

We've identified two additional behaviors that are by design, not bugs: each user's webhook has a QPS (queries per second) cap — based on TVSBot's backend code, the default is 60 requests per 60 seconds (equivalent to 1 per second), and this is a per-token limit. There's also a per-IP cap of 30 requests per 30 seconds. Duplicate sends with the same strategy, symbol, and action within 60 seconds are treated as retries and dropped by TVSBot. So "sending twice results in only one order" is expected behavior.

        {
          "secret": "...",
          "strategy": "BTC Breakout",
          "action": "buy",
          "symbol": "BTCUSDT",
          "exchange": "binance",
          "market_type": "futures",
          "order_type": "market",
          "qty_type": "margin_usdt",
          "qty": 20,
          "leverage": 3,
          "sl_pct": 2,
          "tp_pct": 4
        }
        

Three possible outcomes after sending:

• Wrong secret → HTTP 401
• Missing field or type error → HTTP 400 (with detailed errors)
• Passed verification → HTTP 200: {"received": true, "queued": true, "message": "..."}

Checkpoint 4: Binance Order Rejection — What the Error Codes Mean

TVSBot accepted it and the queue ran through, but Binance can still reject your order. We recommend checking API key permissions as the first suspect: the official message for error -2015 reads Invalid API-key, IP, or permissions for action — if your key doesn't have Spot/Futures Trading enabled, or if your IP whitelist doesn't include your server, you'll hit this code. For details on how to enable API key permissions and configure IP whitelists,this article covers it thoroughly; we won't repeat it here.

The second suspect is symbol filters: the Binance official API documentation lists three order validation filters — LOT_SIZE, MIN_NOTIONAL, and PRICE_FILTER (exchange-imposed rules for quantity precision, minimum notional value, and price precision per symbol). If qty precision is off, the notional value is too low, or the price has the wrong number of decimal places, the exchange will reject; specific error codes depend on the returned msg, and the official documentation doesn't tie each filter to a fixed code.

Checkpoint 5: 200 + queued Is Not Execution — Where to Find Execution Reports

One more time: HTTP 200 with queued only means TVSBot accepted the signal into its queue. Order success, partial fill, rejection, and failure — these four statuses (filled, partial, rejected, failed) are visible in Telegram notifications and the dashboard.

Every signal on the Signals page has a processing_log (the step-by-step record from receiving the webhook to the final order result). When debugging, open it first — it's faster than guessing.

Futures traders should also know this default behavior: TVSBot assumes your Binance account is in One-way Mode (one position per direction at a time). If your account is set to Hedge Mode (two-way positions), Binance will reject the signal — not because of the payload, but because the account setting doesn't match the default. For details on the difference between the two modes,this article has you covered.

What TVSBot Doesn't Do

Let's clarify two things upfront so you don't set expectations in the wrong place. First, Pine-side take-profit and stop-loss only work while your TradingView is running and alerts are triggering — if TradingView goes offline or the alert doesn't fire, Pine won't close your position for you.

Second, 200 + queued means "received," not "executed." Final execution is determined by the exchange; rejected orders stay rejected. The status is fully recorded in processing_log and there's no automatic retry until success.

TradingView to Binance Five-Checkpoint Debug Checklist

When signals aren't reaching your account, check from top to bottom in order. Each row's "Where to Check" is that checkpoint's debugging entry point.

Frequently Asked Questions