A webhook is an outbound HTTP request that a system sends automatically when a specific event happens, rather than waiting to be asked. Where a normal API sits and answers requests, a webhook reverses the direction: when an alarm trips or a threshold is crossed, the SCADA platform calls a URL you registered and delivers the event as it happens. It is sometimes called a reverse API or an HTTP callback, and it is the push-based counterpart to polling a REST endpoint.
Webhook in one line: A webhook is an event-driven outbound HTTP callback. Instead of a client repeatedly asking whether something happened, the source system sends an HTTP request to a preconfigured URL the moment an event occurs, delivering the event data in the payload. In SCADA it is used to push alarms and threshold crossings to other services immediately, without polling.
The defining feature of a webhook is that the source initiates the call. You register a URL and the events you care about, and from then on the system sends an HTTP POST to that URL whenever a matching event occurs, carrying the details in the request body. The receiving service does nothing until the moment something happens, at which point the data arrives on its own. This inverts the usual client-server relationship, which is why webhooks are described as reverse APIs.
Contrast this with REST polling, where a client repeatedly asks is there anything new. Polling wastes requests when nothing has changed and adds latency equal to the polling interval, because a change that happens just after a poll waits until the next one. A webhook has neither problem: there is no wasted traffic and effectively no delay, since the notification is sent the instant the event fires. For events that are rare but urgent, like a critical alarm, that difference is decisive.
The tradeoff is that the receiver must expose an endpoint the source can reach, and it must be available when events fire. Polling puts the client in control of timing and works even behind restrictive firewalls; webhooks put the source in control and require the receiver to be reachable. The two are complementary, and choosing between them depends on who can accept connections and how time-sensitive the event is.
Because a webhook is a single fire-and-forget delivery, reliability requires handling failure. If the receiver is down or returns an error, a good webhook sender retries, usually with increasing backoff between attempts so it does not hammer a struggling service. Retries mean a receiver can be briefly unavailable without losing the event, but they also mean the same event may arrive more than once, so the receiver should process events idempotently and not act twice on a duplicate.
Security is essential because a webhook endpoint accepts unsolicited incoming requests, and anyone who learns the URL could send fake events. The standard defense is signing: the sender computes a signature over the payload using a shared secret and includes it in the request, and the receiver recomputes and compares it before trusting the message. This verifies both that the payload came from the real source and that it was not altered in transit. Without verification, a webhook endpoint is an open door.
Delivery guarantees also depend on ordering and timeouts. If the receiver is slow, the sender may time out and retry, and events may arrive out of order under load. Robust integrations include an event identifier and timestamp so the receiver can deduplicate and reorder, treating the webhook stream as best-effort at-least-once delivery rather than a perfectly ordered feed.
Webhooks shine for the urgent, occasional events that define field operations. A high-pressure alarm on a separator, a tank approaching its high-high level, or a compressor trip are exactly the moments when waiting for the next poll is unacceptable. A webhook lets the SCADA platform push that event immediately to whatever needs to know, without any downstream system having to constantly ask.
Common targets are paging, on-call, and ticketing services. When a critical alarm fires, a webhook can post to an incident management tool that dispatches the on-call technician, or to a ticketing system that opens a work order automatically. Because the event is delivered as structured data, the receiving service can route it by severity, site, or asset. The result is that a field condition becomes an actionable notification in seconds, through systems the operator already uses.
As cloud SCADA for oil and gas and other industries, Merobix can act as the source of these outbound event pushes, complementing the pull-based REST access it also provides. Dashboards and reports pull current state when they need it; webhooks push the rare, time-critical alarms the moment they occur. Together they cover both sides of integration, on-demand queries and immediate event notification, without forcing every consumer to poll for conditions that may almost never happen.
A REST API waits to be called and answers requests, so a client must poll it to learn about changes. A webhook reverses that: the source calls a URL you registered whenever an event occurs, pushing the data to you. REST is pull-based and client-driven; a webhook is push-based and event-driven, which is why it is called a reverse API.
By verifying a signature. The sender computes a signature over the payload using a shared secret and includes it in the request, and the receiver recomputes it and compares before trusting the event. This confirms the message came from the real source and was not altered. Without verification, anyone who knows the URL could send fake events.
A well-designed sender retries, typically with increasing backoff, so a briefly unavailable receiver does not lose the event. Retries can cause the same event to arrive more than once, so the receiver should process events idempotently and use an event identifier to ignore duplicates. This makes webhook delivery reliable at-least-once rather than exactly-once.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.