Webhooks and APIs Explained for People Who Don't Code

If you have received a software quote in the last few years, the words “API” and “webhook” were almost certainly in it. And almost certainly nobody explained them, because people who use them daily forget they aren't ordinary English.

You don't need to know how they work inside. You need to know what they make possible, because some very concrete questions depend on it: can this software talk to that one? How quickly? Who notices if it stops?

Picture a restaurant. Customers come through the front door and see the dining room: that is the interface, the one with buttons, the one people use.

Then there is a service door round the back, where suppliers deliver. It isn't pretty, it has no sign, but it exists precisely so someone can come through in an orderly way. That is the API: a door one piece of software opens so other software can query it, with precise rules about what can be asked and how.

When your webshop “passes orders to the management system”, it is knocking on that door. The useful question to ask a supplier is very simple: “does your software have documented APIs?” If the answer is yes, connecting it to something else in future is ordinary work. If it is no, every connection will be an acrobatic act.

With an API, you do the asking: “any new orders?” You can ask every hour, every five minutes, but you are still asking, and in between you know nothing.

A webhook flips the direction: it is a doorbell you leave with whoever holds the information, saying “ring here when it happens”. When an order arrives, their system calls yours and hands over the data immediately, with no checking on your side.

The difference shows up in two places: speed — a webhook is instant, periodic checking always lags — and load, because asking “anything new?” a thousand times a day to hear news three times is wasted work for both sides.

Here is the question that separates a serious integration from a fragile one, and you can ask it without any technical knowledge: “if the webhook doesn't arrive, what happens?”

Connections drop, servers restart, maintenance happens. A well-built system retries, keeps track of what didn't get through and, if it really can't proceed, tells a person. A fragile one loses the notice in silence — and you find out three days later that website orders have stopped reaching the warehouse.

The second useful question is about security: “how do you know the doorbell was rung by who it claims to be?” There are standard ways to verify it. If nobody has thought about it, anyone who knows the address can pretend to be the payment system.

Not to become technical, but to ask three questions at the right moment, before signing: does the software have documented APIs, does it send webhooks for the events that matter, and what happens when something doesn't arrive.

Those three questions change the value of what you are buying, because they decide whether in two years you can connect it to something else or whether you are locked in. It is the same reasoning that applies to your data and your accounts: what matters is staying able to move.