TradingView alerts to a trading bot: validation and execution

A TradingView alert becomes a bot instruction only after another system receives it, validates it, checks account state and submits an order. A webhook delivery receipt is not an exchange fill. Before connecting anything, write down what should happen to repeated, delayed and contradictory signals.

That distinction answers a practical question: why can a chart show one entry while an account contains two? The signal, delivery and execution are separate events. Keeping them separate makes the discrepancy traceable and prevents a convenient chart notification from becoming an unrestricted instruction to trade.

Start with a signal specification

Record the exact instrument, venue, market type, timeframe and strategy version. BTC spot and a BTC perpetual contract are different instruments even when their chart labels look similar. Define whether the condition is checked during the candle or after its close. A crossover must describe the previous and current values; “the fast average is higher” describes a state that can remain true across many candles.

Also specify position behavior. Does a second valid signal increase exposure, replace a pending order or do nothing? Can an exit arrive before an entry confirmation? Those decisions belong in the rules, rather than in a hurried webhook setup. Our AI strategy specification guide provides a starting template.

Understand what TradingView actually sends

A webhook sends an HTTP POST to a receiving address. TradingView documents webhook resubmission for certain server errors, so receivers must distinguish a repeated delivery from a new trading decision. Do not interpret retry behavior as a guarantee that every signal will arrive.

Keep an immutable event identifier, strategy version, instrument, action, event time and expiry policy. The identifier must distinguish intentional separate entries while staying unchanged when the same event is delivered again. Symbol and direction alone are insufficient: they would suppress legitimate later trades. Do not put exchange secrets, passwords or withdrawal credentials in an alert message.

Work through a duplicate and a delay

Consider an educational spot strategy on five-minute candles. One confirmed signal requests a purchase of 0.01 BTC, subject to a 0.02 BTC total-position limit. It arrives twice. If both messages refer to the same event, the intended additional quantity remains 0.01 BTC, rather than 0.02 BTC.

Now assume the account already holds 0.015 BTC when that event arrives. Buying the entire requested quantity would create 0.025 BTC, exceeding the stated cap. The specification must say whether to reject the entry or reduce it to 0.005 BTC, subject to exchange filters. Either behavior can be tested; silently choosing one cannot.

Finally, suppose the message arrives after its configured expiry. Rejecting it may skip a profitable move, but submitting it would apply a decision to a different market state. Choose expiry from the strategy's timing requirements and measured delays. There is no universal number of seconds suitable for every timeframe.

Separate acceptance from execution

A receiver can acknowledge a valid message before the exchange has accepted or filled an order. Record each transition: received, rejected, queued, submitted, acknowledged, partially filled and completed. Save the exchange order identifier and actual quantity as well as the original request.

If submission times out, first establish whether the exchange accepted the order. Sending another purchase immediately can double exposure. A rejection, an unknown status and a confirmed cancellation require different handling. Reconcile open orders, fills and balances before resuming after a restart. A local “success” log is useful only when it names the event it confirms.

A checklist before connecting capital

Test the failure cases in a simulator or venue test environment that supports the required order behavior:

• Deliver one event twice and confirm one intended action.
• Send a new valid event with the same symbol and side.
• Deliver an expired event and an unknown strategy version.
• Restart between submission and fill confirmation.
• Return a partial fill, insufficient balance and invalid quantity.
• Pause entries while an exchange order remains outstanding.

For every test, record the expected position and remaining orders. Compare paper trading with backtesting before treating matching chart signals as evidence of execution readiness.

Clerix currently illustrates a workflow for preparing strategy rules. TradingView signals, a published webhook endpoint and automatic import of arbitrary Pine Script remain in development. You can manually describe the logic and inspect the Clerix workflow; confirm available capabilities before planning a connection.

Frequently asked questions

Can I paste any Pine Script into Clerix?

Automatic import of arbitrary Pine Script is not currently published. Start by translating the entry, exit, sizing and timing conditions into plain language, then check that each condition has an unambiguous test.

Does “webhook delivered” mean my trade happened?

No. It confirms a delivery event at one point in the chain. Exchange acceptance, executed quantity and final position need separate evidence.

Will pausing the bot remove its open orders?

Do not assume that. Halting new entries, cancelling resting exchange orders and closing positions are separate actions. Verify each behavior explicitly before use.