Webhook

Data & Tracking

Also: Web Hook · HTTP Callback

What it doesPushes data the instant something happens

SpeedNear instant, no repeated checking

Watch forSilent failure if the endpoint goes down

Compare toAPIs that answer only when asked

Quick definition

A webhook is a way for one piece of software to automatically notify another the moment something happens, like a new sale or a form submission. Instead of one system repeatedly asking 'anything new?', the sending system pushes the data across immediately as a Hypertext Transfer Protocol (HTTP) request when the event occurs.

How it varies across Australia

Webhook reliability is not something ad platforms publish a benchmark for, but it shows up directly in Data and Tracking maturity scores. Businesses running webhook driven integrations without retry logic or failure alerts consistently score lower on tracking reliability than those with monitored, well built webhook setups.

See Data and Tracking maturity scores across Australian industries →

What it actually means

A webhook works like a doorbell instead of a phone call. With most integrations, one system has to keep calling another and asking 'has anything changed yet?' That repeated asking is called polling. A webhook flips the model. The sending system rings the bell the instant something happens, a sale, a form submission, a churn event, and pushes the data straight to a URL the receiving system has set up to listen.

This is different from an Application Programming Interface (API), which is a request and response conversation, one side asks, the other answers. A webhook needs no request. It just fires.

Webhooks quietly hold together most of the marketing stack. A checkout event fires a webhook that updates the Customer Relationship Management (CRM) system, triggers an email flow, and fills in the data layer that feeds attribution. A form submission fires a webhook that syncs a lead into a sales pipeline before the pixel has even finished loading. When webhooks are set up properly, they are invisible. When they fail, entire reporting chains go quiet without anyone noticing, because nothing announces its own absence.

A webhook that fails silently is worse than no webhook at all, because everyone assumes the data arrived.

How it shows up

Webhooks show up wherever systems need to talk without a human refreshing a page. A payment gateway firing a webhook to update order status. An ecommerce platform sending a webhook to a CRM when a new customer is created. A form tool pushing a webhook to an automation platform to kick off a workflow. You rarely see the webhook itself. You see its effects, a lead appearing in your CRM within seconds, an alert firing when a high value order comes through, a data layer populating without a page reload.

The Australian context

Australian businesses relying on offshore webhook endpoints need to think about the Privacy Act when personal information travels through them. If a webhook pushes customer data from an Australian ecommerce store to a marketing platform hosted overseas, that is technically an overseas disclosure and may need to be covered in your privacy policy. It is also worth checking where the receiving server actually sits. A webhook endpoint hosted overseas adds latency for Australian traffic and, more importantly, raises a jurisdiction question your legal team should know about before it becomes a problem rather than after.

Where people get this wrong

Assuming a webhook fired just because the integration was set up.Webhooks fail silently on timeouts, authentication changes and endpoint downtime. Without monitoring or retry logic, a broken webhook looks identical to a quiet day.

Using a webhook where a scheduled data pull would be safer.Webhooks assume the receiving endpoint is always available. For less time sensitive data, a scheduled pull that retries on its own is often more reliable than a single unrepeated delivery attempt.

Never testing what happens when the payload changes.If the sending platform changes its data structure, a webhook can keep firing successfully while silently sending malformed or incomplete data downstream.

Common questions

What is a webhook used for in marketing?

Webhooks connect marketing tools without manual data exports. A new lead in a form tool can fire a webhook that instantly creates a record in a CRM, starts an email sequence and logs an event in the data layer for attribution, all within seconds of the form being submitted.

Is a webhook the same as an API?

No. An API is a two way conversation where one system asks and the other answers. A webhook is one way. The sending system pushes data the moment an event happens, with no request needed. Many platforms use both, an API to set the webhook up and the webhook itself to deliver events.

How do I know if my webhooks are working?

Check the sending platform's webhook logs, most show delivery attempts and response codes. Better still, set up a monitoring alert that fires if no webhook has arrived within an expected window, so a silent failure gets caught within minutes instead of weeks.

Can webhooks fail without anyone noticing?

Yes, and this is the most common webhook problem. A changed authentication key, a server timeout or an endpoint that moved can all break a webhook silently. Nothing errors loudly. The data just stops arriving, and reporting quietly drifts from reality.

Debrief

Get the next one

No spam. No fluff. Just the next article, straight to your inbox.

Keep exploring

About New Rebellion

New Rebellion is a marketing intelligence consultancy. We build tools, score Australian businesses on how their marketing actually performs, and publish Debrief every day. This dictionary is part of how we work in the open.

How we think →