"API" might be the most-used unexplained term in technology. Job postings demand experience with them, every app documentation mentions them, and most explanations either drown you in jargon or settle for the restaurant-waiter metaphor and stop. This guide goes one level deeper — far enough that the term stops being fuzzy — while staying in plain language.

The core idea

An API (Application Programming Interface) is a defined way for one program to ask another program for something. That's the whole concept. The weather app on your phone doesn't own weather stations — it asks a weather service's API for today's forecast. An online store doesn't process card payments itself — it asks Stripe's API. Software talking to software, through a documented contract.

The word interface carries the real meaning: it's the agreed boundary between the two programs. The contract says: send a request shaped like this, and you'll get an answer shaped like that. What happens behind the boundary — which servers, which databases, which programming language — is deliberately hidden. That hiding is the point: Stripe can rewrite its internals completely, and as long as the contract holds, every app using it keeps working, unchanged.

One real request, step by step

Most APIs you'll meet are web APIs: requests travel over the same HTTP the browser uses. Here's an actual round trip:

Request:
GET https://api.weather.example/v1/forecast?city=Lahore
Authorization: Bearer sk_live_abc123

Response (HTTP 200):
{
  "city": "Lahore",
  "today": { "high": 41, "low": 29, "condition": "sunny" }
}

Decoded: GET is the verb (read data — POST creates, PUT updates, DELETE removes). The URL path /v1/forecast is an endpoint — one specific question this API answers. ?city=Lahore is a parameter. The Authorization header carries an API key — the credential that identifies who's asking, so the provider can bill, rate-limit, and revoke access. The answer comes back as JSON, the near-universal data format of web APIs (we've written a full guide to reading and debugging JSON). And the 200 is a status code saying "success" — a whole vocabulary of its own.

The vocabulary, decoded

  • REST — the dominant style of web API design: URLs name things (/users/42/orders), HTTP verbs act on them. When someone says "a REST API," they mean "the conventional kind."
  • Rate limit — how many requests you may make per minute/day. Exceed it and you get HTTP 429 responses until you slow down.
  • Webhook — an API in reverse: instead of you asking repeatedly ("any news? any news?"), the service calls your URL when something happens ("payment received").
  • SDK — a code library wrapping an API so you call ordinary functions instead of building HTTP requests by hand.
  • API versioning — the /v1/ in URLs. Because programs depend on the contract, providers can't change it casually; breaking changes ship as /v2/ while /v1/ keeps working.

Why everyone builds them

APIs exist because they let software be composed. A two-person startup ships card payments (Stripe), maps (Google), and SMS (Twilio) in a weekend — capabilities that would each take years to build — by renting them through APIs. Inside companies, APIs are how teams scale: the mobile app, the website, and the partner integrations all consume the same backend API instead of three teams reinventing the same logic. Even this site works that way internally: our background remover is a Laravel frontend talking to a separate Python AI service over a private API — the same pattern at small scale.

Try one yourself in 30 seconds

The fastest way to make this concrete: open a new browser tab and visit https://api.github.com/users/torvalds. That's a real, public, no-key-required API call — and the JSON that fills your screen is exactly what a program would receive: Linus Torvalds' public GitHub profile as structured data. Your browser just played the role of an application. Every API integration you'll ever build is that same round trip with more ceremony: a URL, sometimes a key, a JSON answer, and code that does something useful with it.

From here, the practical path is: learn to read JSON confidently, understand status codes, and make a few calls to a free public API with curl or your language's HTTP library. API skills compound quickly — because once you can talk to one, you can talk to thousands.