What a webhook is and what it’s for in practice

At some point in a meeting about systems integration or process automation, someone says the word webhook. And there are 2 reactions: the developer nods because they know what it means, and the operations director or business lead nods too, without being entirely sure what a webhook is or why it matters.

This article is for the second group. It doesn’t explain how to code a webhook. It explains what it is, what problem it solves and why it comes up in any serious conversation about connecting applications.

The difference between an API and a webhook

To understand a webhook, it helps to compare it with an API, the better-known concept. If that one isn’t clear yet, you may want to read what an API is and why you should care first.

An API works on a request and response model: your system asks, and the external system answers. To find out whether there are new orders, your system has to ask the store every so often: “any new orders?”. If there are, it gets them. If not, it gets an empty answer and asks again later. It’s like calling someone every 10 minutes to see if they have news for you.

A webhook flips that logic: instead of your system asking, the external system tells you when something happens. The store has a webhook set up that says “when a new order comes in, send the data to this address”. When the order arrives, the notice goes out on its own. It’s like giving someone your number so they can call you when they have news.

In practice, webhooks are more efficient, because there are no pointless checks when nothing is happening, and more immediate, because the notice arrives the moment the event occurs, not on the next round of checks.

One clarification so you don’t get tangled up in meetings: a webhook doesn’t replace the API, it complements it. Typically the webhook announces that something happened and, if more information is needed, your system then requests it through the API.

How a webhook works in practice

A webhook works in 3 steps:

Step 1: setup. In the system that will send the notice (a payment gateway, an online store, a CRM), you define 2 things: the event that triggers it and the address (URL) it will be sent to. For example: “when a payment is completed, send the data to https://yoursystem.com/webhook/payments”.

Step 2: the event happens. When the customer completes the payment, the system automatically sends an HTTP message to that address with the event data: the order ID, the amount, the customer details and the transaction status.

Step 3: your system receives and processes it. The system listening at that address receives the data and does whatever comes next: updating the order status, sending a confirmation email, notifying the warehouse or recording the payment in your accounting.

All of this happens in seconds, automatically and with no human involvement.

One detail separates a solid implementation from a fragile one: the receiver should confirm receipt right away and do the heavy lifting afterward. If it takes too long to respond, the sender may treat the delivery as failed and retry, and then the same event arrives a second time.

Common webhook use cases

Payments and transactions

Stripe and PayPal use webhooks to report payment events, and Redsys (the card payment gateway used by most Spanish banks) does something equivalent with its online merchant notification. When a customer pays, the notice kicks off everything that follows: generating the invoice, sending the confirmation, updating inventory or unlocking access on a subscription platform. Without a webhook, you would have to check the status of each transaction periodically or review it by hand.

Forms and leads

When someone fills out a contact form on WordPress, a webhook (built into the form plugin or added through an add-on) can send that data instantly to a CRM: create the contact, assign it to the right sales rep based on the type of inquiry and start a welcome email sequence. All at the moment someone clicks “send”.

Inventory management

If your online store and your warehouse management system are connected through webhooks, when a product’s stock drops below a minimum, the notice automatically creates a restocking order. Without a webhook, someone has to check stock by hand or wait for the next sync to pick up the change.

Internal notifications

Webhooks also work for internal communication. When a new customer signs up on your platform, a webhook can post a message with their details to the sales team’s Slack channel. When a critical error occurs in production, it can alert the tech team immediately, without anyone having to watch a screen.

Why understanding webhooks matters if you’re not technical

Integrations between systems show up in almost every development proposal and in any conversation about automating processes. Understanding the difference between an integration based on periodic checks and one based on webhooks lets you ask better questions.

“Does the integration use webhooks or periodic checks?” isn’t a technical question: it’s a question about how current your data will be and how efficient the system is. An integration that checks every 10 minutes may be enough in many cases. In others, such as payment confirmations, stock alerts or critical notices, those 10 minutes have a real impact on operations.

If you want to think through which of your company’s processes deserve this kind of connection, it may help to read which business data should update itself.

Checklist: webhook questions for an integration proposal

• Does the proposed integration use webhooks or periodic API checks?
• How long does data take to get from one system to the other?
• What happens if the webhook fails? Are there automatic retries?
• What happens if the same notice arrives a second time? Is there protection against duplicate orders, charges or invoices?
• Are incoming events logged so they can be reviewed if something goes wrong?
• Is the webhook address protected against fraudulent requests?

Frequently asked questions

Are webhooks secure?

It depends on how they’re implemented. A poorly protected webhook may accept data from anyone who knows the address, not just from the authorized system. Good implementations verify a signature: the sending system includes a cryptographic signature in each message, and the receiver checks that it matches the authorized sender before processing anything. Stripe, for example, signs all of its webhooks.

What happens if my system is down when a webhook arrives?

Well-designed senders include retries: if the receiver returns an error or doesn’t respond, they resend the notice several times, at increasingly longer intervals. Stripe, for example, retries failed deliveries for up to 3 days. Even so, for critical processes the receiver needs to be reliable, and there should be a periodic reconciliation that recovers any events lost during an outage.

Can I use webhooks without knowing how to code?

In some cases, yes. Tools like Zapier or Make can receive webhooks and process them without code: you create a webhook trigger, get an address and paste it into the system you want to connect. If you go that route, write down which scenario receives each notice and who maintains it, because the hidden cost of poorly documented automations shows up exactly when something breaks. For a custom receiver that runs your own business logic, such as updating your database or triggering internal processes, you need development work.

At Baqueiro we build webhooks and system integrations with our own code when the logic calls for it, without depending on third-party automation platforms. If you have processes that should be talking to each other automatically and aren’t, tell us about it.