Skip to main content
AI Agents Guide
Menu
Affiliate disclosure: This page contains affiliate links marked with ↗. If you sign up through one of these links, we may earn a commission at no extra cost to you. Our rankings and reviews are editorially independent — affiliate relationships do not influence them. Read our methodology →
S

Editor & AI Automation Researcher

Last updated:  ·  Report an error

Updated May 2026

What Is a Webhook?

How a webhook actually flows

The full lifecycle, end to end:

  1. You register a URL with the source app — call it https://your-app.com/webhooks/stripe. The source remembers it.
  2. The event happens in the source — a payment succeeds, an issue gets created, a new lead fills your form.
  3. The source sends an HTTP POST to your URL with a JSON payload describing the event, plus a signature header (HMAC) to prove it came from the source.
  4. Your code (or your iPaaS) receives the POST, verifies the signature, parses the payload, and triggers whatever happens next.
  5. You return 200 OK within a few seconds. If you do not, the source retries (Stripe retries for up to 3 days; GitHub up to 8 hours).

Webhook vs API call vs polling

All three move data between apps; the trigger differs:

  • Polling. You ask the source "anything new?" every N minutes. Always works, but wasteful at low frequency and slow at high. Zapier free-tier polls every 15 minutes; Make every 5; n8n typically every minute.
  • Webhook. The source pushes the event to you immediately. Sub-second latency in steady state. The source does the work; you just listen.
  • API call. You actively pull a specific record because you need it now (read a contact, list invoices). Webhooks notify you something changed; you call the API to fetch the full record if the webhook payload was minimal.

Security checklist

Webhooks are the most-attacked surface of a modern SaaS integration. Every production webhook handler needs all four:

  1. Verify the signature. Every reputable source signs the payload with HMAC-SHA256 and a shared secret. Reject any request whose signature does not match. This is non-negotiable.
  2. Idempotency. The source may retry the same event. Identify each event by its event-id header and ensure your handler is safe if it runs twice.
  3. Replay protection. Reject events older than ~5 minutes (using the source's timestamp header). Stops an attacker replaying a captured webhook.
  4. IP allowlist (optional). Some sources publish their outbound IP ranges; restrict your endpoint to those if your hosting allows. Useful as defense-in-depth, not a substitute for signature verification.

Webhooks in Zapier, Make, and n8n

You don't have to write the handler yourself. Each of the three big iPaaS platforms gives you a hosted webhook endpoint with one click:

  • Zapier "Webhooks by Zapier" — paid feature; gives you a unique endpoint, captures the request, and triggers a Zap.
  • Make "Custom webhook" — free on every plan; supports custom auth headers, JSON Schema validation, queueing.
  • n8n "Webhook" trigger — most flexible: HMAC verification node, raw-body access, configurable response codes. Self-hosted means the webhook URL is on your domain.
  • Pipedream — every workflow gets a hosted webhook URL by default; the simplest no-code path.

Common pitfalls

  • Returning slow. If your handler does heavy work synchronously, the source times out and retries. Always queue the work and return 200 OK quickly.
  • Forgetting to verify. Anyone who learns your webhook URL can POST to it. Without HMAC verification, your "real-time integration" is an injection point.
  • Treating retries as new events. Without idempotency, a retry triggers your downstream action twice — and you charge the customer twice.
  • Logging the payload. Webhooks contain PII. Either redact before logging or scope the logs to a short retention window.
  • Static secrets in repo. Rotate webhook secrets; store them in your platform's secret manager, not in code.

When to use webhooks vs polling vs MCP

Three patterns now solve overlapping problems:

  • Webhook — best for real-time events with a small payload (~ a few KB). Lowest latency, lowest cost.
  • Polling — best when the source does not offer webhooks, when the source's webhook delivery is unreliable, or when you only need to check once an hour anyway.
  • MCP — best when an AI agent needs to call out to a service on demand, rather than be notified. Webhooks push; MCP pulls. Many 2026 stacks use both: webhooks for low-latency events, MCP for agentic tool calls.

Our Top Pick: Make.com

Try Free ↗