Webhook

In plain language

Instead of repeatedly asking whether something changed, a receiving system gives the provider an address to notify. Webhooks reduce unnecessary polling, but they are a delivery mechanism—not a guarantee that an event will be processed exactly once.

Why it matters to a business

• Supports timely automation after payments, status changes, or record updates
• Reduces repeated polling where a provider offers event notifications
• Creates a clear event boundary between independently operated systems

How it works

1. 1The consumer registers an HTTPS endpoint.
2. 2The provider sends an event payload when a subscribed event occurs.
3. 3The consumer verifies authenticity, records receipt, and responds quickly.
4. 4Durable processing, retries, deduplication, and reconciliation handle failures.

Common use cases

• Updating an order after payment confirmation
• Starting fulfillment when an approval is completed
• Synchronizing a CRM after a customer update
• Recording delivery or messaging status

Important implementation decisions

• Signature verification and secret rotation
• Durable receipt before complex processing
• Idempotency key and duplicate-event handling
• Retry, replay, alerting, and reconciliation policy

Common mistakes and misconceptions

• Doing long-running work before acknowledging delivery
• Assuming events arrive once or in order
• Trusting payloads without provider-specific signature verification

Limitations and trade-offs