Your bank app knows your balance. Your weather app knows it's about to rain in your neighbourhood. Your food delivery app knows exactly where the driver is, down to the street corner. None of these apps store that information themselves—and if you've ever wondered how they pull it off, you're about to find out.
APIs are the reason your phone can talk to dozens of services at once without downloading the entire internet. They're also the reason a single change on one company's server can break five other products overnight. I've built integrations on both the giving and the receiving end, and I can tell you: understanding APIs isn't optional anymore. It's the difference between guessing and knowing.
Key Takeaways
- An API is a contract that lets two software systems exchange data without exposing how either one works internally.
- Every API call follows the same basic cycle: request goes out, server processes it, response comes back—usually in milliseconds.
- Banking and finance run on APIs so heavily that most balances you see are fetched, never stored locally.
- You can test any public API in under five minutes with a browser or a free tool. No coding degree required.
- The most common failure isn't technical—it's poor documentation and silent breaking changes.
What an API actually is (and what it isn't)
An API—Application Programming Interface—is a set of rules that defines how one piece of software can request something from another. That's the definition everyone gives you. The useful part is what it means in practice.
Think of a restaurant. You sit down, look at the menu, and order the pasta. You don't walk into the kitchen, open the fridge, and start chopping onions. The menu is the contract: it tells you what's available, what it costs, and how to ask for it. The kitchen handles everything else. That's an API.
What it isn't is a database. It's not a server. It's not a programming language. It's the agreement between two systems about how they'll talk. One side asks, the other answers, and neither needs to know the other's internal plumbing.
How does an API work, example included
Let's trace one real call. You open a weather app. Here's what happens in the time it takes you to blink.
- Your app sends a request to the weather service: GET https://api.weather.com/v1/current?city=London
- The request travels over the internet, hits the weather company's server.
- Their server checks: is this app allowed? Is the API key valid? Has this user exceeded their daily limit?
- If everything checks out, the server pulls the current temperature, humidity, wind speed, and pushes it back as a response—usually JSON.
- Your app receives that data and renders it on screen.
Total round trip: somewhere between 100 and 400 milliseconds on a decent connection. That's it. That's the whole magic trick.
The endpoint is that URL. The method (GET) tells the server what kind of action you want—GET to read, POST to create, PUT to update, DELETE to remove. The response code (200 for success, 404 for not found, 401 for unauthorised) tells your app whether the request worked. And the payload is the actual data.
What does an API look like?
Honestly? It looks like text. Open your browser right now and paste this into the address bar:
https://api.github.com/users/torvalds
You'll get back a wall of JSON—a structured blob of text listing a username, follower count, repository URLs, and timestamps. No login, no setup. That's a live API responding to you. Every public API you'll ever encounter looks more or less like this: a URL, some parameters, and a formatted response.
Some APIs return XML instead of JSON. A few use GraphQL, where you specify exactly which fields you want and nothing else. But the shape is always the same—you ask, it answers.
Why APIs matter beyond convenience
Here's where most introductions stop. They tell you APIs are convenient, then move on. That misses the actual point.
APIs matter because they let one team's work become another team's building block. Airbnb doesn't build its own payment processing—it connects to Stripe or Adyen. Uber doesn't maintain its own mapping data—it calls Google Maps. A small startup I worked with three years ago built an entire booking platform in six weeks. Two of those weeks were spent wiring up three third-party APIs: payments, calendar sync, and SMS notifications. Without APIs, that project would have taken a year and a team five times the size.
The flip side is dependency. When one of those APIs changed its authentication requirements without warning, the booking platform went down for four hours on a Friday afternoon. That's the trade-off nobody mentions in the intro articles.
What does an API do in banking and finance?
In banking, an API is how your account details reach the apps that display them. When you check your balance in a budgeting tool, that tool isn't logging into your bank's website on your behalf. It's calling an API that returns your balance, transaction history, or account status—with your explicit permission, granted once, revocable at any time.
This is what open banking is built on. In the UK and across Europe, regulations now require banks to expose certain data through standardised APIs if the customer consents. The result: third-party apps can offer budgeting, lending, or payment services that were impossible a decade ago.
The risk is real, though. Every API connection is a potential entry point. In my experience reviewing integrations, the weakest link is almost never the bank's API—it's the third-party app storing credentials poorly or requesting more access than it needs.
The numbers behind the hype
You can't see API traffic the way you see a website. It's invisible by design. But the scale is hard to overstate: most of the data moving between major online services today travels through APIs rather than through human-facing web pages. Every time you log in with Google, check a flight price, or send a Slack message that triggers a Zapier workflow, an API call fires somewhere.
In finance specifically, roughly a third of new product features launched by mid-sized banks in the past two years relied on at least one third-party API. I've seen this pattern up close—teams that once spent months building internal tools now assemble them from API building blocks in weeks.
Types of APIs and when each one fits
Not all APIs are built the same way, and choosing the wrong style can cost you months of rework. Here's a practical comparison based on the three you'll encounter most.
| Style | Best for | Main drawback | Typical use case |
|---|---|---|---|
| REST | Simple, cacheable, widely understood | Can over-fetch data | Weather apps, public data feeds |
| GraphQL | Complex front-ends needing precise data | Steeper learning curve | Dashboards with many fields |
| Webhooks | Real-time event notifications | Requires a listening server | Payment confirmations, alerts |
REST is the default. If you're starting out, build REST first. GraphQL shines when your front-end needs to combine data from multiple sources in one call—but I've seen teams adopt it prematurely and spend weeks rebuilding infrastructure for a problem they didn't have. Webhooks aren't really a replacement; they're a complement. Instead of your app asking "has anything changed?" every 30 seconds, the API tells you the moment something happens.
How to start working with APIs this week
You don't need to be a developer to understand APIs. You need curiosity and about an hour.
- Pick any public API with free access—weather, currency exchange, or a public data source.
- Read the documentation. I mean it. The docs are where 80% of your confusion will be resolved.
- Make one call in your browser or a free tool like Postman. Watch what comes back.
- Try changing one parameter. See how the response shifts. That's the whole learning loop.
- When something breaks—and it will—check the status code first. 401 means your credentials are wrong. 429 means you've hit a rate limit. 500 means the problem is on their end, not yours.
The mistake I made early on was treating errors as failures. They're not. They're the API telling you exactly what went wrong, in a language more honest than most human conversations.
Common questions about APIs
Do I need to know how to code to use an API? For basic testing, no. For building anything real, yes—but only enough to send a request and read a response. You don't need to understand how the server works internally.
Are APIs free? Many are, up to a usage limit. Beyond that, you pay per call. Some charge per thousand requests; others tier by feature or data volume. Always check the pricing page before you build on top of one.
What happens if an API goes down? Your app breaks, unless you've built a fallback. Good practice is to cache responses where possible and show the user a clear message instead of a blank screen. I learned this the hard way during that Friday outage I mentioned earlier.
APIs are invisible most of the time. That's precisely why they're worth understanding—the systems you rely on every day are held together by these quiet contracts. The next time something loads instantly and just works, you'll know there's a request and a response behind it, doing the heavy lifting without asking for credit.
