Webhooks for Security Alerts and Automation

What is a webhook, and how is it different from polling?

A webhook is an HTTP request that a platform sends to a web address you control the moment something happens. Instead of your system repeatedly asking whether anything new has occurred, the platform pushes a small message to you: an HTTP POST carrying a block of data, usually JSON, that describes the event. You register a destination URL once, choose which event types you care about, and from then on the platform does the notifying. The receiving side is simply a web endpoint that accepts the request and reacts.

The alternative is polling, where your software calls the platform's API on a timer and asks for anything new since the last check. Polling is simple and gives you control over timing, but it wastes requests when nothing is happening and adds delay equal to the polling interval. For a security alert that gap matters, because an alarm that waits for the next scheduled check is a late alarm. Webhooks trade a little setup for near immediate delivery and far fewer wasted calls.

What is inside a webhook payload?

A typical webhook has three parts: headers, a signature, and a body. The body is a JSON document. Most platforms include an event type, such as a detection, an alarm raised, or a device going offline, so a single endpoint can route different events differently. Alongside it come identifiers for the site and the camera or device, a timestamp, and often a unique event id. Think of it as a short incident report that a program can read and act on without a person.

Richer events also carry pointers to evidence, usually a snapshot link or a clip link rather than the media itself. Sending links keeps the message small and fast, but the links may expire or require authentication, so your receiver should fetch the media promptly or record the link with its expiry in mind. Timestamps should use a clear standard format with a time zone, ideally universal time, so events from different sites sort correctly. Field names differ between platforms, so read the documentation for each sender you connect.

How do webhook retries, timeouts and duplicates work?

Webhooks travel over HTTPS, so the content is encrypted in transit with TLS and the receiver proves its identity with a certificate. The sender expects a quick answer. A well built receiver checks the request, writes it to a queue or log, and returns a 2xx status such as 200 or 202 right away, then does the slow work, such as opening a ticket or calling another service, asynchronously. Senders typically give up after a timeout measured in seconds, so heavy work before replying invites needless failures.

If the sender does not receive a success response, it normally retries. Good senders use backoff, meaning the gaps between attempts grow, often with a little random jitter so many failures do not retry at the same instant, and they stop after a limit and mark the delivery as failed. Because retries exist, the same event can arrive twice. Receivers must therefore be idempotent: store the event id, and if you see it again, acknowledge it but do not repeat the action. Otherwise one intrusion could create two tickets or trigger two sirens.

How do you secure a webhook endpoint?

Your endpoint is a public URL, so anyone who finds it can send it requests. The standard defense is a signature. The sender and receiver share a secret key, and the sender computes an HMAC, a keyed hash, over the request body and places it in a header. Your receiver recomputes the hash with its copy of the secret and compares the two using a constant time comparison. If they differ, reject the request. Compute it over the raw bytes received, not a re-serialized version, or valid messages will fail.

Add layers around the signature. Many schemes include a timestamp in the signed data so you can reject old messages and block replay attacks. Allow-listing the sender's published source addresses, where they exist, narrows who can reach you. Keep secrets out of the URL, because URLs end up in logs, browser history and monitoring tools; use headers or the signing key instead. Rotate secrets on a schedule, store them in a secrets manager rather than in source code, and treat the payload as untrusted input to validate before it touches a database or a command.

Do webhooks arrive in order, and how do you test them?

Do not assume events arrive in the order they happened. Retries, parallel delivery and different network paths can reorder messages, so an alarm cleared notice might land before the alarm raised notice it refers to. Use the event timestamp or a sequence value, if the sender provides one, to decide which state is newest, and design handlers so late or duplicate messages cannot corrupt your records. Where exact current state matters, treat the webhook as a nudge and confirm by reading the current status from the API.

Test before a live alarm path depends on it. A request inspection tool gives you a temporary public address that records every incoming request, so you can see exactly what the sender posts. Many platforms let you send a test event or replay a past delivery from a log, which is invaluable for debugging. Log the event id, the response you returned and how long you took. Then rehearse failure: take the receiver offline briefly, confirm retries arrive and are handled only once, and set an alert for a run of failed deliveries.

What are webhooks used for, and how do they compare with APIs and ONVIF events?

Common uses follow one pattern: an event arrives and something happens automatically. An alarm can be forwarded to a central station or a video management system, a ticket can be opened in a service desk tool, a relay or light can be switched on, a message can be posted to a team chat channel, or a row can be appended to a spreadsheet for reporting. Each action is a small handler behind the endpoint, and one event can fan out to several of them.

Choosing a method depends on the job. A webhook pushes events to you with low delay and suits alerts. An API is a request and response interface, best for fetching history, listing devices, pulling video or changing settings, and it can be polled when push is unavailable. ONVIF events are a camera level standard, where a device publishes notifications such as motion to subscribers, usually a video system on the local network. Many real integrations combine them: a webhook to alert, then the API to fetch detail.

Automate with care. Sending every raw detection straight to a phone creates noise that people learn to ignore. Route verified or filtered events to people, and let low value events flow to logs and reports. A webhook delivers a message; it does not decide whether the message deserves a human. Decide up front which events page someone, which open a ticket for later, and which are only recorded, and write those rules down so the automation stays trusted.