From JSON to a web page: how an API's answer becomes what you see

At the end of Part 2, the weather API had answered with JSON: a block of labelled values, such as a temperature of 11.6 and a weather code of 2. That's not what anyone sees on the weather page. They see "12°", "Partly cloudy" and a little sun behind a cloud. This part is about the gap between the two, because it's where a lot of product decisions quietly get made. It's also where you'll hear one of the most common words in any API conversation: parsing.

Three moves

The JSON that comes back is just text. Turning it into the page you see takes three moves, and they're the same on almost any site that uses an API.

The best comparison I know is the departures board at a train station. The board itself (the page) is built once, with a slot for each destination, time and platform. A live feed from the railway (the JSON) supplies the details, and the board's system (the code) drops each one into its slot, turning a code like "DLY" into the word "Delayed" on the way. When something changes, only that slot flips over. The board is never rebuilt, and the weather page works the same way.

Step 1: parsing

To the code, the JSON that arrives is just a long line of characters, no more useful than a sentence. Parsing is the step that reads those characters, works out the structure (which labels go with which values, what's grouped inside what) and hands back data the code can actually use.

A good comparison is goods-in at a warehouse. A delivery note arrives on paper. Someone keys it into the stock system field by field, and the system checks each value is the right kind of thing: a quantity has to be a number, a date has to be a date. Only then can anyone search it, total it or put it on a shelf.

{"current":{"temperature_2m":11.6,"weather_code":2,"is_day":1},"daily":{"time":["2026-11-04","2026-11-05"]}}

Most of the time parsing just works, and nobody mentions it. You'll hear the word when it doesn't:

When a developer says "the response didn't parse", it usually means the API sent back something other than what was agreed: an error page, an empty answer, or JSON with a typo in it. It's worth asking what the customer sees when that happens.

Steps 2 and 3: translate and place

Once the answer is parsed, the code translates each value for people and places it on the page. Here's where each value in the weather answer ends up:

From a number to a picture

Translating is where most of the product decisions hide, and one translation deserves a closer look. The API never sends a picture, or even the words "partly cloudy". It sends a number from a standard list of weather codes, and the page does the rest. Try any of the 28 codes:

This split is the same in most products. The API sends compact, raw data, and the product decides how to present it. It's also why the answer is so small (around a kilobyte here) and so quick to arrive.

One example of that split: Open-Meteo has no code for sleet, so the page treats "freezing rain" and "freezing drizzle" as sleet. That's a presentation decision, made in the product, not in the API.

The code, simplified

You don't need to read code to follow this series, but if you're curious, here are the three moves in a few lines of JavaScript:

const response = await fetch(address);       // ask, and wait for the answer
const data = await response.json();          // 1. parse: text into structured data

const temp = Math.round(data.current.temperature_2m) + "°";   // 2. translate: 11.6 into "12°"
const sky = legend[data.current.weather_code];                // 2. translate: 2 into "Partly cloudy"

document.querySelector("[data-wx-temp]").textContent = temp;  // 3. place: into its spot
document.querySelector("[data-wx-condition]").textContent = sky.label;

fetch is built into every modern browser. [data-wx-temp] is the label on the spot in the page's HTML where the temperature goes, the empty slot on the departures board.

Words you'll hear

These come up whenever a team talks about an API's data. You don't need to use them, but knowing what they mean makes the conversation much easier to follow.

What this means for product managers

• Ask what happens when the answer doesn't parse. An error page instead of JSON, an empty answer, a missing field: decide what the customer sees, and test it.

• Every translation is a decision. Rounding 11.5 up or down, mph or km/h, "Thu" or "Thursday", what counts as sleet: none of it comes from the API. Someone chooses, so make sure it's written down.

• Design the empty states. What does each spot show while it waits, if a value is missing, or if the whole answer fails? Put it in the acceptance criteria, or the team will guess.

• Test with awkward values. Minus temperatures, a 0, a missing field, a very long place name. Real answers will contain all of them eventually.

• Treat the field names as a contract. The page looks for temperature_2m by name. If the provider renames it in a new version, the page shows "--" until someone updates the code, so version changes belong on the roadmap.

Part 4 moves from the data to the small print: API keys, keeping them secret, and the limits and costs that come with them.