Webhook

Webhooks make connections between tools feel instant and cheap. A payment provider tells your database about a new subscription the second it happens. A failed charge can trigger a follow-up email immediately, instead of being noticed days later. There is no wasteful repeated checking.

The catch is reliability. A webhook can arrive twice, arrive out of order, or be retried after a timeout. Anyone building one, including with an AI tool, needs to design for that.

• Check whether an event has already been processed before acting. Store each event's id and skip repeats.
• Verify the sender's signature on every message. Without this, anyone who finds the address can send fake events.
• Cope with out-of-order events, for example a "cancelled" notice arriving before "created".
• Reply quickly with a success code and do the heavy work afterwards, so the sender does not retry needlessly.
• Log every event received, so a missing update can be traced to a webhook that failed or never arrived.

A webhook reverses the usual direction of a request. Normally your software asks another service "has anything changed?". With a webhook, you give the other service a web address in advance, and it sends a message to that address the instant an event occurs: a payment succeeds, a form is submitted, a deal changes stage. The receiving code then reacts. This is sometimes called a push, in contrast to polling, where you ask again and again.