Sign In Sign Up
technology

APIs Explained: How Modern Software Connects Everything

none
7 min read

In 2002, Jeff Bezos sent an internal memo that changed how Amazon — and eventually how the entire technology industry — worked. The memo had one core mandate: all teams must expose their data and functionality through service interfaces. No direct database access, no back-door integrations. Everything through interfaces. Teams that do not do this will be fired.

That memo described what we now call APIs. And the reason Amazon became a $2 trillion company with AWS as its most profitable division is, in large part, because of that discipline. When Amazon realized they had built world-class infrastructure while enforcing API-first principles internally, they productized it. AWS was not a strategic pivot — it was a direct consequence of the API mandate.

APIs are the most important concept in modern software that business leaders routinely misunderstand. Here is what they are, how they work, and why they determine which companies win in fintech.

What an API Actually Is

API stands for Application Programming Interface. The acronym is not helpful. The better explanation is a metaphor.

Think of a restaurant. The kitchen is where the food is made. You, as a customer, do not walk into the kitchen to cook your meal. You sit at a table, interact with a waiter, and the waiter carries your order to the kitchen and returns with the result. You do not need to know how the kitchen works — what equipment they use, how they organize their prep, what their internal processes are. You just need to know what the waiter can fetch for you.

An API is the waiter. It is a defined interface that lets one software system make requests to another without needing to understand the internal workings of the system being queried.

When your banking app shows your account balance, it is calling an API. When Uber charges your credit card at the end of a ride, it is calling Stripe's payment API. When TurboTax imports your income data, it is calling an IRS API. When your company's HR system updates payroll after an employee change, dozens of internal APIs are firing in sequence.

The software you see — the app, the website, the dashboard — is the front end. The work happens in the back end, in systems connected by APIs.

REST and Webhooks: The Two Patterns That Matter

There are many types of APIs, but two patterns are so dominant in modern software that executives who understand them can follow most technology architecture conversations.

REST APIs: Ask, Receive

REST (Representational State Transfer) is the dominant style for APIs that respond to requests. The pattern is simple: you ask a question, you get an answer.

When your mobile app loads your transaction history, it sends a REST API request to your bank: "Give me the last 30 transactions for account X." The bank's system processes the request and returns the data. The app displays it. Done.

REST APIs are synchronous — the requester waits for a response. They are also stateless — each request contains everything needed to process it. The server does not remember previous interactions.

The business implication: REST APIs are how most integrations work. When a vendor says "we have a REST API," they mean you can build software that programmatically asks their system for data or sends commands to it.

Webhooks: Push Notifications for Software

A webhook is the reverse of a REST API. Instead of you asking a system for information, the system notifies you when something happens.

Consider payment processing. You could poll Stripe's API every five seconds: "Did the payment go through? Did it go through yet? How about now?" That is inefficient and wasteful. Instead, you configure a webhook: "When a payment succeeds, send a notification to this URL." Stripe does the work of notifying you; you do not have to keep asking.

Webhooks are event-driven. They fire when something happens — a payment is completed, a customer updates their profile, a document is signed, an order ships.

The business implication: webhooks are how real-time integrations work. If you want your CRM to update the moment a deal closes in your payment system, or your logistics platform to trigger the moment an order is paid, webhooks are the mechanism.

Why APIs Are the Infrastructure of Fintech

The fintech industry is not primarily a financial innovation — it is an API infrastructure play. Virtually every successful fintech company is either selling API access to a financial capability or building a product on top of someone else's API.

Stripe turned card payment acceptance — historically requiring a bank relationship, a payment processor contract, and months of integration work — into an API you can integrate in an afternoon. Stripe's genius was not payments; it was making payments so easy to integrate that any developer could do it. Stripe processes hundreds of billions of dollars annually because their API is better than the alternative.

Plaid built an API layer between applications and financial institutions. When a personal finance app wants to read your bank account data, it does not build 12,000 individual integrations with every bank — it calls Plaid's API. Plaid handles the complexity. This is why Visa tried to acquire Plaid for $5.3 billion: they understood that Plaid's API layer was becoming infrastructure for financial data.

Twilio did the same for communications. Sending a text message verification code to a phone number — the kind of thing every bank's authentication flow requires — involved carrier agreements and complex technical integrations. Twilio made it a single API call. One line of code, one API call, message delivered globally.

The pattern repeats across every layer of fintech: KYC verification (Alloy, Persona), fraud scoring (Sardine, Sift), accounting data (Codat), payroll (Pinwheel), identity (Socure). Every one of these is an API business — packaging a complex financial or regulatory capability into a clean interface that any developer can call.

