What is an API? A plain-English answer

API stands for Application Programming Interface, which is not a helpful phrase to most people. Here's the version that is:

An API is how one piece of software talks to another. That is the whole concept.

You already use APIs constantly

This isn't some exotic technology for big companies. If you took a card payment today, you used an API. Behind every everyday moment in your business, there's a waiter shuttling between kitchens:

• The card machine. Tap, two seconds, "approved". In those two seconds your machine asked the bank's API whether the card is good, and the bank answered.
• Online bookings. A client books a 2pm cut and it appears in your calendar, which then stops anyone else taking 2pm. The booking system and the calendar are talking through an API.
• Delivery apps. An order placed on Deliveroo or Uber Eats prints in your kitchen seconds later. That's an API at work.
• Reviews on your website. A site that shows your live Google reviews is fetching them through Google's API; nobody is copying them across by hand.

Why this matters when you're buying a website

This piece of jargon matters because almost every "can my website do this?" question is really an API question:

• "Can customers book online?" asks whether the site can talk to a booking system.
• "Can I take deposits or sell gift vouchers?" asks whether it can talk to a payment provider.
• "Can enquiries land in my diary instead of an inbox?" asks whether it can talk to your calendar.

A well-built website is wired so these connections can be plugged in, including ones you don't need yet. A badly built one is a sealed box: it does what it did on day one, and anything new means opening it up or starting again.

The one question worth asking

You don't need to understand the plumbing; you employ people for that, in the same way you employ an electrician without memorising the wiring regulations. There is one question, though, that quickly reveals how a website has been built:

"If I start taking online bookings or payments next year, does this site connect to that, or does it need rebuilding?"

If the answer is a confident, specific yes, you're in good hands. If the answer is vague, it's worth asking more questions before committing. (This is central to how we build: every site leaves room for what you'll want next, not just what you need today.)