What is an API?

The simplest possible mental model

Imagine you walk into a restaurant. The menu is the API. It tells you what you can order, what each thing contains, and what it costs. You do not need to know how the kitchen works, what brand of stove they use, or which farm the tomatoes came from — you just need to know how to order from the menu and what you will get back.

A software API is the same thing. Stripe exposes "create a charge," Twilio exposes "send an SMS," your CRM exposes "create a deal." You do not care how they implemented it; you care that the contract is stable.

What are the main types of APIs?

Most modern APIs fall into one of four paradigms. REST models the world as resources at URLs (GET /users/42). GraphQL exposes a typed schema and lets clients ask for exactly the fields they need. RPC (gRPC, JSON-RPC) names methods directly (CreateUser, SendInvoice) and is more common inside service meshes than on the public web. Webhooks invert the direction — instead of you asking, the other system tells you when something happens by POSTing to a URL you own.

These styles are not exclusive — Stripe is REST plus webhooks, GitHub ships both REST and GraphQL, every major SaaS has at least one webhook category. Choosing between them is a design decision, not a religion. See our dedicated entry on REST vs GraphQL for the tradeoffs.

Why do APIs matter for non-engineers?

Every "integration" your team relies on is an API call. Your CRM pulling data from your billing system, your support tool surfacing the customer's plan, your accounting software reconciling Stripe — APIs all the way down. A founder who can not draw a rough diagram of which APIs their product talks to is one outage away from being unable to explain to customers why something broke.

APIs are also the surface where most security incidents happen. Public APIs without rate limiting get scraped. Internal APIs without authorization checks get used by the wrong tenant. APIs that leak more data than they should make headlines.

At QUANT LAB

We design and build APIs as a first-class product, not as the unloved backend of a frontend. Our API development engagements usually fall into two buckets: integrations that wire your product to third-party platforms (Stripe, Salesforce, QuickBooks, the dozen vertical SaaS tools your customers depend on), and public APIs that let your own customers build on top of you.

Every API we ship gets the same treatment a customer-facing product gets: typed contracts, OpenAPI or GraphQL schema, versioning policy, rate limiting, structured error responses, and authentication that does not rely on hope. Where the data is sensitive, we recommend a web application pentest on the API surface before launch.

Versioning — the thing teams forget until it hurts

APIs need a versioning strategy from the day they ship, because someone is integrating with v1 and you need a path to v2 without breaking them. Common approaches: URL versioning (/v1/users, /v2/users), header versioning, and date-based versioning (Stripe's approach). Each has tradeoffs, but the worst choice is no choice — eventually you have to break something, and customers tolerate breakage much better when there is a documented version policy than when their integrations just stop working with no warning.