Webhook

What a webhook is

A webhook is an automated message that one application sends to another as soon as a specific event occurs. Instead of asking a service over and over whether something has changed, you give that service a URL and it calls you the instant the event happens. Because the message travels over standard HTTP, usually as a POST request carrying a small block of data, almost any tool that can receive a web request can receive a webhook. People often describe it as a reverse API or a push notification for software: the data comes to you rather than you going to fetch it.

The practical value is immediacy. A form is submitted, a payment clears, a record is updated, and within a second the receiving system knows and can react. That real time quality is what makes webhooks the connective tissue of modern automation, linking a website, a CRM, a spreadsheet, a messaging channel, and a dozen other tools without anyone touching a keyboard.

How a webhook works

Three pieces make a webhook function: the event, the payload, and the endpoint. The event is the trigger, the thing that just happened, such as a new order or a cancelled subscription. The payload is the data describing that event, almost always formatted as JSON, containing fields like the customer email, the amount, or the record identifier. The endpoint is the URL on the receiving side that listens for incoming requests and knows what to do with them.

The sequence is simple. You register your endpoint URL inside the source system. When the event fires, the source builds the payload and sends an HTTP POST to your URL. Your endpoint receives it, reads the data, and runs whatever logic you defined: create a row, send an email, update a deal. A well behaved receiver answers quickly with a 200 status code to confirm receipt. If it does not, most senders retry a few times before giving up, which is why endpoints should acknowledge fast and process heavy work afterwards.

Webhook versus API: push versus pull

Webhooks and APIs are often confused because both move data between systems over HTTP, but they work in opposite directions. With a traditional API you pull: your code asks the server a question and waits for an answer, and if you want fresh data you have to ask again. With a webhook the server pushes: it contacts you only when there is something new to report.

The difference matters for efficiency. Polling an API every minute to see if a form was filled wastes requests and still adds delay. A webhook sends exactly one message at the exact moment it matters, nothing more. The trade off is that webhooks require you to run a listener that is always reachable, whereas polling can happen whenever your code wakes up. In practice the two are complementary: webhooks tell you something changed, and you often call an API afterwards to fetch fuller details.

Consider a Webflow site with a contact form. Webflow can fire a webhook the moment a visitor submits it. That request lands in an automation platform such as Make, carrying the name, email, and message. From there the scenario branches: it adds the lead to a CRM, posts a summary in a team channel, and sends the prospect an acknowledgement email, all within a couple of seconds. No one exported a spreadsheet, no one copied a field. One event produced a whole chain of actions because a webhook carried the news the instant it happened.

Security: secrets and verification

Because a webhook endpoint is a public URL, anyone who discovers it could try to send fake requests, so verification matters. The most common protection is a signing secret. The sender uses a shared secret key to compute a signature over the payload and includes it in a header. Your endpoint recomputes the same signature and accepts the request only if they match, which proves the message really came from the expected source and was not altered in transit.

Other sensible measures include serving the endpoint over HTTPS so the payload is encrypted, checking a timestamp to reject old replayed requests, and validating that the data looks the way you expect before acting on it. Treating every incoming webhook as untrusted until verified is the baseline discipline, especially when the action it triggers touches money, accounts, or customer records.

When to use a webhook, and when not

Webhooks shine when you need to react to events in near real time and when the source system offers them. They keep tools in sync, they cut manual work, and they scale cleanly because messages only flow when something actually happens. If your workflow depends on speed, a webhook is almost always the right building block.

They are a poor fit in a few cases. If you need a full historical snapshot rather than a stream of changes, an API call is better. If the receiving system cannot host a reachable endpoint, or if you only need data occasionally, scheduled polling may be simpler. And if events are extremely frequent, you may want to batch or queue them so a downstream tool is not overwhelmed. The rule of thumb: use webhooks for reacting, use APIs for asking.

Webhooks at BeBranded

At BeBranded we treat webhooks as the plumbing behind almost every automation we build. A typical setup connects a Webflow or Framer site to a no code platform like Make or n8n through a webhook, so a form submission, a purchase, or a status change instantly triggers the right follow up in a CRM, a database, or a Slack channel. We design each endpoint to acknowledge quickly, verify its signature, and fail gracefully, because a silent broken webhook is one of the hardest problems to notice. The result for clients is a stack that stays in sync on its own, with fewer manual steps and less room for human error.