NRUNO Trading Automation Wiki · Question 92

How should out-of-order webhook signals be handled?

Webhooks, Delivery & ReliabilityLast reviewed: 25 Aug 2026
Short answer

Where sequence matters, carry identity, timestamps and/or sequence numbers. Reject, defer or reconcile stale/out-of-order commands instead of processing them blindly.

What this means in practice

Where sequence matters, carry identity, timestamps and/or sequence numbers. Reject, defer or reconcile stale/out-of-order commands instead of processing them blindly. This page is specifically about “How should out-of-order webhook signals be handled?”, so each scenario below is explained by its own mechanism instead of sharing one generic diagnosis.

Real-world scenarios

Scenario A — Sequence 102 before 101

Correlate related commands with identity plus sequence/time and current cTrader state. A late command that no longer matches the position should be rejected or reconciled, not reinterpreted as a fresh opposite trade. For Scenario A — Sequence 102 before 101 on question 92, use that evidence specifically to answer “How should out-of-order webhook signals be handled?”; keep it separate from the evidence for the other scenarios on this page.

Scenario B — Delayed BUY

Correlate related commands with identity plus sequence/time and current cTrader state. A late command that no longer matches the position should be rejected or reconciled, not reinterpreted as a fresh opposite trade. For Scenario B — Delayed BUY on question 92, use that evidence specifically to answer “How should out-of-order webhook signals be handled?”; keep it separate from the evidence for the other scenarios on this page.

Scenario C — Reconnect queue

Reconnect is a reconciliation event. Re-read actual cTrader positions and pending orders first, then decide whether queued commands remain valid. Expire stale entries and make recovery idempotent. For Scenario C — Reconnect queue on question 92, use that evidence specifically to answer “How should out-of-order webhook signals be handled?”; keep it separate from the evidence for the other scenarios on this page.

What to check

  • TradingView alert log and exact send time
  • HTTP status and receiver timestamp
  • validated payload plus signal ID
  • cTrader result only after transport is proven

Practical rule

For “How should out-of-order webhook signals be handled?”, change only the first layer whose evidence no longer matches the intended action. Preserve signal identity, timestamps and final cTrader state, and reproduce execution-affecting changes on demo before live use.

Decision summary

Direct answer: Where sequence matters, carry identity, timestamps and/or sequence numbers. Reject, defer or reconcile stale/out-of-order commands instead of processing them blindly.

Next action: Match the observed evidence to one scenario above, test that mechanism independently on demo and keep the result traceable with one signal ID.

Primary sources

Need a TradingView → cTrader execution route?

NRUNO routes your TradingView instructions to cTrader. Your strategy and signal logic remain yours.