Connect TradingView to a Trade Journal via Webhooks

TradingView knows your setup better than any broker ever will — the levels, the indicators, the exact bar you decided on. But it doesn’t hold your positions, so if you don’t capture that context at the moment of the signal, it’s gone. Webhooks are how you catch it.

TradingView is charts, not a broker — what that means for journaling

TradingView is a charting and alerting platform. Unless you’ve connected a supported broker through it, it does not know your fills, your size, or your realised P&L — that all lives at your prop firm’s platform. This split is the single most important thing to understand before you try to journal from it:

Your reasoning, levels and signal live in TradingView.
Your actual execution lives at the broker.

A complete trade journal needs both halves. TradingView can’t be your only source of truth for what happened to the account — but it is the best possible source for why you acted. The trick is to capture the “why” at the instant it exists and reconcile it against the broker’s “what” later.

Webhook alerts as a journaling trigger

TradingView alerts can fire a webhook — an HTTP POST to a URL of your choosing — the moment a condition is met. Most traders use webhooks to route signals into execution. They’re just as useful pointed at a journal: every time your setup triggers, an alert can ship a timestamped record of the signal to your log automatically, whether or not you end up taking the trade.

That last part is quietly valuable. A signal you skipped is data too — it tells you how your setup would have performed and whether your discretionary filtering is helping or hurting. Manual journaling never captures the trades you didn’t take; a webhook does, for free.

To set one up you enable “Webhook URL” on the alert, paste your journal’s ingestion endpoint, and write the alert message as a structured payload rather than prose.

Structuring alert payloads into trade records

An alert that just says “Buy signal on EURUSD” is nearly useless later. Structure the message as JSON so it maps cleanly onto a trade record. Use TradingView’s placeholder variables so each fire carries live values:

{
  "symbol": "{{ticker}}",
  "action": "entry",
  "direction": "long",
  "price": {{close}},
  "time": "{{timenow}}",
  "setup": "pullback-20ema",
  "interval": "{{interval}}"
}

The fields that make a payload actually reviewable:

Symbol and direction — non-negotiable.
Price and time — {{close}} and {{timenow}} stamp the signal precisely.
Setup tag — hardcode it per alert so every fire is pre-categorised. This is what lets you compute expectancy per setup later.
Action — entry, exit, or stop-move, so a single alert stream can reconstruct the trade’s lifecycle.

Consistent, machine-readable payloads are the whole game. A journal that receives clean JSON can group by setup and tally results without you touching a spreadsheet — the kind of automation a Notion database or a manual Tradezella entry can’t match because they depend on you typing it in after the fact.

Reconciling TradingView signals with actual broker fills

Here’s the honest limitation: a webhook fires on your signal, not on your fill. The alert says “long EURUSD at 1.0850,” but you may have been filled at 1.0853 with slippage, or not filled at all, or sized differently than planned. If you journal only the TradingView side, your numbers will drift from reality — and on a prop account, reality is what gets audited.

So treat the webhook as the thesis record and reconcile it against the broker’s fill data:

Match each signal to its actual execution by symbol and timestamp.
Correct entry/exit price and size to the real fills, not the alert’s snapshot.
Flag signals that fired but were never taken — that’s your discretionary-filter data.

The strongest setup is one where the broker fills flow into the journal automatically and the TradingView thesis attaches to them — so every executed trade carries both its real P&L and the reasoning that produced it. Shibiki’s auto-journaling ingests the broker side directly, and the signal payload becomes the “why” layered on top. From that combined record its edge-health view computes your live win rate and expectancy inside a Wilson confidence interval, so an idea isn’t crowned a proven edge until the sample size actually supports it.

Keeping paper and live journals separate

If you run alerts on paper-traded or backtested ideas alongside live ones — and you should — keep the two streams strictly separate. Mixing a promising paper setup into your live expectancy is how traders talk themselves into risking real prop capital on an unproven edge.

Practical separation:

Add an environment field (paper / live) to every payload.
Never let paper results influence live position sizing until the idea has a live sample behind it.
Promote a setup from paper to live deliberately, and mark the date, so you can compare how it behaved in each.

Feed the live stream into an expectancy calculator once you have a real sample, and let the paper stream stay a lab. The webhook plumbing is identical; the discipline is in never letting the two blur.