Most people who run a website meet APIs sideways. You are not setting out to write software; you are trying to take payments, show a map, send a form to a mailing list, or let people sign in with an account they already have. Every one of those is an API integration — one piece of software asking another to do something on its behalf, over the web, in a format both ends have agreed on in advance.
This hub is the plain-English introduction. The full explainer is what is API integration?, and the rest of the archive is on the blog index.
What integration actually means
An API is a published contract. It says: send a request shaped like this, to this address, with these credentials, and you will get an answer shaped like that. The contract matters more than the code. Because it is agreed in advance and documented, the two systems stay compatible even though neither team can see inside the other, and either side can be rewritten without the other noticing.
Integration is the work of holding up your end of that contract — sending the right request, handling the answer, and behaving sensibly when the answer never arrives. That last part is the one people skip, and it is the one that shows up as a broken checkout on a Saturday.
Why it matters to a site owner
Three reasons, in order of how often they bite.
- You are already depending on several. A typical small business site quietly relies on a payment provider, an email service, an analytics collector and a maps or reviews widget. Each one is an outside system your pages need in order to be complete.
- It is where the data lives. Integrating properly means one authoritative copy of a customer or an order, rather than the same record typed into three systems and disagreeing by Thursday.
- It decides what you can automate. If your shop and your accounting can talk to each other, a whole category of manual work disappears. If they cannot, you employ somebody to be the integration.
What to check before you connect something
You do not need to be a developer to ask good questions, and the answers are usually in the first page of the vendor's documentation.
- Is there real documentation? A published, machine-readable description — an OpenAPI specification is the common form — is a strong sign the provider takes compatibility seriously.
- How is it versioned? Find out what happens when the provider changes something. A service that versions its API and announces deprecations will not break your site without warning.
- What are the limits? Nearly every API caps how often you can call it. Knowing the ceiling before launch is cheaper than discovering it during your busiest hour.
- How does it report failure? Good services return a clear, structured error rather than a blank page; the conventions in RFC 9457 describe what a well-formed problem response looks like.
- Where do the credentials live? API keys are passwords. They belong in server-side configuration, never in a page's source, and they should be rotatable without a rebuild.
Designing rather than bolting on
If you are commissioning software rather than buying it, it is worth knowing that the order of work matters. Agreeing the interface first — before anybody builds the screens behind it — tends to produce something cleaner and cheaper to change later, because every consumer is designed against the same contract. Microsoft's API design guidance is a readable summary of the principles involved.
Start here
Read what is API integration? for the concepts, then installing a tracking pixel for a hands-on example of connecting an outside service to your pages. If the platform underneath is still undecided, the CMS hub is the better place to begin.