Are webhooks applicable to machine notifications?

When a machine goes into alarm, finishes a job, or crosses a threshold that matters, waiting for a custom system to ask "did anything happen yet?" is the slow way to find out. A webhook flips that around: instead of asking, the monitoring platform tells your system the moment something specific occurs. This article covers how webhooks work for machine events, when they're the right tool, and what to build on the receiving end.

Contents:

1. What a webhook is
2. How it works: event to payload to endpoint
3. Webhooks vs. polling vs. MQTT
4. Typical machine events worth a webhook
5. Building a webhook receiver
6. Reliability and retry behavior
7. Security considerations
8. Frequently asked questions
9. Conclusion

What a webhook is

A webhook is an HTTP callback: you register a URL with the monitoring platform, and whenever a specific event occurs, the platform sends an HTTP request (almost always a POST) to that URL, carrying details about what happened. Unlike an API you actively query, a webhook is entirely event-driven from your side — your system doesn't ask anything; it just needs to be ready to receive a request whenever the triggering event occurs.

How it works: event to payload to endpoint

• An event occurs on the monitored side — a machine enters an alarm state, a job completes, a threshold is crossed.
• A payload is constructed, typically JSON, containing relevant details: which machine, what event, a timestamp, and any relevant values (the specific alarm code, the metric that crossed a threshold).
• The platform sends an HTTP request to the URL you've registered, with the payload as the request body.
• Your endpoint processes the request, typically responding quickly with a success status, then handling the actual business logic (creating a ticket, sending a notification, updating a record) either inline or asynchronously.

Webhooks vs. polling vs. MQTT

It's worth situating webhooks against the other approaches covered on this blog. Compared to polling a REST API, webhooks eliminate the wasted requests inherent in repeatedly asking "has anything changed" when most of the time the answer is no — you're notified only when something actually happens. Compared to MQTT, webhooks are simpler to consume (a single HTTP endpoint, no broker or persistent connection to maintain) but are inherently one-to-one — each webhook is configured to notify a specific destination, whereas MQTT naturally supports many independent subscribers to the same stream. Webhooks tend to be the right fit specifically for discrete, occasional events that need to trigger a specific downstream action, rather than continuous telemetry streaming.

Typical machine events worth a webhook

• Alarm triggered or cleared — useful for feeding maintenance ticketing systems or alerting tools automatically rather than requiring someone to notice a dashboard.
• Machine state change (running to stopped, stopped to running) — useful for triggering downstream logic like updating a production tracking system in real time.
• Job or cycle completion — useful for advancing a workflow, such as marking a work order complete or triggering the next step in a process.
• Threshold crossed (spindle load exceeding a defined limit, a counter reaching a target) — useful for triggering notifications or automated responses tied to specific operational limits.

Not every signal needs a webhook; continuous data like spindle load trends over time is generally a poor fit compared to streaming or polling — webhooks are best reserved for genuinely discrete, actionable events.

Building a webhook receiver

• Respond quickly, process asynchronously. Most webhook senders expect a fast response (often within a few seconds); heavy processing should be queued and handled separately rather than done inline before responding.
• Design for idempotency. The same event might be delivered more than once due to retry behavior (covered below); a receiver that can safely handle a duplicate delivery without creating duplicate downstream effects is much more robust.
• Validate the payload before acting on it. Don't assume every field will always be present or well-formed; defensive parsing avoids receiver crashes on unexpected payload variations.
• Log incoming events. Keeping a record of received webhooks, even briefly, makes it much easier to troubleshoot when a downstream action didn't happen as expected.

Reliability and retry behavior

Webhook delivery isn't inherently guaranteed — if your endpoint is down, slow to respond, or returns an error, the sending platform's behavior determines what happens next. Most reasonably designed systems will retry failed deliveries with some backoff strategy, but retry policies (how many attempts, how long they're spaced out, whether failed events are eventually dropped or logged for manual recovery) vary. It's worth understanding a specific platform's retry behavior before relying entirely on webhooks for anything where a missed event would be a real problem — and, where that risk exists, pairing webhooks with a periodic reconciliation check against the API is a reasonable safeguard.

Security considerations

• Use HTTPS endpoints only. Sending event data over unencrypted HTTP exposes it in transit; any webhook receiver should be reachable only over TLS.
• Verify payload authenticity. Many webhook implementations include a signature (often an HMAC) in the request headers, computed from a shared secret, so the receiver can confirm a request genuinely came from the expected sender rather than being spoofed.
• Restrict what the endpoint accepts. A webhook receiver should validate the source and structure of incoming requests rather than blindly trusting and executing whatever arrives at the URL.
• Keep the endpoint URL and any shared secret confidential. Treat webhook configuration credentials with the same care as an API key, since anyone who obtains them could potentially send fabricated events.

Frequently asked questions

What happens if my webhook endpoint is temporarily unreachable?

This depends on the sending platform's retry policy. Reasonably designed systems retry failed deliveries for some period before giving up; it's worth confirming the specific retry behavior and, for critical events, having a fallback reconciliation process against the API.

Can the same event trigger multiple webhooks to different destinations?

This depends on the platform, but many support registering multiple webhook endpoints for the same event type, allowing one event to notify several downstream systems independently.

How do I know a webhook request is genuinely from the monitoring platform and not spoofed?

Through payload signature verification, typically an HMAC signature included in a request header, computed using a shared secret known only to the platform and your receiver. Always verify this signature before trusting and acting on a webhook payload.

Should I use webhooks for continuous data like spindle load, or only for discrete events?

Webhooks are best suited to discrete, occasional events. For continuous streaming data, MQTT or a similar streaming approach is generally a better fit, since sending a webhook for every single continuous reading would be inefficient and unnecessary.

Conclusion

Webhooks are the right tool specifically for reacting immediately to discrete machine events — alarms, state changes, completed jobs — without the overhead of constant polling. Getting them right on the receiving end means designing for idempotency and fast responses, verifying payload authenticity, and understanding the sending platform's retry behavior well enough to know when a fallback safeguard is worth building alongside them.

Related articles:

• Streaming Machine Data with MQTT
• Feeding Machine Data into Custom Systems via API
• CNC Data Acquisition: Architecture Basics
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.