← All projects
Interactive learning module  ·  Introductory

API Fundamentals

How software talks to software, taught through one small business

Meet Solebound, an independent shoe store with two locations and a busy online shop. Its founder, Amara, has no IT department. Her business runs on a handful of APIs that pass orders, payments and text messages between the tools she already pays for. This module shows what's happening under the hood, then hands you a key to Solebound's API so you can make the calls yourself.

Learning objectives

By the end of this module, you will be able to:

  1. Explain what an API is and identify the APIs a small business depends on.
  2. Break an HTTP request and response into their parts, and read a status code.
  3. Send requests to a working API, then diagnose and fix the errors you cause.
  4. Tell authentication from permission, and apply the basic rules of key safety.
  5. Read API documentation well enough to use an endpoint you've never seen.
Time
About 25 minutes
Format
Self-paced, 6 sections
Practice
Working API sandbox
Assessment
6-question knowledge check
Section 1 · The concept

APIs are all around you

An API is an agreed way for two pieces of software to talk to each other. You don't need to know how the other system works inside. You only need to know what to ask for and how to ask for it.

Amara doesn't have a developer on staff. She connected her tools with a few small cloud functions: short scripts that run on Google Cloud whenever something happens. When a customer checks out on Solebound's Shopify store, nobody emails Amara the order. Shopify sends an HTTP request to a web address her function is listening on, with the order packed inside as JSON. The function reads it and updates the stock count. That exchange is an API call.

APIs are how the modern internet works. Every app you've used today has made dozens of them. They aren't only for developers. They're the language connected systems use to talk, and understanding them is the first step to building those connections.

The APIs Solebound runs on
The restaurant analogy
🍽️
You, the customer
Your application. You know what you want, but you don't walk into the kitchen to get it.
→
📋
The menu
The API documentation. It tells you exactly what you can order and how to order it.
→
🤵
The server
The API itself. It takes your order to the kitchen and brings back the result.
→
👨‍🍳
The kitchen
The system behind the API. You never see it. You just get what you ordered.
Figure 1.1 An API works like a restaurant server: it carries your order to a kitchen you never see.
💡
The key insight: you never need to know how the kitchen works. Shopify's API hands over order data without you understanding Shopify's database. Twilio's API sends a text without you knowing anything about phone carriers. APIs are designed so you don't have to.
Section 2 · The mechanics

Anatomy of an API request

Every request has the same four parts, and every response has three. Click each highlighted part of this real-world Shopify request to see what it does and why it matters.

Figure 2.1 A real Shopify request and its response. Select any highlighted part.

HTTP methods: the verbs
Status codes: what the server is telling you
Section 3 · Practice

Solebound's API sandbox

This is a working pretend API that runs in your browser. Edit any part of the request and send it. The server checks your key, the address, your data and how fast you're calling, just like a real one would. Start from an example, then try to break it.

Start from an example
Headersone per line, Name: value
BodyJSON, used by POST and PUT
Tip: Ctrl + Enter sends from anywhere in the request.
Your sandbox key: sb_live_demo_4f8a2c
It can read orders and stock, change product prices and send texts. It can't create or delete orders. That's on purpose.
the raw HTTP exchange
$ Pick an example or edit the request, then send it.
$ Everything sent and received appears here.
▊
Collect all eight status codes
0 of 8 found

Every one of these is reachable from the sandbox. Click a code for a hint.

Section 4 · Security

Authentication and API keys

An API lives at a public web address. Without authentication, anyone who found the address could call it. Auth is how an API knows you're allowed to be there, and what you're allowed to do.

What happens when a request arrives
📤
Your app sends a request
Authorization: Bearer sb_live_demo_4f8a2c
→
🔍
The API checks the key
Valid? Not expired? Allowed to do this?
→
✅
Key checks out
200 OK and the data
🚫
Key fails
401 or 403 and an error

Figure 4.1 Every request is checked before the server does any work.

The API key rules every practitioner lives by
⚠️
The most common mistake: typing an API key straight into code that ends up in a public GitHub repository. It happens constantly, and automated scanners often find exposed keys within minutes. Keep keys in environment variables or a secrets manager. Always.
Section 5 · Practical skill

Reading API documentation

Reading docs well is what separates someone who can use any API from someone who can only use the ones they were taught. Here's the page for the endpoint you used in the sandbox. Open each section, then test what it says.

The five things to find in any API doc
Section 6 · Assessment

Knowledge check

Six questions on requests, status codes, authentication and documentation. A few ask you to predict what a server will do, which you've already seen happen in the sandbox.

0 of 6 answered