API (Application Programming Interface)

What is an API?

An API — Application Programming Interface — is a defined set of rules for how software components communicate with each other. When your application needs to charge a credit card, it calls Stripe’s API. When it needs to send an email, it calls SendGrid’s API. When it needs to log into Google, it calls Google’s OAuth API. The API defines what requests are valid, what data they require, and what responses will come back. Your application doesn’t need to know how Stripe processes payments — it just needs to know the API contract.

For non-technical founders, the most important thing to understand about APIs is that they are external dependencies with their own lifecycle. The company that provides the API can change its behavior, deprecate endpoints, require new authentication, or shut down entirely. Every API integration your product relies on is a potential point of failure that you don’t control — and managing those dependencies thoughtfully is part of software architecture, not just an engineering detail.

How APIs Work

The dominant pattern for web APIs is REST (Representational State Transfer): your application sends an HTTP request to a URL endpoint with a specific method (GET to retrieve data, POST to create, PUT to update, DELETE to remove) and receives a structured response, usually in JSON format. The API documentation tells you what endpoints exist, what parameters each accepts, and what the response will look like.

Authentication is almost universal: APIs require you to prove who you are before serving data. API keys are the simplest form — a secret token sent with every request. OAuth is more complex but allows users to grant your application access to their data on another platform (the “Sign in with Google” flow). Most APIs rate-limit requests to prevent abuse, which means your application needs to handle the case where it’s making too many calls and receives a throttled response.

REST, GraphQL, and Webhooks

REST is the standard but not the only pattern. GraphQL, developed by Facebook, lets the client specify exactly what data it wants in a single request rather than making multiple REST calls and assembling the result. This is valuable when building mobile apps or complex UIs that need to optimize network efficiency. It’s overkill for most internal integrations and adds complexity on the server side.

Webhooks are the inverse of a REST API call: instead of your application asking a service for data, the service pushes data to your application when something happens. Stripe uses webhooks to notify your app when a payment succeeds, a refund is processed, or a subscription renews. Your app registers a URL endpoint; Stripe calls it with a POST request whenever a relevant event occurs. Webhooks are efficient — no polling — but they require your application to be publicly reachable and to handle delivery failures gracefully.

API Risk for Startups

The risk of building on third-party APIs is underestimated until it isn’t. Twitter’s API shutdown in 2023 destroyed businesses that had been built on it. Payment APIs that change their fee structure or deprecate fraud protection features can require urgent engineering work with no warning. AI APIs are particularly volatile — model versions are deprecated, rate limits change, and the behavior of a model may shift between API versions in ways that break downstream applications.

The principles for managing API risk: build abstraction layers so that swapping one API provider for another doesn’t require rewriting application logic. Monitor API dependency on critical paths — know when an API is down before your users tell you. Read changelogs and deprecation notices. Evaluate whether the vendor’s business incentives align with long-term API stability, or whether the free tier you’re on is a customer acquisition mechanism that will eventually be monetized or withdrawn.

The integration tax — the cumulative cost of building and maintaining connections between systems — is largely an API management problem. Each API your product depends on is a surface area for breakage, a maintenance commitment, and a potential constraint on your ability to make product changes. Keeping that surface area small, well-monitored, and well-abstracted is an investment that pays off every time a third-party API changes.

Related Terms and Concepts