Skip to content
Learn · Glossary

Webhook

A webhook is an HTTP callback: one system sends an automatic POST request to a URL you control the moment a chosen event happens, rather than waiting for you to ask. It is push, not poll — the source pushes data as events occur, so your endpoint receives them within seconds instead of polling on a timer.

Updated 8 Jul 20262 min readBy fromHello
Key takeaways
  • A webhook is push, not poll: the source system sends data the instant an event fires, so you skip constant 'anything new?' requests.
  • Two directions matter in engagement platforms — outbound nodes call external systems mid-journey; inbound receivers ingest events from them.
  • Because anyone can POST to a public URL, treat every payload as untrusted: verify the signature and respond fast.

How does a webhook work?

You register a URL — the endpoint — with the system that holds the data, and tell it which events you care about. When one of those events fires, that system sends an HTTP POST to your endpoint with a payload describing what happened, usually JSON. Your server reads the payload, does its work, and returns a 2xx status to acknowledge receipt. No request from you triggered it — the source acted on its own. Most providers sign each request so you can confirm it genuinely came from them.

Webhook vs API polling: what is the difference?

Polling is the pull model: your code asks an API 'anything new?' on a fixed schedule, whether or not anything changed. A webhook is the push model: the source calls you only when there is something to report. Polling wastes most of its requests and adds lag between the event and your reaction; webhooks deliver within seconds and stay quiet otherwise. The trade-off is that your endpoint has to be publicly reachable and ready to handle bursts.

A webhook and its adjacent terms.

How do engagement platforms use webhooks?

  • Outbound — a webhook node inside a journey POSTs to an external system mid-flow: notify Slack when a lead converts, sync a status to your CRM, kick off a fulfilment step.
  • Inbound — a receiver ingests events from other tools: a payment provider reports a successful charge, a form tool passes a new lead, so profiles and journeys react without a nightly import.
  • This two-way plumbing is what lets a customer engagement platform sit in the middle of your stack. Dedicated delivery services such as Knock specialise in the outbound side alone.

Why it matters for a small team

A two-person team cannot sit and poll for changes, and cron jobs that check every few minutes add both lag and cost. Webhooks let one tool react to another the moment something happens, with no one watching. Two cautions: because any caller can POST to a public URL, verify the signature on every request and treat the body as untrusted; and log the events you emit and receive so they line up with your tracking plan instead of becoming an untracked side channel.

FAQ

Common questions

  • What is the difference between a webhook and an API?

    An API is something you call when you want data; a webhook is something that calls you when data changes. They are complementary: you often use a REST API to read or update records, and a webhook to be told the moment a record changes so you do not have to keep asking.

  • How do I secure a webhook endpoint?

    Treat every request as untrusted. Most providers sign the payload with a shared secret — recompute the signature and reject anything that does not match. Serve the endpoint over HTTPS, and return a 2xx quickly, doing slow work in a background job so the sender does not time out and retry.

  • What happens if my endpoint is down when a webhook fires?

    Most providers retry failed deliveries with backoff for a while, then give up, so a brief outage is usually survivable. Retries are not guaranteed forever, though — make your handler idempotent, since the same event may arrive more than once, and reconcile against the source API for anything you cannot afford to miss.

  • Do I need to build anything to receive webhooks?

    You need a publicly reachable HTTPS URL that accepts POST requests and returns a 2xx. For inbound webhooks into an engagement platform, that receiver is usually built in — you paste your URL into the sending tool. For outbound calls, a journey's webhook node does the sending for you.

See the platform the team runs.

Related guides
Early access

Put your growth teamon autopilot.

Early access opens gradually, so the team tunes to real use cases. Small teams with big ambitions go first.

500+ already on the list

Not ready to share an email? It's open source. Run it yourself today. View on GitHub

No spam. One email when your spot opens. Unsubscribe at any time.