What Is an API? The Concept Behind Every App You Use

You sit in a restaurant. You want food, but you cannot walk into the kitchen and cook it yourself. The kitchen has rules: customers stay in the dining area. So how do you get food?

You use the waiter. You tell the waiter what you want (your request). The waiter takes your order to the kitchen (the server). The kitchen prepares the food using its own recipes and ingredients (processing). The waiter brings the food back to you (the response).

You never see the kitchen. You do not know how the food is made. You do not need to. The waiter is the interface between you and the kitchen. As long as you order something on the menu in a way the waiter understands, you get your food.

An API works the same way. Your app (you, the customer) needs data or a service from another system (the kitchen). The API (the waiter) defines what you can request and how to request it. You send a request in the format the API expects, and you get a response back with the data or result you need.

The menu is the API documentation. It tells you what is available and how to ask for it. If you order something not on the menu (send a malformed request), the waiter comes back and says "we do not serve that" (error response). If the kitchen is closed (server is down), the waiter cannot help you regardless of what you order.

APIs are not abstract concepts. You use them constantly, even if you do not realize it.

M-Pesa balance check. When you dial *334# and select "My Account" then "Check Balance," your phone sends a request through the USSD network to Safaricom's server. The server's API receives the request, looks up your account in the database, and sends back your balance. The USSD display shows you the result. The Daraja API is the developer-facing version of this same system: it lets apps do what you do manually through USSD.

Logging in with Google. Many websites show a "Sign in with Google" button. When you click it, the website sends a request to Google's authentication API. Google verifies your identity and sends back your name and email. The website did not ask for your Google password. It used Google's API to confirm you are who you say you are.

Ordering food on Glovo or Uber Eats. When you browse restaurants, the app requests menu data from the platform's API. When you place an order, the app sends order details to the API. When a rider accepts the delivery, the app receives real-time updates through the API. The entire experience is API calls happening behind the scenes.

Weather apps. Your phone's weather widget gets its data from a weather API. The app sends your location (latitude and longitude) to the API, and the API returns the current temperature, humidity, and forecast. The app does not measure the weather itself. It asks another service for the data.

Instagram and Twitter. When you open Instagram, the app sends a request to Instagram's API: "give me the latest posts from accounts I follow." The API returns a list of posts (images, captions, likes, comments). The app renders them on your screen. Every scroll, every like, every comment is an API call.

Most modern APIs are REST APIs. REST stands for Representational State Transfer, but the name is less important than the concept. REST APIs use HTTP (the same protocol your browser uses to load websites) to send requests and receive responses.

A REST API request has four main parts:

1. The URL (endpoint). This is the address you send the request to. Like a URL for a website, but it returns data instead of a web page. Example: https://api.safaricom.co.ke/mpesa/stkpush/v1/processrequest. This URL is the M-Pesa STK Push endpoint. Sending a properly formatted request to this URL triggers a payment prompt on a user's phone.

2. The method. HTTP methods tell the API what kind of action you want:

• GET: Retrieve data. "Give me this user's profile." "Show me the product list."
• POST: Create something new. "Create a new order." "Process this payment."
• PUT/PATCH: Update existing data. "Change this user's email address."
• DELETE: Remove data. "Cancel this order."

3. Headers. Metadata about the request. The most common header is the authorization token: a key that proves you have permission to use the API. The Daraja API requires an OAuth token in the header. Without it, the API rejects your request.

4. Body (for POST/PUT). The data you are sending. When triggering an M-Pesa STK Push, the body includes the phone number, the amount, and the transaction description. The body is usually formatted as JSON (a structured text format that looks like a JavaScript object).

The API receives your request, processes it, and sends back a response. The response includes a status code (200 means success, 404 means not found, 500 means server error) and a body (the data you requested, usually in JSON format).

When APIs send data back and forth, they use JSON (JavaScript Object Notation). JSON is a text format that structures data in a way both humans and computers can read.

Here is what a JSON response from a product API might look like:

{
  "id": 42,
  "name": "Tusker Lager 500ml",
  "price": 250,
  "currency": "KES",
  "in_stock": true,
  "category": "beverages"
}

The data is organized in key-value pairs. The key is the name of the field ("name", "price"). The value is the data ("Tusker Lager 500ml", 250). Curly braces {} wrap an object. Square brackets [] wrap a list. That is most of JSON.

A list of products would look like this:

[
  { "id": 1, "name": "Tusker Lager", "price": 250 },
  { "id": 2, "name": "Coca Cola 500ml", "price": 80 },
  { "id": 3, "name": "Maziwa Mala 500ml", "price": 65 }
]

When you build a backend API, you send JSON. When your frontend receives data from an API, it parses JSON. When you integrate with M-Pesa's Daraja API, you send and receive JSON. Learning to read and write JSON is essential. The good news is that it maps directly to JavaScript objects, so if you know JavaScript, you already know JSON.

As a developer, you will both use APIs built by others and build your own APIs for others to use.

Using APIs (consuming). When you integrate M-Pesa into your app, you are using Safaricom's Daraja API. When you send SMS through Africa's Talking, you are using their SMS API. When you add Google Maps to a page, you are using Google's Maps API. Using an API means: reading the documentation, getting an API key, formatting requests correctly, sending them, and handling the responses (including errors).

Building APIs (creating). When you build the backend of a web application, you are creating an API. Your frontend sends requests to your API endpoints to get data and perform actions. If you build a product that other developers will integrate with (like a payment system or a data service), you are building a public API. Building an API means: designing endpoints, implementing the logic, handling authentication, validating input, returning appropriate responses, and writing documentation.

Most developers do both. A typical day might involve: building a new API endpoint for your frontend (creating) while integrating with the M-Pesa API to process payments (consuming). Understanding both sides makes you effective.

The most valuable developers in Kenya are those who can both build clean APIs and integrate with external services like M-Pesa, WhatsApp, and SMS providers. This combination is what full stack development with African Stack skills looks like in practice.

The Daraja API is Safaricom's API for M-Pesa integration. It is probably the API you will interact with most as a Kenyan developer. Here is how a basic interaction works.

What you want to do: Send an M-Pesa payment prompt (STK Push) to a customer's phone so they can pay for an order.

Step 1: Authenticate. Before any API call, you need an access token. You send a GET request to the OAuth endpoint with your consumer key and consumer secret (provided by Safaricom when you register). The API responds with an access token valid for one hour.

Step 2: Send the STK Push request. You send a POST request to the STK Push endpoint. The body includes: the business short code, the customer's phone number (254712345678), the amount (e.g., 500), a transaction description, and a callback URL where Safaricom will send the result.

Step 3: Customer receives the prompt. Safaricom processes your request and sends an M-Pesa payment prompt to the customer's phone. The customer sees "Pay KES 500 to [your business]?" and enters their M-Pesa PIN.

Step 4: Receive the callback. After the customer pays (or cancels), Safaricom sends a POST request to your callback URL with the transaction result. Your server reads this response, checks if the payment was successful, and updates your database accordingly.

The entire flow involves four API interactions: one to authenticate, one to initiate the payment, one callback from Safaricom, and your response to the callback. Each interaction follows the request-response pattern. Each uses JSON data. Once you understand this pattern, every other API integration follows the same logic.

Our Full-Stack Software and AI Engineering course (KES 120,000) includes hands-on M-Pesa Daraja API integration where you build real payment flows, not just read about them.