APIs and AI

Every workplace in 2026 has an AI story, and almost nobody in the meeting can say what happens technically when the assistant answers. You can. Underneath the spectacle it is the thing you have been reading about for eleven chapters: a program sends an authenticated request to somebody else's server and reads what comes back.

The companies at the center of that story are model providers. A model, here, is a program trained on enormous amounts of text that produces text in response to text; the provider runs it on their machines and rents access to it. The way they rent it is an API. Software POSTs to an address with a JSON body holding the words to work on and a few settings, and the server answers with JSON holding the generated text. A key identifies the caller. A rate limit caps the pace. An error table explains the refusals. There is no fifth ingredient.

The Model Behind a Key

What a model provider sells is exactly the shape this book taught. The request is a POST, because it carries a body: the text to work on, plus settings such as which model to use and how long the answer may be. The response is JSON with the generated text inside it, and next to that, a count of how much was consumed.

That count is the bill. Providers meter by units of text called tokens, which are roughly word fragments, and they charge for the text going in as well as the text coming back. This is Chapter 1's idea of an API as a product with users, support and rules, taken to its most literal form: the meter runs on every request, in both directions, and the invoice is the sum of the counts.

Every AI Feature Is a Request

The writing helper in a document editor, the summarize button in an email client, the support bot on a shop's website: each one is an ordinary application that assembles a request, sends it to a model API, and renders what returns. That is the same construction Chapter 1 described when it pointed out that a weather widget and a card payment are somebody else's API showing through the surface of an app you trust.

Which means these features fail the way APIs fail, and you can now reason about them instead of shrugging. A feature that stopped working for everyone at once looks a lot like a refused credential — a 401 if the key was rotated or revoked, a billing refusal if an expired card took the account's credit with it. A feature that works in the morning and gets slow or sullen at the busiest hour of the afternoon looks like a 429, and AI rate limits are the most talked-about limits in software as of 2026. A feature that hangs and then apologizes is a timeout, and a provider having a bad day is a 5xx. Chapter 7's triage applies to all of it without modification, including the part where you ask whose side the problem is on before you start guessing.

Assistants Are Consumers Too

Here is the newer turn, and the reason this page sits in a beginner's book about APIs at all. Assistants are increasingly built to make API calls themselves: to look up an order, book a slot, file a ticket. When one does, it is a client like any other. It reads a description of what an API offers, sends a request to a real endpoint, and gets back a status code and a body.

The description it reads is often the OpenAPI file from Chapter 6, the machine-readable contract that also generated those try-it-out documentation pages. That file was always meant for programs to read; an assistant is simply a newer kind of program reading it. Nothing about the contract changed to accommodate it.

So every rule of citizenship in this book applies to your automated colleagues, word for word. The key an assistant uses should be scoped to what it actually needs, exactly as Vera's was scoped to reading stations. Its pace counts against the same rate limit as yours. Its retries can double-book a bike as surely as a human's impatient second POST could, which is why Chapter 7 spent a page on which requests may be repeated. And somebody still has to read the docs, choose the scopes, set the budget, and check afterwards what was actually done in their name. The assistant moved the typing. It did not move the understanding.

Where This Goes Next

Two doors, both on this shelf, both natural from here. Working with models as a user — how to ask well, how to verify what comes back, what happens to what you send, and what the request under the chat box actually contains — is its own book: Working with LLMs from Zero, whose Chapter 7 you are now over-prepared for, because it is about the API you have just spent a course learning to read.

Building things that call models in a loop, decide what to do next, and act through APIs is the following rung: Agentic AI from Scratch. It assumes precisely what you now have, which is why it was never the right first book and is a reasonable second or third one.