Webhook

In a classic integration the client asks "is there anything new" at intervals; that is polling. A webhook inverts it: the server notifies the client when an event happens.

The difference shows in both latency and cost. With polling, the delay between event and detection is up to the interval, and most requests come back empty. With a webhook the notification is immediate and there are no wasted requests.

In exchange, a webhook requires a reachable endpoint on the receiving side, which limits feasibility in network-isolated deployments.

The most overlooked aspect of webhooks is delivery guarantee. If the receiver is temporarily unreachable a notification can be lost, so the sender must retry and the receiver must assume it may get the same notification twice.

That requires idempotency on the receiving side: processing the same event twice must not change the outcome. Otherwise a repeated notification produces duplicate records or duplicate actions.

Ordering is usually not guaranteed either. Events may not arrive in the order they were sent, so the receiver should use the event’s own timestamp to prevent an older notification from overwriting a newer one.

Because a webhook endpoint is exposed to the internet, it requires verification. The sender’s identity should be confirmed with a signature or shared secret; otherwise anyone can post a forged notification.

A second measure is having the endpoint only accept notifications rather than triggering business logic directly. Queueing the notification for asynchronous processing avoids timeouts on slow work and narrows the attack surface.

The third is not trusting notification content blindly. Verifying against the source system is a safer pattern than using incoming data directly.