Advanced
Under the hood
In the basics, you learned what an API is, how to call one, and what the data looks like. But real-world API work is messier. Servers are slow. Requests fail. Responses change. Debugging is iterative. These nine labs expose the parts of API work that tutorials skip: performance, failure, reliability, and investigation. Each one uses the same APIs you already know, but pushes them into uncomfortable territory.
The Latency Race
Fire all four APIs at the same time. Watch them race. See who wins and why.
The problem
Every API call takes time. How much time depends on where the server is, how much data it returns, how busy it is, and whether you have already connected to it. When you call one API, you wait. When you call four, you can see the difference. Latency is invisible until you measure it. This lab makes it visible.
What you will see
- Your local API (localhost) is always the fastest because there is no network travel.
- External APIs vary by geography: Mexico City, St. Louis, Washington DC all have different round-trip times.
- Response size matters: a 124-byte mortality response arrives faster than a 10KB exchange rate dataset.
- Run multiple races and watch the distribution: latency is not fixed, it fluctuates every time.
Break It On Purpose
Trigger every HTTP error intentionally. Understand what went wrong, why, and how to handle it.
The problem
Tutorials only show the happy path: send a request, get a 200 OK, parse the JSON. But in production, things break constantly. Servers go down. Rate limits kick in. Authentication expires. Your URL has a typo. If you have never seen a 429 or a CORS error before, the first time it happens in production you will waste hours. This lab lets you cause every error on purpose, in a safe environment, so you recognize them instantly when they happen for real.
What you will learn
- 4xx errors are your fault (bad request, wrong URL, missing auth). 5xx errors are the server's fault.
- CORS is not an HTTP status code. It is a browser security mechanism that blocks responses without proper headers.
- Rate limiting (429) protects servers from being overwhelmed. The Retry-After header tells you when to try again.
- Timeouts happen when the server is too slow. Always set a client-side timeout and handle the AbortError.
Time-Travel Debugger
Every API call you made, recorded. Inspect, compare, replay, and fork.
The problem
Real API debugging is never one request. You send a call, something looks wrong, you change a parameter, send again, compare the two responses, realize the difference, adjust, repeat. This iterative loop is the core skill of API work, but no tutorial teaches it. This debugger records every call you make across the page and lets you inspect, compare side-by-side, and see exactly what changed between two responses.
How to use it
- Every API call from the race and playground is automatically recorded here.
- Click any dot to inspect the full request URL and response body.
- Click a second dot to open a side-by-side diff showing every difference between the two responses.
- Use this to understand how changing one parameter (like age=45 vs age=65) changes the entire response structure.
Make API calls in the playground or race to see them here.
API Heartbeat Monitor
Watch the real-time health of all four APIs. When one goes down, that becomes the lesson.
The problem
Tutorials assume APIs are always available. They are not. Servers have outages, maintenance windows, and capacity limits. If you have never seen an API go down, you will not know how to handle it in your code. This monitor pings all four APIs continuously so you can see uptime, latency trends, and what a real outage looks like.
What you will see
- Green means healthy (responding under 1 second). Yellow means slow. Red means down.
- The sparkline shows latency over the last 30 pings. Spikes reveal instability.
- Your local API should always be green. External APIs may occasionally turn yellow or red.
- This is why production systems need retries, circuit breakers, and fallback data.
Reverse Engineer Mode
See the output. Figure out the input. Debug backwards.
The problem
In real work, you often start with the data, not the documentation. A colleague sends you a JSON response and asks: where did this come from? Which API? Which parameters? This lab inverts the learning direction: we show you a response, you figure out which API call produced it.
What you will learn
- How to identify which API produced a response by looking at its field names and data structure.
- How to read a JSON response and guess the parameters that were used (e.g., if age is 70, the param was probably age=70).
- How to narrow down the source: FRED returns "observations" with "date" and "value". Banxico returns "bmx.series" with "fecha" and "dato". World Bank returns arrays with "country" and "indicator".
- The debugging mindset: form a hypothesis, test it, compare the result, adjust, repeat.
How it works: a quick example
Suppose you see this response: {"age": 70, "qx": 0.03498, "lx": 72039, "ex": 12.1}. The clues: it has "age", "qx" (mortality rate), and "lx" (survivors). That structure matches the custom mortality API. So you try: /api/mortality?age=70. If the response matches, you solved it. Look for field names, data types, and value ranges to identify the source.
Packet Anatomy X-Ray
Peel back the layers of an HTTP response. See what JSON rides on top of.
The problem
When you call an API, you see JSON data. But that JSON did not just appear. It was packaged inside something called an HTTP response, which is like an envelope that carries extra information alongside the data. That envelope traveled across the internet using rules called protocols. This lab shows you every layer of that envelope, one at a time.
What you will see
- Layer 1 (Status Line): Shows the method used (GET), the URL called, and whether it succeeded (200 OK).
- Layer 2 (Headers): The metadata envelope. Content-Type tells you the data is JSON. Cache-Control tells you how long to keep it.
- Layer 3 (Raw Body): The actual text that arrived over the network, before your code processes it.
- Layer 4 (Parsed JSON): The structured data object you work with. This is what JSON.parse() produces from the raw body.
Key terms (you will see these inside)
HTTP (HyperText Transfer Protocol): The set of rules that web browsers and servers use to talk to each other. Every API call is an HTTP conversation.
Headers: Metadata attached to every response. They tell you things like: what format is the data in? (Content-Type), can the browser cache it? (Cache-Control), is this server allowing requests from my website? (Access-Control / CORS).
Status Code: A number the server sends back to tell you what happened. 200 means success. 404 means not found. 500 means the server broke.
Response Body: The actual data you asked for. Usually JSON. This is the part you parse and use in your code.
Make an API call, then click X-Ray to see inside
Data Mashup Builder
Chain two APIs together. Join the data. See the combined result.
The problem
Real analysis almost never uses a single data source. You combine interest rates with exchange rates, or mortality data with economic indicators. But each API returns data in a different format, with different date conventions, different field names. Learning to fetch from multiple sources, normalize the data, and join it is the bridge between calling an API and doing actual analytical work.
What you will learn
- How to fire multiple API calls in parallel with Promise.all.
- How to normalize different date formats (DD/MM/YYYY vs YYYY-MM-DD) into a common key.
- How to join two datasets on a shared column (like year or date).
- Why data cleaning takes more time than the API call itself.
How does US monetary policy correlate with the peso exchange rate?
What Would Happen If...
Adjust a variable. See the counterfactual. Reason about the data.
The problem
APIs give you facts. But analysis is about questions. What if inflation were 2% higher? What if mortality dropped by half? What if the exchange rate had stayed flat? The ability to overlay a hypothetical scenario on real data is what separates data retrieval from data analysis. This sandbox lets you manipulate the numbers and see the impact instantly.
What you will learn
- How to transform API data client-side: scaling, offsetting, and projecting.
- How small parameter changes can produce large differences in outcomes.
- Why scenario analysis matters for risk management, pricing, and forecasting.
- The difference between fetching data and reasoning about data.
What if life expectancy were higher or lower?
Contract Negotiation
Design an API from scratch. Define the inputs, outputs, and rules. Then test it live.
The problem
Consuming APIs is one skill. Designing them is another. When you define an endpoint, you decide: what method? What URL structure? Which parameters are required? What does the response look like? What errors are possible? These design decisions determine whether an API is intuitive or frustrating. This simulator lets you make those decisions and immediately test the result.
What you will learn
- How to choose between GET and POST based on what the endpoint does.
- How to name parameters clearly and decide which are required vs optional.
- How to define a response schema that is consistent and predictable.
- Why good API design is about the consumer's experience, not the server's convenience.
Use {{param_name}} to echo parameters in the response.