# Application programming interface (API)

An API (application programming interface) is a defined way for one piece of software to ask another for data or actions, such as an app asking its server for a user's orders or asking a payment provider to charge a card.

Also called: API, REST API, Web API, API integration, Third-party API.

## In short

- An API is a contract: **send this request, get this response**. Neither side needs to know how the other works inside.
- Your app talks to its own backend through an API, and to services like payments and maps through theirs.
- Each integration adds work, cost, and a dependency on someone else's uptime and pricing.
- Good APIs are documented, versioned, and secured, so they can change without breaking the apps that use them.

## What an API does

An API works like a menu. It lists what you can ask for and what you will get back, without showing the kitchen. A mobile app does not read the database directly. It sends a request to an API, such as give me this user's last ten orders, and the server sends back the data in an agreed format, usually JSON.

**Diagram: One request through an API.**

1. App (User taps to see their orders)
2. API request (GET /orders, with a login token)
3. Backend (Checks access, reads the database)
4. Response (The orders, as JSON)

_The API is the agreed boundary. The app and the server can each change inside as long as the request and response stay the same._

## Your own API and other people's

Most products deal with two kinds. The first is the product's own API, which connects the web or mobile front end to its [backend](https://www.choie.co/glossary/backend). The second is third-party APIs, which let the product use services it does not build itself. At Choie, the people who design a screen also write the code behind it, so what the screen needs and what the API returns are decided together.

| Need | Typical third-party API | What to check |
| --- | --- | --- |
| Payments and subscriptions | Stripe, Paddle, app store billing | Fees, supported countries, refund flows |
| Email and SMS | Postmark, Resend, Twilio | Deliverability, cost per message |
| Maps and location | Google Maps, Mapbox | Pricing per request, usage limits |
| Sign-in | Google, Apple, Auth0, Clerk | Which providers your users expect |
| AI features | OpenAI, Anthropic, Google | Cost per call, data handling, rate limits |

A [headless CMS](https://www.choie.co/glossary/headless-cms) is another example: it stores content and delivers it to a website or app through an API.

## REST, GraphQL, and webhooks

- **REST** is the most common style. Each kind of data has its own address, such as /orders or /users/42, and standard actions like GET to read and POST to create.
- **GraphQL** uses a single address where the app describes exactly which fields it wants. It suits screens that combine many kinds of data, at the cost of more setup.
- **Webhooks** reverse the direction. Instead of your app asking repeatedly whether a payment succeeded, the payment provider calls your server when it does.

For most new products, a straightforward REST API or the data layer built into the chosen framework is enough. The choice belongs in the [tech stack](https://www.choie.co/glossary/tech-stack) discussion and should follow what the team knows well.

## What integrations cost

An integration looks like a single line in a feature list, but each one brings sign-up and setup, error handling for when the other service is slow or down, testing with real and fake data, and ongoing attention when the provider changes its API or prices. That is why integrations move the cost of a build more than most features.

> **Count them in the scope.** Listing every integration in the [scope of work](https://www.choie.co/glossary/scope-of-work), with what each must do, is one of the simplest ways to keep a fixed price honest for both sides.

At Choie, integrations with payment, identity, or third-party systems are one of the things that set the price of a build, and the written scope fixes that price before work starts. In monthly work, complex integrations are scoped separately. See the [pricing page](https://www.choie.co/pricing).

## Common mistakes

- **Putting secret keys in the app.** API keys for paid services belong on the server, never in code shipped to browsers or phones.
- **No plan for failure.** Every external call can be slow or fail. The product should say so clearly and recover.
- **Ignoring rate limits and pricing.** A provider that is cheap at a hundred users can be expensive at a hundred thousand.
- **Changing an API without versioning.** Mobile apps in the wild keep calling old endpoints for months after an update.

## Common questions

### What is an API in simple terms?

A set of rules that lets one program ask another for data or to do something. For example, a weather app uses a weather service's API to get the forecast instead of measuring the weather itself.

### What is the difference between an API and a backend?

The backend is the server-side system that stores data and runs the product's logic. The API is the doorway into it: the defined set of requests that apps can send to the backend.

### What is an API integration?

Connecting your product to another service through that service's API, such as taking payments through a payment provider or sending email through an email service.

### Do I need GraphQL for my app?

Usually not at the start. A simple REST API or the data tools built into your framework cover most early products. GraphQL becomes worth it when many screens combine data in different shapes.

### Who keeps an integration working after launch?

Someone has to watch for provider changes, expired keys, and new pricing. Choie fixes defects in its own work at no charge for 30 days after launch. After that, changes such as a provider updating its API are covered by a monthly engagement.

Related: [Backend](https://www.choie.co/glossary/backend), [Tech stack](https://www.choie.co/glossary/tech-stack), [Software as a service (SaaS)](https://www.choie.co/glossary/saas), [Custom web application](https://www.choie.co/glossary/custom-web-application), [Headless CMS](https://www.choie.co/glossary/headless-cms).

HTML: https://www.choie.co/glossary/api