TradingView is very good at producing alerts, so Quantarya does not try to replace that part first.

Instead, it treats TradingView as one signal source that can send structured payloads into a strategy.

That lets the strategy dashboard focus on what happens after the alert: trade creation, lifecycle events, filters, audit state, and performance review.

A useful webhook payload does not need to be poetic. It needs to be explicit enough that a machine can route it and a human can debug it later.

The important fields are usually plain: strategy ID, symbol, side, entry, stop loss, take profit levels, timeframe, source timestamp, and a reference that lets the alert be matched back to its origin.

When those fields are consistent, the downstream product can become much calmer. Quantarya can create the trade, attach lifecycle events, and explain broker outcomes without relying on guesswork.

Every external signal needs a destination. In Quantarya, that destination is the strategy ID.

The strategy ID gives webhooks and API clients a stable route while the user-facing metadata can change over time.

That means a title can be improved, tags can be cleaned up, and an organization can be adjusted without breaking the webhook that sends trades into the journal.

The hard part is not receiving an alert. The hard part is making the alert survive real account routing: symbol aliases, account permissions, disabled markets, stale tokens, risk limits, and broker-specific instrument IDs.

That is why a missing order should not disappear into Lambda logs. If AUS200, HK50, FRA40, EU50, US30, or XAG receives an alert and no order is placed, Quantarya should record the exact account-level reason.

The journal is useful only when it can explain both success and absence. No trade is still an event if the system was expected to act.

An entry is only the first sentence of a trade. TP events, stop-loss events, manual closes, and edits explain the rest of the story.

Quantarya stores those events so the dashboard can separate open trades, closed trades, deleted audit rows, and lifecycle changes.

That is what turns alerts into a journal instead of a notification archive.

The stop loss and take profit plan should not live only in the TradingView script or in someone's memory. It should be stored with the trade so the lifecycle Lambda can evaluate the plan against market movement.

That gives the dashboard a much better story: planned levels, observed candles, hit sequence, drawdown, drawup, final outcome, and whether the trade was counted as a win or a loss.

For a trading journal, that is the difference between a line item and a reviewable trade.