How Trading Webhooks Actually Work

At its core, a webhook is simply a way for one system to send a message to another system when something happens.

In a trading automation stack, that message might begin with a strategy detecting an entry and eventually end with an order reaching a trading account.

But those are not the same event.

Between “my strategy found a trade” and “an order was executed” are several separate steps — and understanding those steps makes automated trading much easier to reason about, troubleshoot and control.

A webhook is only one part of the trip

A useful way to understand trading automation is to stop thinking of it as one big “bot.”

It is usually a chain of systems, with each layer responsible for something different.

1. Signal Source — “I see a setup.”

The process starts with something capable of evaluating market conditions.

That could be a TradingView indicator, a Pine Script strategy, a third-party trading system, or another application capable of producing a trade signal.

Its job is not necessarily to place a trade. Its first job is simply to determine that a particular condition has occurred.

For example:

At this point, nothing necessarily exists at the broker. The strategy has made a decision. That decision still needs to travel somewhere.

2. Alert — “The conditions have been met.”

An alert turns the strategy condition into an event.

With TradingView, users create running alerts from the chart interface. Pine Script can define conditions capable of triggering alerts, but the script itself does not create the running alert.

Once created, TradingView runs the alert on its servers.

3. Webhook — “Here is the message.”

When the alert fires, a webhook can send information to another application.

The webhook itself is not the strategy. It is not the broker. And it is not the trade.

It is the delivery mechanism carrying a message between systems.

TradingView webhook alerts send an HTTP POST request to the URL configured in the alert.

A simplified payload might conceptually look like this — illustrative only, not a required TradingView or third-party schema:

{
  "ticker": "MNQ",
  "action": "buy",
  "entry": 21450,
  "stop": 21425,
  "target": 21500
}

If the TradingView alert message is valid JSON, TradingView sends it using the application/json content type. Otherwise it is sent as plain text.

The receiving system has to understand whatever message format is being sent. That is why integrations need an agreed payload structure.

TradingView also notes that its alerts are not designed for automated trading. A webhook can carry a message. It does not make TradingView the broker, the execution layer, or an endorsement of any particular stack.

4. Middleware — “Should this instruction go through?”

This is the layer people often skip.

A basic automation might look like:

That works conceptually, but it means the execution system receives whatever the signal source sends.

Middleware creates another decision point:

Instead of blindly forwarding the incoming instruction, middleware can inspect it first.

Depending on the system, that layer could:

• validate the incoming message;
• reject malformed or unsupported signals;
• calculate position size;
• enforce configured limits;
• modify supported fields;
• log what happened;
• reject the instruction; or
• forward an approved instruction.

Built by Spooky

Poltergeist

IN DEVELOPMENT

Poltergeist is Spooky Trades' middleware layer. Its purpose is simple: put intelligence between the signal and execution.

Spooky's current implementation places Poltergeist between Wraith and Ghost:

Wraith→

Poltergeist→

Ghost

Poltergeist can inspect supported incoming signals before they reach the execution layer. It does not generate the signal, place the order, or guarantee a fill.

Meet Poltergeist

5. Execution — “Turn the instruction into an order.”

Once an instruction reaches the execution layer, something still has to translate that instruction into whatever the destination trading infrastructure understands.

That is a different responsibility from generating the original signal. Keeping those responsibilities separate is useful.

The signal source decides that an opportunity exists. Middleware decides whether and how the instruction should continue. The execution layer handles getting the approved instruction toward the trading platform or account.

In Spooky's current stack, Ghost performs this role. Ghost is part of the QuantCrawler ecosystem — not a Spooky Trades product.

QuantCrawler link may earn Spooky Trades a commission at no extra cost to you.

6. Trade Copier — “Where else should this execution go?”

A trade copier solves another problem entirely.

Instead of deciding whether a setup is valid, it distributes trading activity according to the copier's configuration.

Conceptually:

This is why “webhook automation” and “trade copying” should not be treated as the same thing.

One transports an instruction through an automation chain. The other distributes execution across configured accounts.

Traders remain responsible for ensuring any copying or automation arrangement complies with the rules of their broker, prop firm, platform, or other account provider. This guide does not certify any particular setup.

What this looks like on Spooky’s desk

This is the implementation Spooky currently uses, but it is not the only possible webhook architecture.

The more general pattern is:

That distinction matters because Poltergeist is being designed as middleware rather than as a Wraith strategy or a replacement for Ghost.

Integrations can require their own adapters, schemas or configuration. Wraith and Poltergeist are built by Spooky. Ghost and Trade Copier sit in the QuantCrawler ecosystem.

Affiliate disclosure: this QuantCrawler link may earn Spooky Trades a commission at no extra cost to you.

Where webhook automation actually breaks

When an automated trade does something unexpected, “the bot failed” is not a very useful diagnosis.

The failure usually happened at a particular layer.

The signal was wrong

The strategy generated something you did not want. That is strategy logic, not a webhook problem.

The alert was stale

The strategy or its settings changed, but an existing TradingView alert was created from an older snapshot.

The payload was wrong

The alert fired, but the receiving application got missing, malformed or unsupported data.

The webhook never arrived

Webhook delivery is not guaranteed. TradingView states that webhooks can occasionally fail to reach their destination and provides delivery status in the alert log.

The receiver took too long

TradingView currently cancels webhook requests if the remote server takes longer than three seconds to process the request.

Webhook endpoints should generally acknowledge or process requests promptly rather than assuming unlimited processing time.

The receiver rejected it

Authentication problems, invalid data, unavailable endpoints and server errors can all prevent a webhook from being processed.

The signal arrived — but you no longer wanted the trade

This is the interesting one.

A signal can be technically valid while the resulting trade is no longer desirable under your execution rules.

Perhaps the configured risk is too high. Perhaps the signal contains unsupported values. Perhaps execution conditions have changed.

This is where an intermediate control layer becomes useful.

Instead of asking only:

“Did the strategy fire?”

you can also ask:

“Should this instruction still reach execution?”

That is the problem Poltergeist is intended to address. It does not prevent losses, guarantee fills, or make a strategy better. It gives the instruction one last inspection before it continues.

Treat webhook URLs like infrastructure

Webhook messages can contain trading instructions, and webhook endpoints expose part of an automation system to the internet.

They should therefore be treated as infrastructure rather than casually shared links.

TradingView explicitly warns users not to place sensitive information such as login credentials or passwords in webhook URLs or messages.

Use authenticated HTTPS endpoints where supported, and never expose brokerage passwords, API secrets, private webhook URLs or other credentials in public examples, screenshots or guides.

TradingView also requires two-factor authentication to use webhook alerts.

The mental model that makes all of this easier

Once those responsibilities are separated, automated trading becomes much easier to understand.

Instead of one mysterious black box, you have a pipeline. And every stage can be observed, tested and improved independently.

The ghost in the middle

Spooky Trades started building Poltergeist because the space between signal generation and execution turned out to be useful.

Rather than asking an execution system to blindly accept every supported signal exactly as it arrives, Poltergeist introduces a place to inspect that instruction first.

It is still in development.

But the underlying idea is simple:

Sources & Further Reading

TradingView-specific details in this guide are drawn from TradingView's official documentation:

• TradingView — How to configure webhook alerts
• TradingView Pine Script — Alerts
• TradingView — What do errors mean when sending webhooks?
• TradingView — Using credentials for webhooks

This guide was last reviewed August 15, 2026. Platform behavior can change. Treat the linked documentation as the current authority.