What an API is, and why your website talks to other systems
A plain explanation of application programming interfaces, with the examples a business website actually uses and the questions to ask about each.
The short answer
An application programming interface, API, is an agreed way for one piece of software to ask another for something and get a predictable answer. Your website asks a payment provider to charge a card, a mapping service for a map of your address, an email service to send the form submission, a newsletter tool to add a subscriber, an accounting system to record an order. Each of those is an API call, and a typical business website makes several kinds without anyone using the word. The point of an API is that your site can do useful things without building them itself. The catch is that every API is a dependency: it comes with a key that must be kept secret, a cost that may scale with use, a data flow your privacy setup must cover and a failure mode your site must handle. Each deserves a line in the site’s documentation, and the account behind each must be in your name.
APIs a business website uses
| What the visitor sees | The API behind it | What to know |
|---|---|---|
| Contact form sends an email | Transactional email service | Key in secret storage; sending domain authenticated; failures logged |
| A map on the contact page | Mapping service | Key restricted to your domain; usage limits; privacy implications of the embed |
| Paying for something | Payment provider | The site never touches card data; webhooks confirm payment |
| Newsletter sign-up | Marketing platform | Double opt-in; consent recorded; key scoped to subscribing |
| Booking a slot | Scheduling service | Whose calendar; what data is stored where |
| Site search | Search index service, or none for a static index | Where the index lives |
| Reviews or ratings shown | Review platform | Cached, not fetched on every visit |
| Orders appearing in accounting | Accounting or ERP system | Direction of sync; what is the source of truth |
| Login with an existing account | Identity provider | What is shared; what happens when it is unavailable |
Managing them well
- Keep a list of every external service the site calls, with purpose, account owner, key location, cost model and data flow.
- Accounts in your name, with a monitored address for the provider’s notices.
- Keys in secret storage on the platform, one per integration, narrowest permissions, never in public code.
- Handle failure: a form that cannot send should say so and keep the submission; a map that cannot load should not break the page.
- Cache what changes slowly, such as reviews or prices, instead of calling on every visit.
- Watch limits and costs so a traffic spike or a bug does not run up a bill.
- Keep versions current so provider deprecations are handled before deadlines.
Why this is good news
Because APIs exist, a small business website can take payments as safely as a large one, send email that reaches the inbox, show maps, sync with accounting and add subscribers without building any of it. The provider does the hard part and carries the compliance for their piece. The site’s job is to call them correctly, keep the keys safe and handle the moments they fail. Managed that way, integrations are the cheapest capability a site has.
What this means for you
Your website talks to other systems through APIs, and each is a dependency with a key, a cost, a data flow and a failure mode. Keep the list, own the accounts, store the keys properly, handle failures visibly and monitor the flows that matter. Understood that way, integrations let a small site do what used to need a large one, without the risks that come from treating them as invisible.
Frequently asked questions
Do we need to understand APIs to run our website?
Only at the level of knowing which systems your site talks to, what data flows each way, whose account and key are involved and what happens when one of them fails. That is a one-page list your partner should maintain. The technical detail of how requests are formed is their job; knowing the dependencies exist is yours.
What is an API key and why does it matter?
A key is the password your site uses to identify itself to another service. Anyone holding it can act as your site: send email from your account, charge your payment provider, read your customer records. Keys live in the platform's secret storage, never in the site's public code, and each integration gets its own key with the narrowest permissions the provider allows.
Can an API change and break our site?
Yes. Providers retire old versions, change limits and occasionally shut down. Good providers announce it months ahead to the email on the account, which is why that account must be in your name with a monitored address. A partner who keeps dependencies current handles the change before the deadline; a site nobody maintains breaks on the day.
Sources
- MDN Web Docs: Introduction to web APIs (accessed 2026-09-12)