The Internet & APIs

The app that worked perfectly — until it didn't

A startup built an AI-powered customer support chatbot. It worked flawlessly in testing. Demo day: the CEO opens the app in front of investors. Types a customer question. The chatbot... does nothing. Blank screen. Awkward silence.

The problem? The chatbot needed to call an AI model (hosted on a server across the internet) to generate its response. That call failed. The app had no error handling. No fallback. Just a blank screen and a room full of uncomfortable investors.

Every AI product you've ever used — ChatGPT, Siri, Google Translate — is not running AI on your device. It's sending your request over the internet to a powerful server, waiting for the server to do the work, and showing you the response. If you don't understand how the internet and APIs work, you can't build, debug, or even properly evaluate AI products.

How the internet works: the postal system

The internet works exactly like a postal system. You write a letter (request), put an address on it, and send it. The postal service delivers it to the right building. Someone at that building reads your letter, writes a response, and sends it back.

Every time you open a website, tap an app, or ask ChatGPT a question, this cycle happens. Sometimes it takes 50 milliseconds. Sometimes it takes 5 seconds. Sometimes (like that demo day disaster) it fails entirely.

There Are No Dumb Questions

"What's a server? Is it different from a regular computer?"

A server is just a computer that's always on and waiting for requests. Your laptop could be a server if you set it up that way. The servers that run AI models are typically very powerful computers with specialised chips (called GPUs) stacked in giant data centres. But the concept is the same: it's a computer that listens for requests and sends back responses.

"What happens when the internet is slow?"

The request still goes through — it just takes longer. Think of it as your letter getting stuck in a traffic jam. Slow internet means bigger delay between sending your request and getting a response. For AI products, this delay is called latency, and it's one of the biggest factors in user experience.

HTTP: the language of the internet

When your device sends a request to a server, they need to speak the same language. That language is called HTTP (HyperText Transfer Protocol). Think of it as the standardised form you fill out when sending a package.

There are a few types of HTTP requests, but you only need to know two:

When you type "chatgpt.com" and press Enter, your browser sends a GET request: "Give me the ChatGPT webpage."

When you type a message and press Send, your browser sends a POST request: "Here's my message — process it and give me a response."

Every HTTP exchange has two parts:

The request (what you send):

POST /v1/messages HTTP/1.1
Host: api.anthropic.com
Content-Type: application/json

{"prompt": "Explain gravity to a 5-year-old"}

The response (what comes back):

HTTP/1.1 200 OK
Content-Type: application/json

{"response": "Gravity is like the Earth giving you a big, invisible hug..."}

See that 200 OK? That's a status code — the server's way of saying "I got your request and here's your answer." There are other codes too:

APIs: the restaurant waiter

Now for the big one. API stands for Application Programming Interface. It's how one piece of software talks to another piece of software.

Forget the technical definition. Here's the analogy that will stick:

An API is a waiter in a restaurant.

You (the customer) sit at a table. The kitchen (the server) has all the food. But you can't walk into the kitchen yourself. You need the waiter (the API) to:

1. Take your order (receive your request)
2. Bring it to the kitchen (forward it to the server)
3. Bring back your food (return the response)

The waiter doesn't cook. The waiter doesn't eat. The waiter is the interface between you and the kitchen. And critically, the waiter only lets you order items that are on the menu. You can't ask for things the kitchen doesn't make.

That menu is the API documentation — it tells you exactly what requests you can make, what format they need to be in, and what you'll get back.

There Are No Dumb Questions

"Why can't the app just do the AI processing itself? Why call an API?"

Because AI models are enormous. GPT-4 and Claude are hundreds of gigabytes in size and require specialised GPU clusters to serve at scale — infrastructure costing hundreds of thousands to millions of dollars — which is why they run in data centres, not on your device. Your phone or laptop can't run them locally. So the model lives on a powerful server, and your app calls it via an API. It's like asking "why can't you cook the meal at your table?" — because the kitchen has the oven, the ingredients, and the chef.

"Do I need to know how to code to use an API?"

To call an API programmatically, yes — but many tools now let you use APIs without code. Platforms like Zapier, Make, and even ChatGPT's custom GPTs let you connect to APIs through visual interfaces. Understanding what an API is and how it works is valuable even if you never write a line of code.

JSON: the universal order form

When you place an API order, you need a standard format — so the kitchen knows exactly what you want. That format is JSON (JavaScript Object Notation). Think of it as a universal order form that every restaurant in the world agrees to use.

Here's what JSON looks like:

{
  "name": "Jane Smith",
  "order": "Caesar salad",
  "modifications": ["no croutons", "dressing on the side"],
  "drink": "water",
  "quantity": 1
}

JSON has a dead-simple structure:

When you send a prompt to Claude's API, your request is JSON:

{
  "model": "claude-sonnet-4-20250514",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Explain APIs like I'm 10 years old"
    }
  ]
}

And the response comes back as JSON:

{
  "id": "msg_123",
  "content": [
    {
      "type": "text",
      "text": "An API is like a waiter at a restaurant..."
    }
  ],
  "model": "claude-sonnet-4-20250514",
  "usage": {
    "input_tokens": 14,
    "output_tokens": 52
  }
}

See the usage field? That tells you how many tokens you just spent — a token being the basic unit AI models use to measure text (roughly ¾ of a word in English; "Hello, world!" ≈ 4 tokens). Token count determines cost: more tokens sent or received means a higher bill. Every API response includes metadata like this.

Why every AI product calls an API

Here's the thing that ties this whole module together. Let's trace what happens when you type a message into ChatGPT:

Six steps. Most of them happen over the internet via APIs. If any step fails — your internet goes down, the API rejects your request, the model server is overloaded — you get an error.

This is true for every AI product:

No API, no AI product. It's that simple.

Back to that demo-day disaster. After the meeting, the team went back and added three things: retry logic (try the API call again if it fails), a timeout (don't wait forever), and a fallback message ("Something went wrong — please try again"). Their next demo worked. The fix took one day. Understanding why it failed is this module.

Key takeaways

• The internet is a postal system — your device (client) sends requests to servers, and servers send back responses. Every AI interaction follows this pattern.
• You can read HTTP status codes to understand what went wrong: 200 = success, 401 = no permission, 429 = too many requests, 500 = server error.
• An API is a waiter — it takes your request, delivers it to the kitchen (server), and brings back the result. The menu (documentation) tells you what you can order.
• JSON is the universal format for API communication — structured, readable, and used by virtually every AI API in existence.
• Every AI product depends on APIs. No API connection = no AI functionality. Understanding this is essential for building, evaluating, or troubleshooting any AI-powered product.