Open Banking: When Regulators Mandate APIs

In most countries, banks built walls around customer financial data. You could log in to your bank's app and see your transactions, but no third-party app could access that data without a screen-scraping workaround (which banks frequently blocked).

Open banking regulations forced banks to open their data through standardized APIs.

In the EU, PSD2 (Revised Payment Services Directive) requires banks to give licensed third parties API access to customer account data and payment initiation — with customer consent. In the UK, the Open Banking Standard mandated specific API specifications that all major banks must implement. In the US, the CFPB's Section 1033 rule (finalized in 2024) gives consumers the right to access their financial data and share it with authorized third parties via API.

The business implications are significant. A budgeting app can now pull your actual bank transactions rather than asking you to enter them manually. A lender can access six months of your bank account history to make a credit decision rather than relying on a credit bureau score alone. A business can initiate payments directly from a bank account rather than running them through a card network.

Open banking APIs are reshaping credit, payments, and personal finance simultaneously. The banks that had moats built on data exclusivity are discovering that regulation has opened the gates.

API Economics: Why This Business Model Works

APIs are not just a technology pattern — they are a business model. And understanding the economics helps executives evaluate technology vendors and potential partners.

The typical API business model prices by usage: per transaction, per API call, per connected account, or per successful conversion. Stripe charges a percentage of each transaction. Plaid charges per data connection. Twilio charges per message sent.

This creates several dynamics worth understanding.

Alignment of incentives. The vendor makes money when you make money (or when you succeed at whatever the API enables). Stripe grows when its customers process more payments. This alignment is different from traditional software licensing, where the vendor is paid regardless of whether you succeed.

Switching costs compound over time. Once your application is built around a vendor's API, the cost of switching — rewriting integrations, testing thoroughly, migrating data — grows with usage. Vendors with strong APIs exploit this dynamic in pricing reviews. This is why evaluating API vendors for long-term compatibility is as important as evaluating their current pricing.

Data network effects. API businesses that see more transaction data (Stripe seeing fraud patterns across millions of merchants, Plaid seeing financial flows across thousands of apps) improve their service with scale. The vendor with more data can build better fraud detection, better credit models, better anomaly detection — creating a competitive moat that is data-driven, not just technical.

What Executives Should Know About API Dependency

Every enterprise runs on a stack of API dependencies it often does not fully understand. Your customer communication runs on Twilio or SendGrid. Your payments run on Stripe or Adyen. Your identity verification runs on Jumio or Persona. Your data warehouse connects to production systems through a dozen internal and external APIs.

API concentration risk is real. When Twilio experiences an outage — and they have — every company using Twilio for authentication SMS stops being able to authenticate users. When a payment processor's API has a degradation, every merchant using that processor stops accepting payments.

Best practices that executives should ensure their teams follow:

Dependency mapping. Know which external APIs your critical business processes depend on. Understand the failure modes. What happens if Plaid goes down? Does your underwriting process halt?

SLA review. Every API vendor has a service level agreement with uptime guarantees and response time commitments. Review them before you are dependent, not after. A vendor guaranteeing 99.5% uptime sounds good until you calculate that 99.5% allows 44 hours of downtime per year.

Fallback design. For critical APIs, design your application to degrade gracefully rather than fail completely. If the real-time fraud scoring API is unavailable, can you fall back to rule-based scoring rather than refusing all transactions?

Data portability. If you terminate an API relationship, can you export your data? Many API businesses make data export painful — intentionally. Ensure portability is specified in your contract before it matters.

Key Takeaways

  • APIs are defined interfaces that let software systems communicate. They are the plumbing of every modern application — invisible when working, disastrous when broken.
  • REST APIs respond to requests; webhooks push notifications when events occur. Understanding which pattern is appropriate for which use case is basic technology literacy for product and business leaders.
  • Fintech is largely an API infrastructure business. Stripe, Plaid, Twilio, and dozens of others created trillion-dollar market caps by packaging complex financial and technical capabilities into clean, developer-friendly APIs.
  • Open banking regulations are forcing financial data APIs open. PSD2 in Europe, Open Banking in the UK, and CFPB Section 1033 in the US are dismantling the data walls banks built over decades.
  • API dependency is a business risk. Map your critical dependencies, understand SLAs, design for graceful degradation, and ensure data portability before you are locked in.

Related Reading

Related Articles