API (Application Programming Interface)

What is an API (Application Programming Interface)?

An API is a contract. One piece of software promises that if you send a request in a specific shape, it will send back a response in a specific shape. Everything behind that contract, the database, the language, the servers, is none of your business as the caller. That separation is the whole point.

The everyday version looks like this. Your app needs to charge a credit card. You do not build a payment network. You send a request to a payments provider with an amount, a currency, and a token representing the card, and you get back a response saying the charge succeeded or failed, with a reason. The provider can rewrite their entire system next month, and as long as the contract holds, your code keeps working.

Most APIs founders touch are web APIs, spoken over HTTP and exchanging JSON. A request has a method (GET to read, POST to create), a URL such as /v1/customers, headers carrying an API key that proves who you are, and sometimes a body. The response carries a status code and data. That is genuinely most of it.

How an API actually works

Four moving parts show up in nearly every integration. Authentication proves the caller is allowed in, usually with an API key or an OAuth token. Endpoints are the named operations available to you. Rate limits cap how many calls you can make in a window, which is why bulk jobs need queues and retries. Versioning lets the provider ship changes without breaking you, which is why URLs so often start with /v1/.

Two failure modes deserve attention before you write code. Every network call can fail, so anything important needs a retry with backoff. And every call costs time, so ten sequential calls in one page load will make your product feel slow.

Why APIs matter for startups

For a team of one to five people, APIs are how you punch above your weight. Payments, email delivery, authentication, search, maps, and transcription are all a few hours of integration instead of a few months of building. That decision alone can be the difference between shipping a minimum viable product in six weeks and shipping it in six months.

Publishing your own API is a different decision. It turns your product into something other people build on, which creates switching costs and can open a partner channel. It also means you now support a contract forever, because breaking it breaks other people's businesses. Do not publish one until you have a customer asking for it by name.

APIs in practice

Say you run a three person tool that generates invoices for freelancers. Users keep asking for their invoices to land in their accounting software automatically. Instead of building an accounting product, you integrate with an accounting platform's API: a nightly job reads your new invoices, maps each one to their expected fields, and posts them.

The first version breaks constantly because you ignore rate limits and retry immediately on failure. You add a queue, a five second backoff, and a dead letter list a human reviews each morning. Sync failures drop from dozens a week to a handful, and the integration becomes the feature customers cite when they renew.

Common mistakes

• Putting API keys in client code. Anything shipped to a browser or mobile app is public. Keep secrets on your server and proxy the calls.
• No retry or timeout strategy. A provider having a bad ten minutes should not corrupt your data. Use timeouts, exponential backoff, and idempotency keys on writes.
• Assuming the response shape never changes. Validate what you receive and fail loudly, rather than silently writing empty fields to your database.
• Building your own API too early. A public API you cannot break is a permanent maintenance cost. Wait for real demand.
• Ignoring cost per call. Metered APIs can quietly become your second largest expense. Track usage against revenue.

Related concepts

APIs are the connective tissue behind microservices architectures, and a well documented one is often bundled with an SDK so developers can integrate faster. For any SaaS product, thoughtful API design is also a scalability decision, because the contract you publish today is the one you have to keep serving at ten times the volume.