What is an API? Application Programming Interface

The short answer

An API, short for application programming interface, is an agreed way for one piece of software to ask another to do something or to give back some information. It defines what you may ask for, how you must ask, and what you will get in return.

You use APIs every day without noticing. When an app shows today's weather, it asks a weather service through its API. When you pay with UPI inside an app, the app calls a payment provider's API. When a website shows a map, it is asking a mapping service.

If you remember one thing, remember this: an API is a menu, not a kitchen. It tells you what you can order. It does not let you walk in and cook.

The restaurant, a little further

You sit at a table, you read the menu, you tell the waiter what you want, and the waiter brings it from the kitchen. You never see the kitchen, you do not need to know how the food is made, and the kitchen does not need to know anything about you except your order.

In software the app is you, the API is the menu and the waiter, and the server is the kitchen. The great benefit of the arrangement is that either side can change without breaking the other, as long as the menu stays the same. A restaurant can swap its chef without reprinting the menu.

That is why APIs matter so much in business software. They let different systems be built by different people, at different times, and still work together.

Where you will meet them

There are three places an API shows up for a business owner.

Your own app talking to your own server

A mobile app almost always talks to a back end through an API. The app asks for the list of products, or sends a new order. This one you control and pay for in development.

Your product talking to someone else's

Payments, SMS, email, maps, WhatsApp messaging, identity checks and accounting systems are all reached through their providers' APIs. You rely on them, and you usually pay them by usage.

Other people talking to yours

If you want partners or customers to connect their systems to yours, you publish an API. That is a product in itself, with documentation, keys, limits and support.

Why this word appears in your contract

APIs are where cost and risk hide in a software quote. Three things are worth knowing.

1. Each integration is its own piece of work. 'Payment integration' is not one line; it can be several days of design, building and testing, with a separate test period.
2. Many APIs charge per use or per month, and that bill goes to you, not to the developer. Ask for an estimate at your expected volume.
3. You depend on the provider. If they change the price, the rules or switch the API off, your product is affected. Ask what the plan is.

Keys, limits and versions

To use most APIs you are given a key, a long string that identifies you. Keys must be kept secret. A key left in the code of a mobile app can be extracted by anyone, and a leaked key can run up a bill or expose data.

APIs also set limits: how many requests per minute, how large a file, how much data. A product that works with ten users can hit a limit at ten thousand. Ask what the limits are and what happens when they are reached.

Finally, APIs have versions. Providers retire old versions on a timetable. Someone has to own the job of keeping your integrations current, and it is worth deciding who before launch rather than after an outage.

What to ask your developer about APIs

• Which third-party APIs does this product depend on, and what does each cost at my expected volume?
• Where are the keys stored, and who can see them?
• What happens to my product if a provider has an outage or raises its price?
• Are there limits I might reach, and how will we know?
• Who updates the integrations when a provider changes them?
• If I want partners to connect to my system later, what would that involve?

A walk-through with a real example

Suppose you build a small shop app and want customers to pay with UPI. Your app does not move money itself. It would be illegal and unwise for it to try. Instead it uses a payment provider's API.

1. Your app tells your own server how much to charge.
2. Your server asks the payment provider, through its API, to create a payment for that amount.
3. The provider replies with a reference that identifies it.
4. Your app opens the provider's payment screen using that reference.
5. The customer pays, and the provider tells your server the result.

Each arrow in that list is an API call. Each one has rules about what must be sent and what comes back. If any of them is skipped or done carelessly, you can end up with orders marked paid that were not, or customers charged with no order.

That is why a developer building a payment feature is doing real work, and why it deserves its own line in a quote.

You will hear the word REST

Developers often say a REST API. REST is a set of conventions for how an API is shaped, built around the web's own ways of asking for things. You do not need to remember the details. If someone tells you they will build a REST API for your app, they mean they will build the standard kind of back end that a mobile app talks to.

You may also hear about GraphQL, a different style that lets the app request exactly the fields it wants. Both are common. The choice matters to the developers and rarely to you. What matters to you is that the API is documented, tested and secured.

APIs and security, in a paragraph you can act on

Most data breaches that involve an app trace back to an API that was not protected properly. Not because the technology is weak, but because a rule was missed: an endpoint that returned another user's data if you changed a number in the address, a key hard-coded into the app, an old test interface left switched on.

You do not have to know how to prevent those. You have to know to ask. Ask whether every request is checked to confirm that the person asking is allowed to see what they asked for. Ask whether the API has been tested by someone other than the person who built it. Ask where keys are kept, and how they are changed if one leaks.

For an app handling personal data in India, these are not optional questions, because the law places the responsibility for protecting that data on you, not on your developer.

Documentation is part of the API

An API without documentation is a menu in a language nobody reads. If your developer builds one, either for your own app or for partners, the documentation is part of the deliverable: what each request is called, what it needs, what it returns, and what errors it can produce.

Good documentation outlives the developer. When someone new joins the project in a year, it is what lets them understand how the pieces connect without reading every line of code. Ask for it in the scope, and ask to see an example from a past project.

Say it back

Here is a sentence you can use in a meeting to check that you have it: 'Our app does not do this itself. It asks another service to, through an agreed set of requests called an API, and we pay for each ask.'

If you can say that, and you know to ask which APIs are in the quote and what they cost, you understand more about the term than many people who use it every day.