What is an API? How systems talk to each other
An API (application programming interface) is a defined door one piece of software opens to another: what you may ask for, how you ask and what you get back are specified in advance. On the web the most common form is a REST API that answers requests with JSON, while webhooks work the other way and call you when an event happens. The value of integration is removing the human who carries data between two screens.
- An API is the contract between systems
- REST asks; webhooks tell you when something happens
- Keys belong on the server, never in the browser
- Integration cost tracks the other side's documentation quality
What is an API?
An API is the structured door a piece of software opens so other software can talk to it. The interface for people is the screen; the interface for machines is the API. As Wikipedia puts it, an API defines the services a component offers and how those services are called.
A concrete example: a courier's API says "give me a tracking number and I'll return its status". An accounting system's API says "send me invoice details and I'll issue it". Without these doors, somebody would open two screens every morning and move the data by hand.
REST, JSON and webhooks
The most common approach on the web is REST: every resource is an address, and you send GET, POST, PUT or DELETE requests to it. Responses usually come back as JSON. To describe an API in a way machines can read too, the OpenAPI specification is used; a good API ships an OpenAPI document.
Webhooks run in the other direction. You don't ask; the other side calls your address when something happens. For events such as "payment received", "parcel delivered" or "form submitted", a webhook is far more efficient than polling.
What integration is good for
- It ends manual data entry. An order moves from email to a spreadsheet to accounting on its own.
- It cuts mistakes. Copy-paste errors and forgotten records disappear.
- It shortens the delay. What you used to learn at month end you learn as it happens.
- It creates one source of truth. The "which list is right?" argument ends.
API security: the three most common mistakes
- Putting the key in the browser. API keys belong on the server; a key in front-end code is visible to anyone who reads the source.
- Skipping authorisation checks. A user should see their own record, not someone else's when they change a number in the URL. Broken access control is still number one on the OWASP Top 10:2025.
- No limits. An API without rate limiting can be taken down by one runaway loop of your own.
Questions to ask before an integration
- Is the documentation current, and is there a sandbox?
- What are the rate limits, and what does the API return on failure?
- Does data need to flow nightly or instantly? Are webhooks supported?
- How are breaking changes announced (versioning)?
- If personal data crosses the line, which fields are truly required?
A good integration doesn't require two systems to resemble each other. It only requires the contract between them to be clear.
Sources
- Wikipedia, API
- OpenAPI Initiative, OpenAPI Specification
- OWASP, OWASP Top 10:2025
Frequently asked questions
Does every piece of software have an API?
No. Older or locally installed programs often don't; then you connect to the database directly or exchange files instead.
How long does an integration take?
With good documentation and a sandbox, a few days. With an undocumented system and no support, it can take weeks.
Do APIs cost money?
It varies. Many services are free up to a request quota and charge per use above it.
Webhooks or polling?
Webhooks where possible. Polling wastes resources and delivers information late.
