Webhook

The difference from a conventional API query is direction. With polling, your system asks every minute whether anything changed and in the vast majority of cases gets a no. With a webhook, nothing happens until the event occurs, and then exactly one message arrives. That saves calls and cuts reaction time from minutes to seconds.

In practice you register a URL in the source system and from that moment receive an HTTP POST with a JSON body for every matching event. A form is submitted, a deal changes stage, a payment clears: in each case the incoming call starts a process on your side. In n8n, the webhook trigger is by far the most common entry point into a workflow.

Three things go wrong regularly. First, there is no delivery guarantee: if the receiver is unreachable at the decisive moment, the event is lost depending on the provider. Second, calls are delivered twice, so processing has to be idempotent, otherwise you create the same record twice. Third, the receiving URL is publicly reachable. Without signature verification, anyone who knows the address can trigger your process and feed it fabricated data.

For operations this boils down to a short list: verify the signature or token on every call, log incoming events before processing them, and provide a retry path for failed processing. Webhooks are the simplest integration mechanism available. The simplicity ends precisely at delivery.