Request Builder

01The parts: your Round Three message, translated

This is the winning message from Round Three. Below it is the same request written the way HTTP writes it. Tap a coloured part to find its twin.

• Checkpoint: I can name the four parts of a request and the two parts of a reply, without looking

02Read: your first request

A Read fetches something that already exists. httpbin.org is a public echo machine: it sends back whatever it receives, so you can see exactly what you sent.

1. Look at the four bands. Address is filled in for you. Action is Read · GET. Key: none needed. Package: none, because a Read sends no package.
2. Press Send. You should see a large 200, and under The part you want, your text.
3. Type a sentence with a space in the text box, like hello world, and watch the address. The space turns into %20 before anything is sent. An address cannot hold a space, so it is translated. Your code and your tools will not always do this for you; a raw space in an address is a classic 400.
4. Click Show the raw request. This is the request as text: the action, the address, and nothing else.

• Checkpoint: a 200, and I saw a space become %20

03Create: send a package

Same echo machine, a different door, a different action. This time you send something: Aarav's Friday workflow, as JSON.

1. Check the package band. It holds {"text": "…"} and says ✓ valid JSON. Try deleting a quote: it turns red. Put it back.
2. Press Send. Look for 200, then find your text at json.text in the reply.
3. Click Show the raw request. A package needs one more header, Content-Type: application/json, so the machine knows which format to read. Machines do not guess.

• Checkpoint: a 200, and my text came back at json.text

04Round Three, for real

The machine from Round Three is real. It lives at __SITE__/aarav and checks the parts in the order you learned them: address, action, key, package. It needs a key, and it issues its own.

Part A · Create a key

1. Replace your name in the package with your name.
2. Press Send. Expect 201: something new was created, your key. It is copied into Part B's key box for you.

Part B · Create a diagnosis

1. Check the key band holds your aarav_… key. Press Show to check it pasted fully.
2. Press Send. Expect 201 and a diagnosis of Aarav's Friday report.
3. Press Send the same request again. The two replies sit side by side. They are identical: this machine follows rules. Remember that for step 8.
4. For the practice set: take a screenshot of the reply. The reply shows only the start of your key.

• Checkpoint: a 201 key, then a 201 diagnosis, twice, identicalPractice set item 1: the screenshot.

05Break it on purpose

Every failed request comes back with a code, and the code points at one part. Learn the codes by causing them, one part at a time.

1. Pick a button below. It changes one part of the Part B request above.
2. Before you press Send, write down the code you expect.
3. Press Send in Part B. The red box names the part and what to change.
4. Press Put it right, then try the next button. Fill in the practice set table as you go: what you changed, the code you got, the part it points to.

Then: Read what you created

In Part B, switch the action to Read · GET and press Send. You created diagnoses a few minutes ago. The reply is 200 and an empty list. Where did they go? This machine has no database, so nothing it creates is kept. Where data should live is Block 1 · Week 3 · Databases and domain modelling.

• Checkpoint: I caused a 400, 401, 404 and 405, and predicted at least two of themPractice set item 2: the table.

06Whose fault? Every code

Each card sends one real request. Before you press Send, pick whose fault the reply will be. 2xx worked. 4xx you sent something wrong. 5xx their machine broke.

• Checkpoint: all eight cards sent, and I can say whose fault each family is

07Read real traffic

Every request you sent here is visible in your browser's own tools. Real products work the same way. Reading this is how you check what an app actually sends.

1. Open DevTools. Mac: Cmd Option I. Windows: F12 or Ctrl Shift I. Or right click anywhere, Inspect.
2. Click the Network tab, then the Fetch/XHR filter. Click the clear button (a circle with a line).
3. Scroll up to step 4, Part B, and press Send. A row named diagnoses appears.
4. Click it and find each part:

   Address	Headers → Request URL
   Action	Headers → Request Method
   Key	Request Headers → authorization
   Package	Payload (what you sent) and Response (what came back)
   Code	Headers → Status Code

5. Optional, a real product: do the same on ChatGPT. Reading the Network tab walks through it, including the one header you must never expand or paste.

• Checkpoint: I found all five parts of my own request in DevTools

08Put a model behind it

Aarav's UI has a face. It needs a brain: a model that reads his workflow and writes a plan. Groq runs open-weight models on its own chips, and you reach them with the same four parts. That is Groq with a q, not Grok.

Part A · Get a free Groq key (one time, about 3 minutes)

1. Open console.groq.com/keys in a new tab. It is a website, not a download.
2. Sign in with Google. No card needed.
3. Click Create API Key, name it fde-apis, and click Submit.
4. Copy the key now. Groq shows it once. Do not paste it anywhere except the box below.

Part B · Send your first request to a model

1. Paste the key into the key band. Wait a second: the model list loads from Groq itself. That load was a Read with your key, your first keyed request. If it says 401, the key was not copied fully.
2. Keep the model openai/gpt-oss-120b and the message as it is.
3. Press Send. Expect 200. The answer is at choices[0].message.content. The reply also carries a reasoning field, the model's scratchpad. Ignore it.
4. Press Send the same request again. Same address, action, key and package. Different words. Compare that with Aarav's service in step 4.

Your key stays in this tab's memory. It is not saved and is gone when you reload. Free tier: 30 requests a minute, counted per Groq account, so use your own account, not a friend's key.

• Checkpoint: a 200 from Groq, two different answers, and one line on which I would trustPractice set item 3.

09Find your key, and where it should live

1. With DevTools open on Network, press Send in step 8.
2. Click the completions row, then Request Headers. Your Groq key is there in plain text.
3. Think it through. This page is your private tool, so that is fine here. If Aarav's product worked like this, every visitor could open DevTools, read his key, and spend his money. So where should the key live?

The UI calls your backend. Only the backend calls Groq, with the key kept on the server. The backend is also where data can be kept, which step 5 showed the page and Aarav's machine cannot do. Building that backend is the next lesson, Building APIs and the backend. More in Keys.

When you are done practising, you can delete the key at console.groq.com/keys and create a new one for the next lesson.

• Checkpoint: I found my key in DevTools and can say which box it belongs inPractice set item 4: one sentence. Never a screenshot of a key.

10Design your API

You have sent every kind of request. Now design the ones your own app needs. Here is Aarav's, as the example:

Your version, with a blank template and what to produce, is in the practice set.

• Checkpoint: practice set doneFinish it before you start the next lesson.

Next: the practice set.Stuck? Troubleshooting · Curious why each part exists? The Wire, optional