Webhooks

API polling has the receiving system repeatedly asking the source system "has anything changed?" at fixed intervals (every 1 minute, every 5 minutes). This is inefficient: most polling requests return "no changes," consuming API quota and creating latency (the maximum latency is equal to the polling interval). Webhooks invert the model: the source system notifies the receiver the instant an event occurs, achieving near-zero latency with no wasted API calls. The limitation is reliability: webhooks are "fire and forget" by default — if the receiving system is down, events are lost. Well-designed webhook systems add retry logic with exponential backoff (attempting delivery multiple times over increasing intervals) and delivery logs (visible in the product UI so customers can inspect whether their endpoint received each event and investigate failures).

Webhook failures are among the most complex integration support tickets because they span both sides of the integration. Common scenarios: (1) Endpoint not receiving events — verify the endpoint URL is publicly accessible (not localhost), the server accepted the test event, and the event type is subscribed. (2) HTTP 200 response not returned — the receiving server must return an HTTP 200 status within the timeout window (typically 10–30 seconds); if it takes longer, the webhook platform marks delivery as failed even if the server did eventually process the event. (3) Duplicate events — well-designed webhook consumers should be idempotent (processing the same event twice produces the same result as processing it once) using the event's unique ID to detect and ignore duplicates. (4) Signature verification failing — most SaaS APIs sign webhook payloads with HMAC-SHA256 using a secret key; the customer's code must verify this signature on every received event to prevent spoofed webhook attacks.

Product Ops collaborates with Engineering to design webhook capabilities that minimize support burden and maximize developer satisfaction. Best practices: event type coverage (every meaningful state change in the product should have a corresponding webhook event); event payload design (payloads should include all data needed to act on the event without a follow-up API call — include full object state, not just IDs that require a subsequent GET request); delivery logs UI (a searchable event log in the product dashboard where developers can see every fired event, its delivery status, the server's HTTP response, and a "redeliver" button for manual retry); signature verification (sign every payload with HMAC-SHA256 and document the verification process clearly); and versioned payloads (when the event schema must change, version the payload and support both versions simultaneously during a transition period — never make breaking changes to a webhook payload without advance notice).