What is an API? A plain-English explainer

The short answer

API stands for Application Programming Interface. Despite the technical-sounding name, the concept is straightforward: an API is a defined way for one piece of software to ask another piece of software to do something.

That's it. A set of rules for how two programs can talk to each other.

Why APIs exist

Imagine you're building an app that needs to display a map. You could write mapping software from scratch — gathering satellite imagery, building routing algorithms, handling zoom levels, rendering tiles. That would take years. Or you could call the Google Maps API, pass it an address, and get back a rendered map in milliseconds.

APIs exist because building everything yourself is impractical. They let developers use functionality that already exists — payment processing, maps, weather data, email delivery, document conversion — without having to understand or rebuild the underlying system. You just need to know the rules for asking.

This is why modern software is largely built from assembled APIs rather than written from the ground up. Your banking app talks to a fraud detection API, a notification API, and a payment processing API. Your food delivery app talks to a mapping API, a payment API, and restaurant ordering APIs. None of these companies built all of those capabilities themselves.

How a web API works

Most APIs you'll encounter today are web APIs — they communicate over the internet using standard HTTP, the same protocol your browser uses to load web pages. The most common style is called a REST API.

A REST API uses standard HTTP methods to indicate what kind of operation you're performing:

• GET — retrieve something (fetch a record, look something up)
• POST — send something (create a record, trigger a conversion, submit data)
• PUT / PATCH — update something existing
• DELETE — remove something

The response from a modern web API is usually in JSON format — a simple, structured text format that any programming language can read. It looks something like this:

// A typical JSON response from a hypothetical user lookup API
{
  "id": "usr_abc123",
  "name": "Jane Smith",
  "email": "jane@example.com",
  "plan": "pro"
}

API keys and authentication

Most APIs require you to identify yourself before they'll respond to requests. The most common method is an API key — a unique string of characters that acts like a password for your application.

You include the API key in every request, usually in a header:

# Example API request with authentication
POST https://api.example.com/convert
Authorization: Bearer your-api-key-here
Content-Type: application/json

The API uses this key to verify you're authorised, track how many requests you've made (for rate limiting and billing), and associate the request with your account. Keep API keys private — treat them like passwords, because that's effectively what they are.

A real example — Zindle

Here's what a Zindle API call looks like in practice:

# Convert HTML to PDF using the Zindle API
curl -X POST https://api.zindle.com.au/v1/convert \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<h1>Invoice #1234</h1><p>Amount due: $500.00</p>"
  }' \
  --output invoice.pdf

That's it. One request, one PDF back. The developer doesn't need to know anything about how PDF rendering works, what libraries Zindle uses internally, or how to handle page layout. They just need to know the rules for making the request — which is what the API documentation provides.

This is exactly the kind of task APIs are made for: a well-defined, repeatable operation that would be tedious to build yourself but is trivial to call.

APIs vs websites

A question worth addressing: if a website and an API are both accessed over the internet via HTTP, what's the difference?

A website is designed to be used by humans through a browser. It returns HTML, CSS, and images that the browser renders into something readable and clickable.

An API is designed to be used by other software. It returns structured data — usually JSON — that another application can process programmatically. There's no visual interface, no button to click, no page to read. The response is meant to be consumed by code, not by eyes.

Many services offer both. An e-commerce platform might have a website for customers to browse and buy, and also an API so that other businesses can integrate their product catalogue, check stock levels, or place orders programmatically from their own systems.

Why this matters even if you're not a developer

Understanding what an API is matters beyond just being able to follow technical conversations. A few practical reasons:

• Evaluating software integrations. "Does this tool have an API?" is one of the most important questions to ask when evaluating business software. An API means your data isn't locked in — other systems can read and write it programmatically.
• Understanding what you're buying. Many SaaS products charge based on API usage. Knowing that an API call is simply one request to a service helps you understand what those usage limits actually mean in practice.
• Communicating with developers. If you can describe what you want a system to do in terms of inputs and outputs — "we send you an HTML document, you give us back a PDF" — you're already thinking in the same terms as the API developer. That makes scoping and commissioning technical work significantly clearer.