CentriWebA webhook is a message one piece of software sends automatically to another the moment something happens, such as a payment succeeding or a form being submitted. An API is the menu of things one system lets another ask for or do. For a business owner, an API is how your tools ask questions, and a webhook is how they tell each other news.
You do not need to build either. You need to know enough to ask a vendor or developer the right questions, and to spot when a promised integration will not behave the way you expect.
What is an API, in plain terms
An API (application programming interface) is a defined way for one piece of software to talk to another. Your accounting software has one, so does your CRM, your payment provider and your booking tool. Each lists the requests it will accept, such as “give me the invoices from last week” or “create a new contact with this name and number”.
A useful picture is a restaurant menu. The kitchen can cook a lot of things, but you can only order what is on the menu, in the way the menu describes. The API is the menu, and a request is an order. Without an API, a tool is a closed room, and the only way to move information is for a person to copy it across.
With an API, something else has to start the conversation. That is where the two approaches differ.
What is a webhook, and how is it different
With a plain API, your system asks. It might check your payment provider every five minutes: has anything new come in? This is called polling, like opening the fridge every few minutes to see if dinner has arrived.
A webhook flips it. You give the other system a web address, and it sends a message to that address as soon as the event happens. It is a buzzer at a cafe: you do not keep asking whether your order is ready, because it tells you.
| API request | Webhook | |
|---|---|---|
| Who starts it | Your system asks | The other system tells you |
| When | When you ask, or on a timer | When the event happens |
| Good for | Looking things up, creating or changing records | Reacting quickly to news |
| Downside | Delays or wasted checks if you poll | You need an address that is always listening |
Most real integrations use both. A webhook tells your system that invoice 1042 was paid. Your system then uses the API to fetch the full invoice details and update your records.
A webhook example from a small business
A tradesperson takes a deposit through an online payment link. The sequence behind the scenes looks like this:
- The customer pays.
- The payment provider sends a webhook to a web address you have given it. The message is a small block of text listing what happened, the amount and an identifier.
- Your automation receives it, checks it is genuine, and finds the matching job.
- It marks the deposit as paid, moves the job to scheduled and sends the customer a confirmation.
- It replies to the provider with a success signal, so the provider knows the message arrived.
Stripe, a payment provider, describes this on its webhooks documentation. As at November 2026, it says Stripe pushes data to a registered HTTPS endpoint as a JSON payload when events happen in your account, with examples such as a customer’s bank confirming a payment, a dispute, or a recurring payment succeeding. Check their page for current details.
The same pattern works for a website form that creates a CRM record, a calendar booking that triggers a reminder, or a signed contract that starts onboarding. Our guide to web form to CRM automation shows one in detail.
Where the webhook address comes from
The receiving address is often created by your automation tool. In n8n, for example, a Webhook node is a trigger that creates a URL for receiving data from apps and services when an event occurs, and it starts a workflow. According to n8n’s documentation (as at November 2026), it gives you a test URL for building and a production URL that becomes active when the workflow is published. Other tools work the same way. Check their pages for how.
That detail has a practical lesson. If a webhook works in testing and not in real life, the cause is often that the other system is still pointing at the test address, and the fix is to register the production one.
Questions to ask a vendor or developer about webhooks
You do not need the technical answer. You need to know whether they have one. Ask these:
- What events can your system announce? Some tools offer a rich list. Others offer only a few, and the one you need might not be there.
- Is there an API for the rest? A webhook usually carries only a little. Does the API let us fetch the details?
- How do you prove a message is genuine? Anyone can send a message to a public address. Stripe’s documentation says it signs each event, and that without verification an attacker could send fake events to trigger actions such as fulfilling orders or changing records. Ask the same of any vendor.
- What happens if our system is down? Stripe’s page says it retries delivery in live mode for up to three days with an increasing delay. Other vendors differ, and some do not retry at all.
- Can the same message arrive twice? Stripe’s documentation says an endpoint might occasionally receive the same event more than once and recommends logging processed event IDs. The receiving system has to cope with duplicates, or you may send two confirmations or create two jobs.
- Is order guaranteed? Stripe says it does not guarantee delivery in the order events were generated. “Paid” might arrive before “created”.
- Can we see a log of what was sent? When something goes missing you need to know whether the sender or the receiver dropped it.
If a vendor cannot answer the first four, the integration may look good in a demo and fail on a busy Friday.
What goes wrong with a webhook
Most failures are dull, not dramatic.
- The listener is not running. If the receiving workflow is switched off or the server is down, messages bounce. Whether they are retried depends on the sender.
- The receiver is too slow. Stripe’s guidance is to return a success response quickly, before doing any complex work, so the sender does not time out. A well-built receiver acknowledges first and processes after.
- A field changed. The sender updates its message format, and your automation looks for a field that is no longer there. This is one reason automations break.
- Fake messages. An unprotected address can be found and used. n8n’s Webhook node offers several ways to authenticate callers, including basic, header and JWT authentication, and you can restrict callers by IP address. Using none of them is an option, but it is a choice with a cost.
- A lost message nobody notices. Without monitoring, a missed webhook is a missing job or an unpaid invoice that looks paid. Ask who gets alerted.
Does a business owner need to care?
Only at certain moments. When you choose software, ask whether it can send webhooks or has an API, because a tool that does neither makes automation hard. When you hire someone to connect tools, the questions above show whether they have thought about failure. When a quote for an integration looks high, our guide to API integration cost explains what drives the price.
If a tool has no webhooks, polling on a timer still works for things that are not urgent, such as a nightly report. Reserve webhooks for events where speed matters, like a new enquiry or a payment.
Which automation tool receives and processes webhooks is a separate decision. We compare them in n8n vs Zapier. CentriWeb builds most client automations in n8n, so weigh our view with that in mind. If you would rather someone build and look after the connections for you, that is a service we offer, though a simple form to spreadsheet link is usually something you can set up yourself in an afternoon.