What Is a Webhook?

Webhooks are the connective tissue of most retail trading automation, and their properties determine what kind of system you can build on them.

The mechanic

You give a service a URL. When the triggering event occurs, the service sends an HTTP POST to that URL carrying whatever data it was configured to include.

Your endpoint receives it, decides what it means, and does something. That is the whole mechanism — a single request, one direction, initiated by the sender.

The name comes from the idea of hooking into an event stream over the web. Nothing about it is trading-specific; the same pattern connects payment processors, deployment pipelines, and messaging platforms.

Push versus pull

The distinction that determines the architecture.

Polling means repeatedly asking whether something has changed. Simple, and it costs a request every time you ask regardless of whether anything happened, and your reaction is bounded by how often you ask.

Webhooks push. You learn about the event when it occurs, with no wasted requests and no polling interval limiting your reaction time.

The trade is availability. A polling client that was offline catches up on its next request. A webhook sent to an endpoint that was down is simply gone, because the sender fired once and moved on.

That asymmetry is the single most important property to design around.

What the sender controls

Webhook senders impose constraints, and the receiver has to live within them.

Timeout. Senders will not wait indefinitely for a response. Some allow only a few seconds, which means a handler that authenticates to a broker, constructs an order, submits it, and waits for confirmation before responding will exceed the budget under normal conditions.

The standard structure is to acknowledge immediately and process behind the response. Validate, record, return success, then do the work.

Retry policy. Some senders retry failed deliveries; some do not. A sender with no retry means every delivery failure is a permanently lost event, which changes what you can safely depend on a webhook for.

Network constraints. Senders often restrict which ports they will send to and may not support IPv6, so an endpoint that works fine in testing can be unreachable from the sender.

Read the sender's documentation on these three before building. They are not negotiable and they shape the design.

Authentication, or the absence of it

A webhook endpoint is a publicly reachable URL that anyone can send a request to. Something has to establish that a given request is legitimate.

Signing is the strong approach. The sender computes a cryptographic signature over the payload using a shared secret and includes it in a header. The receiver recomputes it and compares. This proves both origin and that the body was not modified.

A shared secret in the payload is the common substitute where signing is not offered. It proves the sender knew the secret and nothing else — the request can be captured and replayed verbatim, and it carries no integrity guarantee.

Not every sender signs. Where signing is unavailable, protection has to be layered: HTTPS without exception, a long random secret compared in constant time, an unguessable URL path, timestamp rejection to bound replay, and IP allowlisting where the sender publishes its addresses.

None of that is equivalent to signing. It is what you do when signing is not on offer.

Duplicates and ordering

Two properties that surprise people building their first receiver.

Duplicates happen. Retries, misconfiguration, and replays all produce repeated deliveries, and a repeat is byte-identical to the original. The defence is an idempotency key: a unique identifier per event, recorded durably before acting, checked before acting again. Generate it at the sender where possible, because a receiver generating its own gives two copies of one event two different keys.

Order is not guaranteed. Two events sent in sequence can arrive out of order. In trading that means an exit can arrive before its entry, producing incoherent state. Sequence numbers and per-instrument serialisation are the usual answers.

Where webhooks fit and where they do not

They fit event notification — something happened, act on it. Signals, alerts, and state changes.

They do not fit anything requiring guaranteed delivery. If a message must arrive, a fire-and-forget POST is the wrong mechanism, and no amount of receiver engineering fixes a sender that does not retry.

The practical consequence in trading is specific: an exit that must happen should rest at the broker rather than depending on a future webhook arriving. Entries can tolerate a missed signal. Exits often cannot.

What this means for automation

Treat the payload as untrusted input. It arrives over a channel you do not control from a sender you may not be able to verify. It should never determine position size — compute that from your own capital and bound it server-side.

Log the raw body before parsing. Senders generally keep no record you can inspect, so if you did not capture it, the evidence is gone.

Keep the acknowledgement fast. Responding inside the sender's timeout while broker work continues behind it is a high-concurrency I/O pattern rather than a code-optimisation one.

Run it somewhere that stays up. An endpoint that is down loses events permanently. On a self-hosted deployment that availability is your responsibility, along with the network policy and the alerting.

The honest limits

A webhook is a delivery mechanism, not a system. It carries an event and takes no responsibility for what happens next.

Signal loss is designed into any sender that does not retry, and building as though it will not happen is the actual error rather than the loss itself.

And a working pipeline says nothing about whether the signals are worth acting on. Position sizing bounds what a bad signal costs — capital divided by twenty as the ceiling on any single position, under the divide-by-20 rule.

Frequently asked questions

What is a webhook? An HTTP request one system sends to another when an event occurs — a push notification between servers rather than something you request.

How is a webhook different from an API? Direction. With an API you ask for data; with a webhook the sender tells you when something happens.

Are webhooks reliable? Delivery depends on the sender's retry policy and your endpoint being available. Some senders make a single attempt with no retry.

How do I secure a webhook endpoint? Signature verification where offered. Otherwise layer HTTPS, a long random secret checked in constant time, an idempotency key, timestamp rejection, and IP allowlisting.

Why did my webhook not arrive? Commonly an endpoint that was unreachable, a port the sender does not support, or a response that exceeded the sender's timeout.

Disclaimer: This article is educational content about trading mechanics and software. It is not investment advice, financial advice, tax advice, legal advice, or a recommendation to buy or sell any security, nor a recommendation of any strategy, position structure, or order type. Any instruments, figures, or examples are used solely to illustrate mechanics. Options and futures trading involve substantial risk of loss and are not suitable for all investors; selling options can produce losses substantially greater than the premium received. Please read Characteristics and Risks of Standardized Options before trading options. Automated trading carries additional risks including software defects, connectivity failures, broker API changes, and outages that may prevent orders from being placed, modified, or cancelled. Past performance does not indicate future results, and no configuration, structure, position-sizing rule, or risk setting can guarantee a profit or prevent a loss.

StaxInvesting LLC sells self-hosted trading software. It is not a broker-dealer, investment adviser, or financial institution, and it does not manage accounts, hold member funds, place trades on behalf of members, or access member brokerage accounts. Members run the software in their own cloud environment, connect their own brokerage accounts under their own credentials, and are solely responsible for their configuration, their credential security, and every trade executed in their account. Broker order handling, approval levels, and available features vary; verify against your broker's current documentation. Consult a qualified financial adviser and tax professional regarding your individual circumstances.