TradingView algo trading from algorithm to execution works best when the algorithm decides and the infrastructure only transports and executes. Pine Script keeps the rules while the connector keeps the signal path observable.
Your algo may be an indicator with alert conditions, a Pine strategy with simulated orders or custom logic that produces entries and exits. Keeping that logic in TradingView makes it independently testable from the execution bridge.
Historical results do not prove when a realtime webhook will fire. Bar confirmation, intrabar calculations, strategy events and higher-timeframe data can change live timing. Validate the signal event before measuring transport latency.
Once the desired event exists, TradingView can send a webhook. The message should identify action, symbol and execution parameters clearly. NRUNO receives the instruction, validates the supported command and routes it to the cTrader cBot.
Algorithmic systems benefit from fixed spread limits, session windows, maximum signal age, volume limits and position rules. These controls do not create the signal; they define when a technically valid instruction is allowed to proceed.
Record signal time, alert time, webhook receipt, connector dispatch and cTrader result separately. That lets you distinguish strategy delay, transport delay and broker-side execution instead of compressing everything into one misleading latency number.
Primary sources: TradingView webhooks · Webhook security
No. The algorithm remains your TradingView/Pine logic.
Yes, if it generates a reliable realtime alert and suitable message.
No. Realtime timing and execution behaviour need separate testing.