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.
Also called: API, REST API, Web API, API integration, Third-party API.
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.
One request through an API
- 01AppUser taps to see their orders
- 02API requestGET /orders, with a login token
- 03BackendChecks access, reads the database
- 04ResponseThe orders, as JSON
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. 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 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 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, 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.
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.