one-line definition
Webhooks are HTTP callbacks that automatically send data from one system to another when a specific event occurs — a push-based alternative to repeatedly polling an API.
formula: No formula. Key metrics: delivery success rate (target: 99%+), average delivery time, and retry rate. Track failed deliveries — they represent data your integration partner never received.
tl;dr
Webhooks are the cheapest integration feature you can build. A single endpoint that fires JSON on key events lets your users connect your product to Zapier, Make, n8n, or their own custom code. It turns your product from a standalone tool into part of a workflow — and workflow tools are much harder to cancel.
Simple definition
Without webhooks, if system B needs data from system A, it has to keep asking: "Anything new? Anything new? Anything new?" That is polling, and it wastes resources on both sides. Webhooks flip the model. You tell system A: "When X happens, POST the data to this URL." Now system A pushes the data the moment the event occurs. No wasted requests. No delay. Your app fires an HTTP POST with a JSON payload to the URL the user configured. The receiving end processes it however they want — send a Slack message, update a spreadsheet, trigger another workflow.
How to calculate it
Track webhook health with these metrics:
- Delivery success rate: Successful deliveries ÷ Total attempted deliveries. Target: 99%+. Below 95% means something is systematically wrong with your delivery infrastructure or your users' endpoints.
- Average delivery time: Time from event occurring to webhook response received. Should be under 5 seconds for most events.
- Retry rate: Retried deliveries ÷ Total deliveries. High retry rates (above 10%) suggest your users' endpoints are flaky or your timeout is too aggressive.
Log every webhook delivery with timestamp, status code, response time, and payload size. This log becomes your debugging lifeline.
Example
You build an invoicing tool. Users keep asking for Slack notifications when invoices are paid. Instead of building a native Slack integration (OAuth, permissions, UI — weeks of work), you add webhooks in 2 days. When an invoice status changes, your system POSTs a JSON payload to whatever URL the user provides. Payload includes: invoice ID, amount, status, customer name, timestamp. Users point this at a Zapier webhook trigger and connect it to Slack in 5 minutes. Three months later, 34% of your paid users have at least one active webhook. Those users have 40% lower churn than non-webhook users — because your tool is now wired into their daily workflow, not sitting in a tab they forget to open.
Related reading
Related terms
- API Latency
- Feature Adoption
- Activation Rate
FAQ
When should I add webhooks to my product?+
When users start asking for integrations. Webhooks are the simplest way to let other tools react to events in your system. If users want Slack notifications when something happens, or need to sync data to their CRM, webhooks are cheaper to build than a full API integration. Start with 3-5 events that cover the most common use cases.
How do I handle failed webhook deliveries?+
Implement exponential backoff retries: retry after 1 minute, 5 minutes, 30 minutes, 2 hours, then 24 hours. Store failed payloads for 72 hours so users can manually retry. Always include a webhook event ID so the receiver can deduplicate. And give users a webhook log in your dashboard — it saves you dozens of support tickets.