Foundations

How APIs Work

Understand APIs, requests, responses, authentication, webhooks, and how Nigerian SaaS products connect to payments and messaging.

How APIs Work only counts when it ends in something you built and can open in a browser.

LearnBuild

Outcome

Explain APIs to beginners and SaaS builders.

Read API documentation without panic; end with a small live demo, a README, a screenshot, and an explanation in your own words.

Read API documentation without panic
Send test requests and inspect responses
Plan integrations for payment, WhatsApp, email, and maps

Operator Brief

Buyer, user, workflow, and wedge.

Buyer

The first person to judge this is whoever you show it to next — a senior developer, a mentor, a founder, a business owner. They are checking one thing: can you explain what you built?

User

A beginner or working developer who wants study time to turn into something real and inspectable, not another saved tutorial tab.

Current manual workflow

Most people watch videos, copy the code, lose the project, and end up with nothing to show and no bug they can explain fixing.

Wedge

Build the smallest version of how apis work that answers one real question someone would actually ask.

How APIs Work build order

Step 1

REST basics

Use Postman to grasp the idea, build one small feature, run it on your machine, deploy it, then write down what changed and what you still need to check.

Step 2

Authentication

One deployed page or feature, one README, one set of screenshots, one short write-up. No dashboard sprawl, no half-built extras.

Step 3

JSON

Ship a tiny how apis work build with a public link, a GitHub repo, a README, and a 60-second note on how it works.

Step 4

Webhooks

Do not accept AI code you cannot explain line by line. Do not publish secrets, private client data, or payment keys in screenshots or repos. Run the app, check mobile layout, and keep a small bug log before calling it finished.

Step 5

API errors

Real, explainable work opens doors — a portfolio piece, an apprenticeship, a remote application, a first chat with a small business — if and when you want them.

Hands-on: call an API and read the response

An API is just a URL you can request data from. These commands send real requests and show you the JSON that comes back. curl is built into macOS and Linux.

1. Make a simple GET request

This asks a public test API for one record and prints the JSON response — the same thing your app's code would receive.

curl https://jsonplaceholder.typicode.com/todos/1

2. Send data with a POST request

POST creates something. You send a JSON body and set the Content-Type header so the server knows how to read it.

curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"My first post","body":"Hello"}'

3. Send an authenticated request

Most real APIs (like Paystack) need a secret key in an Authorization header. This is how you prove who you are. Never commit this key.

curl https://api.paystack.co/transaction \
  -H "Authorization: Bearer YOUR_SECRET_KEY"

4. Read the response cleanly

Pipe the output through a formatter so the JSON is readable. Install jq once, then it pretty-prints any response.

curl https://jsonplaceholder.typicode.com/todos/1 | jq

Field Notes from Nigeria

Why this works here

The Nigerian builder needs a low-data, mobile-first path from concept to deployed proof, with GitHub, screenshots, a written case study, and one credible money path.

Proof and risk standard

Avoid this

Do not accept AI code you cannot explain line by line.
Do not publish secrets, private client data, or payment keys in screenshots or repos.
Run the app, check mobile layout, and keep a small bug log before calling it finished.
Reading tutorials for weeks without shipping a public URL
Letting AI generate code you cannot explain, debug, or test
Skipping Git, browser devtools, deployment, and written documentation
Learning tools without connecting them to a Nigerian business workflow

Proof standard

Live URL
GitHub repo with README
Mobile screenshot
Bug or test note
Plain-English explanation
A deployed mini project
A GitHub repository with a clear README

First proof, then where it can lead

First proof to build

Ship a tiny how apis work build with a public link, a GitHub repo, a README, and a 60-second note on how it works.

Where it can lead you

Real, explainable work opens doors — a portfolio piece, an apprenticeship, a remote application, a first chat with a small business — if and when you want them.

Pricing anchor

While you are learning, the proof itself is the value. If you later turn it into client work, a scoped starter build commonly runs ₦150k-₦500k after a proper conversation.

Outreach script

Message to try

I built a small how apis work demo around a Nigerian business workflow. Can I show you the link and ask what would make it genuinely useful to your team?

MVP boundary

One deployed page or feature, one README, one set of screenshots, one short write-up. No dashboard sprawl, no half-built extras.

Workflow to prove

Use Postman to grasp the idea, build one small feature, run it on your machine, deploy it, then write down what changed and what you still need to check.

Reusable template

01Definition in plain English

02Where it fits in the builder lifecycle

03A Nigerian example workflow

04A small practice task

05A proof artifact to publish

How to measure progress

Deployed projects

Readable commits

Bugs fixed independently

Concepts explained without AI

Portfolio artifacts created

Frequently asked questions

What should I ship first for How APIs Work?

Ship Ship a tiny how apis work build with a public link, a GitHub repo, a README, and a 60-second note on how it works.. Keep the scope tight, document the assumptions, and connect the result to real, explainable work opens doors — a portfolio piece, an apprenticeship, a remote application, a first chat with a small business — if and when you want them..

What is the biggest risk with How APIs Work?

Do not accept AI code you cannot explain line by line. The VibeCoded standard is to expose the buyer, workflow, proof, pricing anchor, and review notes before calling the work ready.

Quality Gate

Editorial standard

Examples are tied to real Nigerian business workflows
The page tells learners exactly what to build next
The advice includes testing, deployment, and review
The page never pretends AI removes the fundamentals
The page targets "how APIs work" without stuffing the phrase.
The operator brief names a buyer: The first person to judge this is whoever you show it to next — a senior developer, a mentor, a founder, a business owner. They are checking one thing: can you explain what you built?
The first proof is explicit: Ship a tiny how apis work build with a public link, a GitHub repo, a README, and a 60-second note on how it works.
Where the work can lead is stated honestly: Real, explainable work opens doors — a portfolio piece, an apprenticeship, a remote application, a first chat with a small business — if and when you want them.
The next action is concrete: Build your first API integration.