Backend APIs with Claude Code
Build your first backend API with Claude Code. 5 hands-on labs covering what an API is, routing + validation, error handling, OpenAPI documentation, and testing — Claude Code writes the code; you learn what to ask for and how to read what comes back.
About This Course
Build your first backend API with Claude Code as your coding partner. Learn what an API actually is in plain English, how it responds to the requests your frontend sends, how to shape data between the client and server, how to handle errors cleanly, how to document what your API offers, and how to test it. Every lesson leans on Claude Code you describe what you want, Claude Code writes the code, you run it and understand what came back. You do not need to know TypeScript, Node, or any framework going in; the lessons teach you what to ask for. By the end of this course you will have a working REST API running in your lab environment, you will understand each piece of code Claude Code wrote, and you will be able to extend it on your own.
Course Curriculum
10 Lessons
How APIs talk — the request/response conversation
Every modern app you've used — Instagram, your bank's mobile app, Uber, Spotify — talks to a server using the same two-step pattern: a request goes out, a response comes back. This lesson explains that conversation in plain English using apps you've already used, so when you start building your own API in the next lab, you already know what you're building toward.
What an API is + your first endpoint - Lab Exercises
Open the Lumen Trail backend API starter in VS Code, run it, and watch it respond to your first HTTP request. Then direct Claude Code to add new endpoints — a GET that returns version info, a POST that echoes a JSON body — and understand what Claude Code wrote. By the end of this lab you will be able to describe in plain English what a backend API does, start the development server, hit endpoints with curl, and direct Claude Code to add new endpoints to a running API.
Routes, inputs, and the problem of trusting data
An API with one endpoint is a toy. A real API has dozens, each matched to a URL path, each accepting one of three kinds of input (path parameters, query parameters, or a request body). This lesson explains how a server knows which handler to run, how data gets in, and why every input the server receives has to be checked before it's trusted.
Routing, request validation, and response shaping - Lab Exercises
By the end of this lab you will know how to shape a REST API that handles multiple routes, validates request bodies against a schema, and returns responses with a consistent structure. You will direct Claude Code to add a catalog resource (/items) to the Lumen Trail API with list, single-item, and create endpoints — using Zod to validate incoming data before it ever reaches your business logic.
Status codes, errors, and the double-click problem
A production API has to say "yes" cleanly and "no" even more cleanly. This lesson walks through the five families of HTTP status codes, what a structured error payload looks like, and why apps on flaky networks need a specific pattern called idempotency to keep from accidentally doing the same thing twice.
Error handling, status codes, and idempotency - Lab Exercises
By the end of this lab you will know how to turn an API that "works on the happy path" into one that fails cleanly: structured error payloads with stable codes, correct HTTP status codes for every failure mode, and idempotency keys so a flaky connection can't double-create an item. You will direct Claude Code to add a single error-handling middleware, upgrade every error branch in the Lumen Trail API, and support Idempotency-Key on POST /items.
API contracts — the shared story clients and servers tell
When one team builds the server and a different team builds the mobile app, both have to agree on the exact shape of every request and response — or the app shows wrong data, crashes, or breaks silently. This lesson explains the industry-standard way to write that agreement down: an OpenAPI document, plus a browsable page called Swagger UI that lets anyone read and try your API.
OpenAPI contracts and Swagger UI - Lab Exercises
By the end of this lab you will know how to describe your API with an OpenAPI document so other teams can read and try it in a browser instead of digging through your source. You will direct Claude Code to add a hand-written OpenAPI JSON spec to the Lumen Trail API, serve it at /openapi.json, and mount an interactive Swagger UI page at /docs.
Tests — the safety net that catches bad changes
An API without tests is one bad refactor away from a customer-facing bug. This lesson explains why tests exist, the difference between the three common shapes of tests (unit, integration, end-to-end), what a test actually asserts, and how watch mode gives you under-a-second feedback as you (and Claude Code) make changes.
Testing APIs with Claude Code - Lab Exercises
By the end of this lab you will know how to direct Claude Code to write tests for an HTTP API — the kind that catch regressions before customers do. You will use vitest (the Node ecosystem's standard test runner) to write integration tests that import the Hono app directly, exercise each endpoint, and assert on the response. No port, no network, no process management: a test runs the request through the app in memory and reads the response the same way a real HTTP client would.