Practice Set: API as the Second Interface

Send real requests to real machines, put a model behind one of them, then design every request your own app needs.

Self-pacedFinish before you start the next lesson

The practice set in one sentence

Work through the ten steps of the Request Builder in your browser, keep what each step produces, and finish by writing the API table for your own app.

01How It Works

Open the Request Builder. Everything happens in that page. Nothing to install.
Do the steps in order, 1 to 10. Each step ends with a checkpoint. Tick it when you have the result; ticks save on this device.
Keep what the steps produce. Screenshots and short notes, as listed in section 03 below.
Keep it together in one note or folder, and finish before you start the next lesson. Halfway, the build guide checks your progress: steps 1 to 8 done and a draft of your API table.

Plan for about two hours in total. Step 8 needs a free Groq account; create it with Google, no card needed.

02In the Browser, Then in Python

Every step

Every step, in the browser

The Request Builder sends real requests for you. You fill in the four parts and read the reply. That is the whole skill.

Optional extra

Run step 8 in Python

Using the Python setup from Block 1 · Week 1, run the Python version of the Groq request shown in step 8. It becomes the body of your FastAPI route in the next lesson, Building APIs and the backend.

03What to Produce

Tick each deliverable when it is ready. Ticks save on this device.

1. A 201 from the real Aarav serviceStep 4A screenshot of the reply with the diagnosis in it. Mask your key if it shows anywhere.
2. The "break it" tableStep 5For 400, 401, 404 and 405, plus the 500 from /aarav/broken: what you changed, the code you got, and the part it points to. Use the template below.
3. A 200 from Groq, twiceStep 8The two answers to the same request, side by side, and one line: which would you trust, and why?
4. Where your key was, and where it should beStep 9One sentence: where you found your key in DevTools, and which box it should live in instead. Never a screenshot of a key.
5. Design your APIStep 10Every request your app needs, in the table format below. At least one request calls a model. Every key marked with the box it lives in.

Deliverables ready

0 / 5

Template for deliverable 2: break it on purpose

What I changed	Code I got	The part it points to
Example: deleted the closing brace of the package	400	package
	401
	404
	405
Sent anything to `/aarav/broken`	500	None of yours: their machine

04Deliverable 5: Design Your API

Use a real workflow you have observed, in your own work or someone else's. If you do not have one yet, use Aarav's workflow. Start from one question: what does your user do, and which of those actions would your app need another machine for?

The worked example: Aarav's app

CRUD	Method	Address	Package in	Reply	Key
Create	POST	/workflows	{"description": "..."}	201 + workflow id · 400 if the description is missing	None from the UI
Read	GET	/workflows/{id}	none	200 + the workflow · 404 if no such id	None from the UI
Create	POST	/workflows/{id}/diagnoses	none; the backend sends the workflow to Groq	201 + diagnosis · 5xx if Groq fails	Groq key, in the backend
Read	GET	/workflows/{id}/diagnoses	none	200 + past diagnoses	None from the UI

Three boxes sit behind that table: UI → backend → Groq. The UI calls only the backend. The backend holds the Groq key and stores the data, because a page can do neither.

Your table

CRUD	Method	Address	Package in	Reply, with codes	Key, and the box it lives in

Check your table before you move on

Every action is one of Create, Read, Update, Delete, spelled with the matching method.
Addresses are nouns (/workflows), not verbs (/getWorkflow).
At least one request calls a model.
No key sits in the UI box.
Each reply lists the success code and at least one failure code.

05Rules

Predict the code before you send.

Write down the code you expect before every request in steps 4 to 6. Keep the prediction even when it is wrong; the wrong ones are where you learn.

Never paste a key anywhere others can see it.

Not in a message, not in a screenshot, not in an AI chat. If a key leaks, revoke it and create a new one. See step 9.

Use your own Groq account.

Groq's free limits apply per account, not per key: 30 requests a minute and 1,000 a day on openai/gpt-oss-120b. A shared account runs out for everyone at once.

Stuck for more than 20 minutes?

Check Troubleshooting first. Then write down the exact error and code, what you tried, and the request with the key masked. The question template there often finds the answer for you.

06Where to Keep It

Keep all five deliverables together in one note or folder, finished before you start the next lesson. The build guide walks through the Groq step and how to check an API design. Start from a draft; it does not need to be finished first.

Four things in, two things out.Companion pages: Request Builder · notes · troubleshooting · kit