In Part IV you learned to choose a model for a job, and in Class 12 you sent a model a structured request through OpenRouter and got a structured reply. You already used this class's subject: you called an API.

In Class 3 you learned JSON — the structure software exchanges. An API is one of the main roads it travels on: one program sends a structured request to a published address, and another returns a structured response or carries out a permitted action.

Start with breakfast weather in Brussels

Imagine you open a weather app and it says: Brussels, 9°C, rain at noon. Your app did not guess or read a web page like a person. It sent a short question to a weather service — "current conditions for 50.85, 4.35" — and got short JSON back: temperature, humidity, wind, forecast slots.

That software-to-software question-and-answer is an API exchange: ask precisely, answer precisely.

The seven terms, plainly then technically

Here is the vocabulary for the whole class:

The complete exchange looks like this:

Your app / agent → request to an endpoint → service checks it
→ service returns JSON → your app uses the result

Your app never reaches inside the service. It asks at the counter, and the counter decides what to hand back — so the service can redo its kitchen without breaking every app.

A website is for clicking; an API is for calling

A website is designed for a person to click — headlines, buttons, layouts. It changes often, and a small redesign breaks anything that tried to scrape it. An API is designed for software to call consistently: endpoint names and field names are a contract. A field called temperature_2m means the same thing next month, while the homepage can be redesigned freely around it.

That is why serious apps call APIs instead of scraping pages. Scraping is reading the menu through the window with binoculars. Calling the API is walking up to the counter and ordering. The same counter also handles writes, not just reads: create a customer, send an email, publish a post, query a database, or ask a model to respond — the OpenRouter call from Class 12 was exactly that last one. The shape is always the same; only the permission changes, which is Class 14's subject.

A small, real API map

Let us anchor this in real services:

Notice the third row is deliberately vague. Choosing a production provider is a data decision, not just an API decision. Part V teaches how to call and control an API; Part VI teaches whether the underlying data is worth using.

Two things you should not assume

Yahoo Finance has no general public API. Yahoo's site is useful, and unofficial wrappers exist — but Yahoo's official developer pages document Sign-In and Fantasy Sports, not a public Finance API. Do not build on an unofficial endpoint as if it were a contract. ByeBuy market data comes from the Data directory in Part VI.

Realtor.com is not a free listing API. The consumer site teaches you the market, but listings carry MLS, licensing, geography, freshness, and redistribution questions. No free feed hides behind the homepage. The Data directory points you to the right provider.

That OpenRouter call was an API call

The Class 12 request — a POST to https://openrouter.ai/api/v1/chat/completions with a key, a model name, and a messages array — returned JSON with choices and usage. Structured input in, permitted work, structured output with a meter reading. Every lesson to 13.5 is learning to read each half of that exchange on purpose.

Practical exercise: map two exchanges

1. SEC (guided). Pick a public company, find its CIK in the EDGAR API docs, and describe the read-only submissions request: endpoint URL, required identifier, and three JSON fields a research app would save (e.g. form, filing date, accession number). 2. One app you use (banking, maps, weather, calendar, music). One paragraph: client, service, request, response contents, and runtime (browser, server, or CLI) with one reason.

Finish line: two short paragraphs — one for the SEC exchange with endpoint + three fields, one for your chosen app with client, service, request, response, and runtime.

Verify: for the SEC part, can you point to the exact docs page that names the endpoint? If you cannot, you are guessing, not mapping.

Common failure mode: describing the website ("the app shows a chart") instead of the exchange ("the client requests X from Y, receives A, B, C"). Eyes on the counter, not the dining room.

Check your understanding

1. In one sentence, what is an API — and what are the client and the service in the Brussels weather example? 2. What is an endpoint, and how is it different from a website page? 3. Why do apps call a weather API instead of scraping the weather homepage? 4. Why should SEC data.sec.gov requests run from a server or CLI rather than browser-only code? 5. Why is it unsafe to treat an unofficial Yahoo Finance endpoint or the Realtor.com homepage as a production API contract?