What should happen after a webhook receiver returns HTTP 200?

Why this matters

Reliable automation separates signal calculation, TradingView alert generation, webhook transport, connector processing, cTrader execution and broker outcome. A user should be able to identify the last stage that definitely succeeded and inspect the next one.

Automation chain

Pine / TradingView logic
→ server-side alert
→ webhook delivery
→ NRUNO validation/routing
→ cTrader execution
→ broker result
→ final order/position

Real-world scenarios

Scenario A — 200 then broker rejects

How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.

Scenario B — 200 then async success

How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.

Scenario C — 200 for known duplicate

How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.

Deep diagnostic workflow

1. Record symbol, timeframe, UTC timestamp, alert name and intended action.
2. Prove the TradingView trigger using the alert log.
3. Record webhook delivery status and HTTP result.
4. Record receiver validation, normalized command and signal ID.
5. Record cTrader dispatch and exact TradeResult/error.
6. Verify the final position/order state.
7. Change one variable at a time and retest on demo.

Worked example — EURUSD

A EURUSD long signal should be traceable from the TradingView event through the final cTrader result. If TradingView fired at 10:00:00, NRUNO received at 10:00:00.120, dispatched at 10:00:00.130 and cTrader rejected at 10:00:00.180 with BadVolume, the webhook was not the failure. The execution parameters were.

Worked example — fast 1-minute automation

A trader sees a live signal during an open candle but later cannot reproduce it historically. First determine whether the script intentionally used realtime updates. Only after separating Pine timing from network and broker timing should latency or connector behavior be blamed.

Reliability / failure policy

• Every signal gets a unique lifecycle: received → validated → dispatched → accepted/rejected.
• Duplicate delivery must be safe.
• Transport retry and broker retry are different decisions.
• Stale signals need an explicit expiry policy.
• Broker errors should remain visible and exact.
• Never silently transform an invalid command into a different trade.
• Demo testing must include failure paths, not only successful entries.

NRUNO implication

NRUNO is the execution connector, not the signal generator. For this topic its UI should distinguish webhook received, validation rejected, duplicate ignored, cTrader unavailable, dispatched, broker accepted and broker rejected. That distinction also makes support questions reusable as future Wiki scenarios.