Futures Webhook Duplicate Orders and Idempotency

First identify the duplicate's origin. TradingView may resend one trigger after a qualifying 5xx; that is repeated delivery of the same intent. Pine may emit once per bar while a broad condition remains true; those are separate sender events even if a human considers them one signal. An operator may click or recreate an alert. Finally, a receiver may retry a broker call after losing its response. Applying one generic cooldown to all four causes hides the actual control failure.

The financial risk is asymmetric. Suppressing a genuine second signal can leave exposure below plan, while submitting a duplicate can double exposure instantly. A safe design records a decision for every logical event and exposes unknown states rather than treating missing confirmation as failure. The exact implementation belongs to the receiving service. Do not add an `idempotencyKey` to a HexTrade payload unless its current docs explicitly support it; undocumented fields should never carry a safety guarantee.

TradingView placeholders such as ticker, timeframe, bar time, and current trigger time can contribute to a human-readable fingerprint. HexTrade documents optional `strategyName`, `alertName`, `note`, and `tags`, so a non-secret correlation label can travel with the request. Use a versioned naming convention such as strategy family, reviewed version, and event timestamp. Keep it concise and deterministic; an operator should be able to compare two records without reconstructing an entire Pine runtime.

Time alone is not always enough. Two strategies can act on the same symbol and second, and one strategy can intentionally scale in more than once. Include the semantic order identity needed by your design, such as an entry or exit role and strategy order ID when available. Conversely, including market price that changes between a manual reconstruction and the original can defeat matching. Define the identity before launch and test intentional same-bar scale-ins so deduplication does not erase valid orders.

`close > movingAverage` can remain true for many bars, while `ta.crossover(close, movingAverage)` is true only on the transition. That simple change often removes apparent duplicates at the source. More complex strategies should record whether they are flat, pending, long, or short and emit only on allowed transitions. Reset the state on a deliberate opposite event or confirmed exit, not merely after an arbitrary number of seconds that can expire while the first order is still working.

Strategies execute at bar close by default unless configured for every tick, and realtime bars can recalculate with fluid values. An `alert()` frequency cannot repair strategy logic that enters repeatedly. Order-fill events may align more closely with the broker emulator's simulated fills, but they still describe TradingView's strategy environment rather than the destination broker. Repainting and every-tick recalculation must be evaluated separately from webhook retry duplicates.

Exactly-once network delivery is not a realistic assumption; exactly-once business effect is approached through identity, atomic state changes, and reconciliation. The receiver should claim an unseen event before side effects, then let concurrent or later arrivals observe the claim. If the broker offers a client order identifier, the receiver can carry a stable value downstream within that broker's documented rules. If it does not, account-side reconciliation becomes even more important after connection loss.

The three-second TradingView deadline adds pressure but does not remove state requirements. A receiver can acknowledge accepted work only after it has retained enough information to continue safely. If a temporary internal failure returns a qualifying 5xx, later deliveries must find the original state. If a broker call times out, hold the event and query or inspect the destination before retrying. Automated retries are safest before external submission and most dangerous after an uncertain one.

Scope matters. A same-account, same-symbol cooldown can suppress rapid repetition, but it may also block a valid scale-in and may not cover another account or symbol. An in-memory daily cap resets on process restart, so it cannot be presented as a permanent ledger. `maxQty` limits each request's size but cannot prevent two separate capped orders. `allowedSymbols` prevents routing to an unexpected instrument but does not determine whether two MNQ events are duplicates.

Configure these controls from the risk policy outward. If the strategy intentionally sends entry and exit events close together, a cooldown requires careful testing so it does not interfere with the exit path. Keep an emergency pause outside the sender, monitor the destination account, and begin with the smallest approved quantity. The product docs are the authority for current fields; avoid assuming undocumented global deduplication, exactly-once guarantees, or persistence semantics.

Build a row for each sender event and each HTTP delivery. If one event has several qualifying retry deliveries but one broker order, delivery idempotency worked. If separate alert events share a continuous Pine condition, fix signal gating. If one receiver event maps to multiple broker submissions, inspect concurrency and timeout recovery. If a human replay created the second order, improve unknown-state escalation and remove informal retry instructions from the runbook.

After reconciliation, reproduce the cause in dry mode or an isolated receiver. Add a regression case for the exact failure: delayed response, qualifying 5xx, simultaneous duplicate, stale snapshot, repeated condition, or missing broker acknowledgement. Review guardrail scope and alert ownership. Only resume with a new versioned alert after the test demonstrates one intended effect, and monitor the first live execution at minimum size.