A webhook is a mechanism by which one application automatically sends a real-time HTTP notification to another application when a specific event occurs. The sending system “calls back” to a pre-configured URL the moment an event fires — a payment is completed, a form is submitted, or a record is updated. There is no need for the receiving application to repeatedly poll for new data. Webhooks are the foundational pattern for event-driven SaaS integrations.
How It Works
Setting up a webhook involves three components:
1. The endpoint URL: The receiving application exposes a publicly accessible HTTPS URL — the webhook endpoint — that accepts POST requests. This is typically a serverless function, an API route, or a middleware service.
2. The event subscription: In the sending application’s developer settings, you register the endpoint URL and select which events should trigger a notification — for example, payment.completed, user.created, or ticket.status_changed.
3. The payload delivery: When the subscribed event fires, the sending application constructs a JSON payload describing the event and makes an HTTP POST request to the registered endpoint. The payload typically includes the event type, a timestamp, and the relevant data object.
{
"event": "payment.completed",
"timestamp": "2026-06-11T09:14:00Z",
"data": {
"payment_id": "pay_abc123",
"amount": 4900,
"currency": "USD",
"customer_id": "cus_xyz789"
}
}The receiving server must respond with an HTTP 200 status code within a timeout window (commonly 5–30 seconds) to confirm receipt. If it does not, the sender retries delivery according to its retry policy. The receiving server should acknowledge receipt immediately and process the payload asynchronously to avoid timeouts under load.
Why It Matters for B2B
Webhooks are the practical backbone of SaaS-to-SaaS automation in B2B environments.
Real-time workflows: Polling an API every minute to check for new orders, tickets, or payments wastes API quota and introduces latency. A webhook delivers the event in milliseconds. For time-sensitive workflows — fraud alerts, SLA breach notifications, inventory depletion — this latency gap is commercially significant.
Reduced API rate limit consumption: Enterprise SaaS plans often cap API call volumes. Replacing polling loops with webhook subscriptions frees that quota for writes and complex queries.
Integration platform dependency: Tools like Zapier, Make (formerly Integromat), and n8n rely heavily on webhooks as their primary trigger mechanism for connecting SaaS products. Understanding webhook architecture is essential for evaluating whether a SaaS vendor supports the automation patterns your stack requires.
Vendor evaluation criterion: When assessing SaaS tools, the quality of webhook implementation is a technical differentiator: Does the vendor publish webhook delivery logs? Support retry on failure? Provide payload signatures for security? Offer event filtering to reduce noise? These features determine whether an integration is production-grade or brittle.
Real-World Examples
- Stripe payments: When a customer completes a checkout, Stripe fires a
payment_intent.succeededwebhook to the merchant’s backend. The backend uses this event to provision the customer’s subscription, send a receipt, and update the CRM — all within seconds of payment without polling the Stripe API. - GitHub Actions: A push to a repository triggers a
pushwebhook to GitHub Actions, which spins up a CI/CD pipeline. This event-driven model means builds start in under a second of the push landing. - HubSpot to Slack: A deal reaching “Closed Won” in HubSpot fires a workflow webhook to a Slack incoming webhook URL, posting an automatic notification to the sales channel. No custom code required — two webhook endpoints wired together.
- Shopify order fulfillment: A fulfillment app subscribes to Shopify’s
orders/paidwebhook. When payment clears, the event triggers automated pick-pack-ship logic in the warehouse management system, eliminating manual order export.