What a webhook does

A webhook is a communication sent by a system to a configured address when an event occurs. It allows the recipient to react without continually checking for updates. It is not necessarily an email or an alert visible to the worker. It is an application-to-application mechanism requiring agreement on content and behaviour.

An event and a state are different

A notification may indicate that a preventive action changed without containing all its current information. The recipient may need to query its state through an authorised API. It must also know whether the event describes creation, modification or deletion. The design connects with traceability in preventive management to interpret what happened.

Verifying the sender

The receiver must verify communication authenticity using the prescribed mechanism, as well as using a protected channel. Trusting the received text or an identifier anyone can copy is insufficient. Included personal data are limited and who configures destinations is controlled. Sending preventive information to the wrong URL can expose it outside the authorised process.

Preparing for duplicates and delays

The network may fail and the sender may repeat a delivery. How to recognise processed events and recover failures must therefore be defined. Not every provider guarantees order, single delivery or unlimited retries. Conditions are checked in their documentation and tested before the notification is used to initiate important actions.

Integration example

In a hypothetical example, closing an inspection generates an event to update a monitoring dashboard. The receiver validates the message, identifies the inspection and avoids counting two closures if a duplicate arrives. If notification fails, a reconciliation procedure detects the difference. Testing checks the final data, not merely that a request was sent.

Not a replacement for emergency communication

A management webhook should not be assumed suitable for critical safety alerts without specific design, guarantees and alternatives. Responsibilities, timing and incident follow-up are agreed. Records should enable error investigation without storing credentials or unnecessary sensitive information. The integration is maintained and reviewed when participating systems change.