Webhook
Updated July 21, 2026
An HTTP callback that sends a real-time notification to an external system when a specific event occurs. The technical mechanism behind push alerts.
Also known as: Reverse API, HTTP callback, Web callback
A webhook is a user-defined HTTP callback: when a specific event happens in a source system, that system automatically sends an outbound HTTP request, usually a POST carrying a JSON payload, to a destination URL the receiver registered in advance. Instead of the receiving application repeatedly asking "is there anything new," the source pushes the notification the instant the event occurs. That inversion is the whole point. It removes the polling loop, cuts latency to near real time, and lets two systems that were never built together exchange events over nothing more than HTTP.
The term was coined by programmer Jeff Lindsay in 2007, in a post titled "Web hook to revolutionize the web." It extends the older programming idea of a "hook", a callback that lets external code attach to and be notified by a running process, into the web and HTTP context. The mechanism of a server making outbound calls on events predates the name, but the named concept traces to that 2007 post.
Today webhooks are the standard event-notification primitive across widely used platforms: GitHub fires them on pushes and pull requests, Stripe on payment events, Shopify on orders, Slack accepts them through incoming-webhook URLs, and Jenkins uses them to trigger builds. In competitive-intelligence tooling they are the plumbing beneath push alerts, the way a change-detection platform delivers a new event to a customer's own systems without asking that customer to poll for it.
How a webhook fires and gets delivered
The flow has three steps. First, the receiver registers a destination URL with the source system, usually through a settings page or an API call, and often subscribes to a specific set of event types. Second, when one of those events occurs, the source system builds a payload describing what happened and sends it as an outbound HTTP request, commonly a POST with a JSON body, to the registered URL. Third, the receiver's server-side endpoint accepts the request, parses the payload, and does whatever the event calls for: writing a record, posting a message, kicking off a job.
Because the endpoint sits at a public URL, most implementations sign the payload. The source computes an HMAC, frequently SHA-256, over the request body using a shared secret and puts the result in a header such as X-Signature or X-Hub-Signature-256. The receiver recomputes the same HMAC and compares, rejecting anything that does not match. This verifies both that the request genuinely came from the expected sender and that the body was not altered in transit.
Webhook vs. API vs. WebSocket
These three get conflated because all move data between systems over HTTP-adjacent channels, but the direction and shape differ. A conventional API is pull-based: the client decides when to call and the server responds to each request. A webhook is push-based: the source system initiates the call the moment an event happens, which is why webhooks are sometimes described informally as a reverse API, since the normally passive server side is the one making the outbound request.
A WebSocket is different again. It is a persistent, bidirectional connection held open between two parties so either side can send low-latency messages at any time, which suits live chat, collaborative editing, or streaming updates. A webhook, by contrast, is a one-shot, one-directional HTTP request fired per event with no connection kept open. The rule of thumb: reach for a webhook when a source needs to notify a receiver of discrete events; reach for a WebSocket when both sides need a continuous two-way stream.
Why webhooks sit under CI push alerts
In competitor-tracking tooling, a webhook is the delivery mechanism behind a push alert. When a platform's own change-detection job finishes, whether a competitor's pricing page changed, a new blog post appeared, or a fresh job posting was detected, it can POST that event straight to a customer's endpoint the moment it lands. That destination is often a Slack incoming-webhook URL, a Zapier or Make trigger, or the customer's own internal service. meertrack, for instance, uses this pattern to move a detected change into a customer's systems without asking them to poll an API on a timer.
Webhooks also matter on the ingestion side. If a tracked source itself exposes webhooks, a monitoring platform can subscribe to those events rather than scraping the source on a fixed schedule, surfacing changes as they are published instead of on the next crawl.
Delivery guarantees and common pitfalls
A plain webhook is a direct point-to-point HTTP call with no intermediary broker and no built-in persistence, which distinguishes it from a Pub/Sub messaging system that queues messages, fans out to many subscribers, and can replay history. That simplicity carries costs. Webhooks generally do not guarantee delivery, ordering, or exactly-once semantics. If the receiver is down or slow when the event fires, the call can fail outright.
Most real implementations bolt reliability on top. The sender adds retry logic with backoff for failed deliveries, which means the receiver may see the same event more than once and must process payloads idempotently, deduplicating on an event ID so a retried delivery does not double-count. Events can also arrive out of order, so receivers should not assume the sequence of requests matches the sequence of underlying events. Treating the endpoint as public and unauthenticated until the HMAC signature is verified is the other frequent oversight.
Stop looking terms up. Start tracking them.
meertrack watches your competitors' websites, pricing, and hiring, then alerts you when something meaningful changes.
Frequently Asked Questions
What is a webhook and how does it work?
A webhook is a user-defined HTTP callback. You register a destination URL with a source system, and when a chosen event occurs there, the system automatically sends an outbound HTTP request, typically a POST with a JSON payload, to that URL. Your endpoint receives the request and acts on it. The effect is a real-time notification pushed to you the moment something happens, with no polling required.
What is the difference between a webhook and an API?
A conventional API is pull-based, meaning your client decides when to call and the server answers each request in turn. A webhook reverses that: the source itself makes the call, delivering data the instant an event fires. This is why people sometimes describe webhooks as a reverse API. Many platforms offer both, an API you query on demand and webhooks that notify you in real time.
Is a webhook push or pull?
Push. With polling, the receiver repeatedly asks the source whether anything is new, at fixed intervals, whether or not anything changed. A webhook flips that around: the source notifies the receiver only when an event actually happens. This eliminates wasted requests and cuts the delay between an event occurring and the receiver learning about it down to near real time.
How do you secure a webhook and verify its signature?
Because a webhook endpoint is a public URL, senders typically sign the payload. The source computes an HMAC, often SHA-256, across the request body with a shared secret and places it in a header like X-Signature or X-Hub-Signature-256. Your endpoint recomputes the same HMAC over the received body and compares the two, rejecting any request whose signatures do not match. This confirms both the sender's identity and that the payload was not tampered with.
Can a webhook fail, and how are failed webhooks handled?
Yes. A webhook is a single HTTP call with no built-in delivery guarantee, so if the receiver is unreachable or errors out, the delivery can fail. Most senders add retry logic with backoff, which means the same event may arrive more than once. Receivers should process events idempotently, deduplicating on an event ID, and should not assume events arrive in order, since ordering is not guaranteed either.
Related terms
An alert delivered proactively to the user (via Slack, email, mobile) rather than requiring them to check a dashboard.
Real-Time AlertsImmediate notifications about critical competitor events: pricing changes, product launches, messaging shifts.
Alert RoutingRules determining which alerts go to which users or channels based on competitor, change type, or severity.
Event-Driven ArchitectureSoftware design pattern where systems detect, process, and react to events in real time as they happen, rather than polling on a fixed schedule.
Real-Time Competitive TrackingContinuous monitoring of competitor activities through automated alerts and ongoing surveillance.
SignalA meaningful, actionable piece of competitive intelligence (e.g., "Competitor X raised their enterprise tier price by 20%"). CI tools exist to surface signals.
Signal-to-Noise Ratio (SNR)The proportion of meaningful alerts to total alerts. High SNR = users trust and act on what they receive; low SNR = alert fatigue and churn.
AI Daily SummariesAutomated intelligence digests that surface key competitor developments without manual review.