In short
An API, application programming interface, is a defined way for one piece of software to request something from another: send this, get that back, in an agreed format. When a website shows a map, takes a card payment, sends a text message or checks a postcode, it is using someone else's API. When a company says its product 'has an API', it means other software can read from it or act on it without a person clicking through the interface. APIs are what let systems be combined, and an API key is the password one system uses to identify itself to another.
The idea
Every program has things it can do. An API is the part of a program that lets other programs ask for those things, in a way that is written down and stable. The program on one side makes a request, "give me the weather for this postcode", in a format the other side has published; the other side does the work and sends back a response, also in a published format. Neither needs to know how the other is built. They only need to agree on the menu.
The comparison to a restaurant is old because it works. You do not go into the kitchen; you order from the menu, in the language the menu uses, and the food comes out. The menu is the interface. The kitchen is the implementation. The waiter is the API doing the carrying.
Where you already use them
A map on a contact page is Google's or Mapbox's map API being asked for tiles around an address. A card payment is Stripe's or PayPal's API being asked to charge a card and told whether it worked. A booking confirmation text is Twilio's or a similar API being asked to send a message. Address autocomplete is a postcode API. A weather widget, a currency converter, a social feed, a chatbot, a login with Google, an AI feature: each is a program on your site asking a program elsewhere for something and showing the answer.
Your own site can offer one too. A booking system might expose an API so an accounting tool can pull invoices. A product catalogue might expose one so a partner can list your stock. That is what "our product has an API" means: other software can talk to it without a person clicking.
Request and response
On the web, most APIs work over the same HTTP that browsers use. The requesting program sends a request to a URL, with a method (get, create, update, delete), sometimes with data in the body, and usually with a key identifying itself. The API replies with a status (success, not found, not allowed, error) and, if successful, data, usually as JSON, a plain text format that both sides can read.
The design conventions for this, REST being the most common and GraphQL an alternative, are the developer's concern. For everyone else the relevant facts are that the request and response formats are documented, that they can change over time (which is what API versioning manages), and that each request is a small transaction with a cost, a limit and a possibility of failure.
Keys, limits and costs
An API key is a secret string a program sends with each request so the provider knows who is asking, can bill them, and can cut them off. It is a password and must be kept out of front-end code and public repositories, which is the single most common API security mistake.
Rate limits cap how many requests a key may make per second or per day. Exceed them and the API refuses until the window resets.
Pricing is usually per request or per unit of work: per map load, per message, per thousand AI tokens. Free tiers cover small use; costs scale with traffic and should be estimated before a feature ships, particularly for AI APIs.
Failure is normal. The provider has an outage, the network hiccups, the limit is hit. Software that uses an API has to handle the answer not coming, which is a design task, not an afterthought.
Why it matters for a business
APIs are why software no longer has to do everything itself. A small company can take payments, send messages, verify identities, translate text and run AI features by asking specialists, at a fraction of the cost of building any of them. That is also a dependency: each API is a supplier, with terms, prices and a future that may change. The questions to ask before relying on one are the questions you would ask any supplier.
What to ask a vendor
- Is the API documented publicly, and is the documentation current?
- What does it cost at our expected volume, and what happens above the free tier?
- What are the rate limits?
- How is it versioned, and how much notice is given before changes?
- What is the uptime record, and is there a status page?
- Where is data processed, and is there a data processing agreement?
- Can we export our data through it if we leave?
A vendor with good answers has an API you can build on. A vendor whose "API" is a sales-page bullet with no documentation does not, and "integrates with everything" usually means "has a Zapier connector".
The one-paragraph version
An API is a documented way for one program to ask another to do something and get an answer. Your website uses several already. Your product may offer one. The key is a password, the limits and prices are a supplier relationship, and the failures need handling. If you would like a plain-language review of which APIs a planned product depends on and what each one commits you to, book a call.
Common questions
What is an API in simple terms?
A documented way for one piece of software to ask another to do something and get a result back, without either needing to know how the other works. Like ordering from a menu: you ask in the agreed way, the kitchen does the work, the answer comes out. Websites use APIs for maps, payments, messages, logins and AI features.
What is an API key?
A secret string that a program sends with each API request to identify itself, so the provider can authorise the request, bill for it, and cut it off if misused. It functions as a password and must be kept on the server, never in front-end code or public repositories, where it can be read and abused.
What does it mean when software 'has an API'?
That other programs can read from it or act on it directly, without a person using its interface: pulling records into another system, creating entries automatically, or connecting it to a workflow tool. The value depends on how complete and well-documented the API is; a bullet point on a sales page is not the same as a usable API.
Do I need to know about APIs to run a business website?
Enough to understand that the site depends on them: the payment provider, the map, the email service, the booking tool. Each is a supplier with costs, limits, terms and possible outages. Knowing which APIs your site relies on, what they cost at your volume, and where your data goes is a business question, not a technical one.
What is the difference between an API and an integration?
An API is the interface a piece of software exposes so others can talk to it. An integration is a specific connection built using one or more APIs, such as your booking system sending invoices to your accounting tool. Integrations are built on APIs; an API is what makes integrations possible.
