What Is an API? A Simple Explanation Using a Restaurant Waiter

An API is the waiter between your app and the system that does the work. Here is what that means, with a restaurant example, local use cases and questions to ask your developer.

Category: Engineering

Your developer says, "We'll connect to the payment API." You nod, then wonder what you just agreed to and what it will cost.

You don't need to code to understand APIs. If you have ever eaten in a restaurant, you already know how one works.

The restaurant in one picture

Picture a restaurant in Bamenda on a busy Saturday. You sit down and read the menu. You don't walk into the kitchen and tell the cook how to fry the plantains. You call the waiter, say what you want, and wait. The waiter takes your order to the kitchen, and the kitchen cooks. The waiter then brings the plate back to your table.

That waiter is the API.

API stands for Application Programming Interface. The name is less important than the job. An API is a set of rules that lets one program request data or actions from another program without knowing how that program works internally.

Here is how the pieces match up:

Following one order from start to finish

Take a customer buying a pair of shoes on an online shop in Douala.

1. The customer picks something. They tap "Pay with mobile money" on the shop's website. This is the customer ordering.
2. The website calls the waiter. It sends a request to the payment company's API: this phone number, this amount, this order reference.
3. The waiter goes to the kitchen. The API passes the request to the payment system. That system talks to the mobile money network, which sends a prompt to the customer's phone.
4. The kitchen cooks. The customer enters their PIN or confirms the prompt. The money moves.
5. The waiter returns. The API sends the result back to the website: paid, failed or pending.
6. The customer gets the plate. The website shows "Payment received" and the shop starts packing the shoes.

The shop's website never needed to know how mobile money works inside. It only needed to know how to order from the menu.

Why the waiter matters

Without a waiter, every customer would walk into the kitchen. It would be chaos, and the restaurant wouldn't allow it. APIs exist for the same reasons.

• Safety. The kitchen decides what leaves it. An API shows only the data and actions the owner wants to share. Your website doesn't get direct access to someone else's database.
• Simplicity. You say "one plate of ndolé" and don't explain how to cook it. Developers call a ready-made function and don't rebuild a payment network.
• Freedom to change. Because the waiter exists as a middle layer, the kitchen can change how it operates, hire a new chef or install a new oven. The customer still orders the same way. A company can rebuild its whole system, and apps that use its API keep working.

The rest of the restaurant

The analogy covers more of API vocabulary than most people expect.

The menu is the documentation

A good API has a written menu. It lists what you can ask for, what details you must give, and what you get back. You can't order "something tasty." You order what is on the menu, in the form the waiter understands. If you ask for a dish that doesn't exist, the waiter says so. In software that is an error message.

The API key is your membership card

Some restaurants only serve members. An API often works the same way. Authentication is how the API knows who is making the request. It is often done with an API key, a unique string of characters, like showing a membership card to the waiter.

Treat that key like a bank card PIN. Don't put it in a public WhatsApp group. Don't paste it into code that visitors can view. Don't email it around. If it leaks, someone else can place orders on your account.

Waiting for the food

Some dishes take time. Good restaurants hand you a ticket number and call you when the food is ready. APIs do this too. A payment may come back as "pending" because the customer hasn't confirmed on their phone yet. The system later sends a "call-me-back" message, called a webhook, when the result is final.

If you run a shop, this matters. Never mark an order as paid just because the customer says they paid. Mark it paid when the payment provider confirms it.

Where you already use APIs in Cameroon

You use APIs every day without seeing them.

• Mobile money on a website. Gateways connect websites to MTN MoMo and Orange Money. One developer wrote this month that in Cameroon, mobile money is the payment API. He explained how he took payments for two small products through CamPay. Other providers, such as Flutterwave and PayUnit, offer similar APIs.
• Maps and delivery. A delivery app that shows a driver on a map is asking a mapping service for locations.
• SMS and email. When a school sends fee reminders to parents or an NGO sends a confirmation to a donor, the system is calling a messaging API.
• Login with Google. The "Sign in with Google" button asks Google's API to confirm who you are.
• Your own systems. A mobile app for your business needs an API on your server. The app is the customer, and your database is the kitchen.

What this means if you are hiring a developer

You don't need to read API documentation. You do need to ask a few plain questions.

1. Which APIs will you use, and who runs them? Each one is a service from a third party, and you depend on it. Know the names.
2. What does each one cost? Many charge a percentage per transaction or a monthly fee. Ask for exact figures from the provider. Don't accept a guess.
3. Where are the API keys stored, and who owns the accounts? The accounts should be in your business name, not your developer's personal email.
4. What happens if the API is down? If the payment provider has an outage, does your site show a clear message or break?
5. How do we confirm payments? The answer should include checking payment status with the provider. A customer's screenshot is not confirmation.
6. Did you test in a sandbox first? A sandbox is a practice kitchen. Orders there use pretend money. Good providers offer one.

Common mistakes

• Trusting the browser instead of the server. Payment confirmation must be checked on your server, not just in the customer's browser.
• Ignoring duplicates. The same webhook can arrive twice. Your system should handle that and not ship two orders. The developer quoted above makes the same point: sandbox testing and idempotent webhook handling are the parts that quietly take time.
• Building what you can rent. Don't build your own payment system when a tested one exists.
• Relying on one provider with no plan B. Have a fallback, even if it is a manual process, for when the provider is down.

If you want to learn to build one

Building an API is a good first backend project. In Laravel, the PHP framework many Cameroonian developers use, you define routes. Each route is a dish on the menu. You then write the code the kitchen runs for it. A simple example is an API that lists products and takes orders for a local shop. It takes a few days to understand and a few weeks to do properly, with login, validation and error handling.

This is the kind of project we use at Aneta Prime, both in client work and in our 6-week AI-first coding bootcamp in Bamenda. You learn faster by building a small waiter yourself than by reading about one.

The short version

• An API is the waiter between two pieces of software.
• The menu is the documentation, and your order is a request.
• The plate coming back is the response.
• An API key is your membership card, so keep it private.
• Ask your developer which APIs they use, what they cost, and what happens when one fails.

The next time someone says "we'll use an API," you can ask which kitchen they are ordering from.

Tags: API, web development, learning to code, Laravel, digital business, Cameroon