API integration is the process of connecting your website or application to an outside service so the two can exchange data without anyone copying it across by hand. Once the connection exists, information flows between the systems on its own: an order placed on your site appears in your fulfillment system, a payment is authorized by a bank, a map shows the right location on a page you never drew a map on.
The phrase sounds more technical than the idea is. Strip away the vocabulary and API integration is simply one program asking another to do something on its behalf, in a format both agreed on beforehand.
What is an API?
API stands for application programming interface. It is a defined set of requests one piece of software can make of another, and a defined set of answers it can expect back. The word that carries the weight is interface: an API is the surface a system deliberately exposes to the outside world, in the same way a dashboard is the interface to an engine. You do not need to understand the machinery to use the controls, and the manufacturer can change the machinery without redesigning the controls.
Almost all the APIs a site owner will meet are web APIs, which means the requests travel over the same protocol as web pages themselves. That is why an API call and a page load look so similar from the outside: both are HTTP requests, and both come back with a status code that says what happened. The rules are set out in RFC 9110, the specification that defines HTTP semantics. The important consequence for you is that an API can fail in all the ordinary ways a web page can fail — slowly, partially, or not at all.
So what does integration add?
An API on its own is just an offer. Integration is accepting it: writing the part of your system that forms the request, sends it, reads the reply, stores what matters, and copes when the reply is an error or never comes. A finished integration is the difference between a service being available to your site and being useful to it.
The best-known examples are the ones people stop noticing. A payment gateway takes card details, checks them with a bank and returns an approval — your shop never handles the card itself. A mapping service returns coordinates for an address so a restaurant page can show where the restaurant is. A sign-in provider confirms that a visitor is who they claim to be, so you never store another password. In each case a specialist service does the difficult part and your site does the part that is actually yours.
A worked example
Suppose a delivery business wants to show customers where their order is. Nobody builds a mapping platform to do that. Instead the site calls a mapping API with an address and receives coordinates back, then calls it again with those coordinates to get a map tile to display. Two requests, a handful of lines of code, and a feature that would otherwise be an entire product. That is the whole appeal of integration: you rent the hard part.
The same shape applies to email, analytics, reviews, shipping quotes, tax calculation and stock levels. The pattern never changes — a request, a response, and your code deciding what to do with it.
Why API integrations matter
- Data stays consistent. When systems talk to each other directly, there is one authoritative version of a customer, an order or a price. Manual re-entry guarantees the opposite.
- Work disappears. Anything that is currently somebody exporting a spreadsheet on a Friday is a candidate for an integration.
- You get capability you could not build. Fraud checking, address lookup and currency conversion are all specialist problems solved better by people who do only that.
- Change gets cheaper. A system built around clear interfaces can have a component replaced without the rest being rewritten around it.
- It scales past you. An integration works at three in the morning and at a thousand orders an hour, which is not true of a person.
What to check before you connect one
The questions worth asking are the same whether you are writing the code yourself or paying someone to.
- Is it properly documented? A machine-readable description such as an OpenAPI specification means the contract is explicit rather than folklore.
- How does it handle versions? Find out how the provider signals a breaking change, and how much notice you get.
- What are the rate limits? Every API has a ceiling on how often you may call it. Design for it rather than discovering it.
- How are credentials handled? API keys are passwords in a thin disguise. They belong in server-side configuration and must be replaceable without a redeploy of everything.
- What happens when it is down? Decide in advance whether the page degrades gracefully or breaks. A missing map is a small disappointment; a checkout that hangs is a lost sale.
Designing with APIs in mind
If you are commissioning something new rather than bolting onto something old, agreeing the interface before building the screens tends to produce a cleaner result. Every consumer — the website, a mobile app, an internal tool — is then written against the same published contract instead of against whatever the first implementation happened to do. Microsoft's API design guidance is a good introduction to the conventions.
Where to go next
The API integration hub collects the rest of the material on this subject, and installing a tracking pixel is a practical first integration for most site owners — a small script, an outside service, and a concrete result. If your site itself is still being planned, start at the CMS hub instead and come back to this once the platform is settled.