Teach networking and APIs in depth with Traceptor (an instructor's guide)

Networking is one of the hardest subjects to teach well. The wire is invisible, the layered abstractions are slippery, and most textbook diagrams are static where the real thing is alive. Students often leave a semester of Computer Networksable to recite OSI but unable to explain what their own browser just did when they refreshed Wikipedia. Traceptor is built to close that gap — and we offer free Premium licenses to verified university instructors teaching network or API courses.

This is a hands-on guide to running a semester (or a self-contained unit) using Traceptor as the lab tool. It assumes a small Mac-equipped lab or BYOD studio; everything below works the same way on Apple Silicon laptops students bring to class. By the end of the semester your students will have captured, decoded, modified, and stress-tested real production traffic from the apps they actually use.

Why a proxy debugger beats a textbook

Most networking courses lean on three tools: tcpdump / Wireshark for packet-level capture, curl for sending crafted requests, and a browser's devtoolsfor the application layer. All three are excellent. They're also fragmented, opaque under TLS, and stuck inside the browser tab respectively.

Traceptor lives at a layer most students never get to touch in a classroom: HTTP and HTTPS, fully decrypted, system-wide. It sits between every app on the machine and the network, presents a locally-trusted certificate so TLS becomes readable, and surfaces the headers / bodies / timings / TLS metadata in a single workspace. For a student trying to see what an iOS app is doing, or what their own React frontend sends when they click Submit, that layer is exactly the right altitude.

Image coming soon

What students get to see (that they usually don't)

• Real HTTPS bodies.Most networking courses skip past TLS because it's a black box. With a per-install CA in the keychain, students see exactly what Slack, Spotify, and their own apps send and receive.
• The full lifecycle.Request line, request headers, request body, response headers, response body, TLS handshake, timing waterfall — rendered as connected fields, not seven different tools.
• Mobile traffic, no rooting. Students point their iPhone at the Mac proxy with a PAC URL pasted from a setup portal. Now they see what an app does, not just what the web view does.
• Modification without code changes. Map Local rewrites a response. Scripting (JavaScript) rewrites both directions. Breakpoints pause a request mid-flight so a student can edit it before it ships. The traffic continues; the student feels powerful.

An 8-module syllabus you can drop into a semester

Each module is one to two lab sessions, designed to fit a standard 14-week semester with room for a final project. Pace can shrink for a 6-week intensive or stretch for a longer course.

Module 1 — HTTP from first principles

Open Traceptor on a fresh capture, browse a few sites, point at one row. Walk through the request line, headers, methods, status code, the difference between query string and body, and the role of Content-Type. Make the abstract concrete: every textbook diagram becomes a real row in the timeline.

• Lab: capture a single GET to a JSON API, identify three headers students have never seen before, and explain each in one sentence.
• Discussion: why does Accept-Encoding mostly contain gzip, br? What would change if a server ignored it?

Module 2 — TLS and the trust model

Use Traceptor's certificate install flow as the teaching surface for TLS. Show what an HTTPS request looks like without Traceptor (encrypted bytes in tcpdump) and with (decoded headers in Traceptor). Then unpack the trick: a per-install root CA, the keychain trust step, and why the same trick is dangerous on a shared machine.

• Lab: students export the Traceptor CA, inspect it with openssl x509 -text, and identify the basic constraints + key usage bits that make it a signing authority.
• Discussion: why does SSL pinning exist? What threat does it defend against, and why does the Traceptor MITM technique not threaten apps on the public internet?

Module 3 — REST API design, observed in the wild

Instead of starting with theoretical REST principles, have students capture 20 minutes of their own app usage and reverse-engineer the API. What resources does the server expose? Which endpoints take pagination? What status codes does it actually use? They'll discover that real APIs are messier than textbook REST — and why.

• Lab: capture all traffic from a single mobile app for ten minutes (over Wi-Fi proxy) and produce a one-page diagram of the API surface.
• Discussion: where does this API obey REST conventions, and where doesn't it? Which deviations seem deliberate, and which look like legacy?

Module 4 — Request rewriting and the “what if” lab

This is where students go from observers to participants. Introduce Tools ▸ Map Local for static response swapping, then Tools ▸ Scriptingfor dynamic rewriting. Hand them a working web app and ask them to break it — not by attacking the server, but by feeding the client unexpected but valid-looking responses.

js// Example for the lab: change every numeric "price" field in a /products
// response to a string, and watch which front-ends crash gracefully and
// which crash spectacularly.
async function onResponse(context) {
  const { request, response } = context;
  if (!request.url.includes("/products")) return context;

  const body = JSON.parse(response.body);
  body.items = body.items.map((p) => ({ ...p, price: String(p.price) }));
  response.body = JSON.stringify(body);
  return context;
}

• Lab: using Map Local + a JSON fixture, force the demo app into three states the live API never produces (empty list, single-item list, 500 error).
• Discussion: what does this teach about defensive parsing on the client side?

Module 5 — Mobile networking, the real one

Walk through the Mobile Setup view, the QR code linking to the in-app setup portal, the PAC URL flow, and the iOS Certificate Trust toggle. Once the phones are paired, the lesson writes itself: students discover their favorite apps make dozens of background requests per minute to third parties they've never heard of.

• Lab: spend 30 minutes using a single phone app while routing traffic through Traceptor. Produce a list of every third-party host the app contacted, classified by purpose (analytics, attribution, crash reporting, CDN, etc.).
• Discussion: what does this look like through the lens of GDPR, ATT, or your country's equivalent?

Module 6 — Security at the API layer (OWASP API Top 10)

Open any captured request and click the Security sub-tab. Traceptor runs the OWASP API Top 10 (2023) and OWASP Mobile Top 10 (2024) passively against the request and produces a graded finding list. Walk through the categories: BOLA, broken auth, BOPLA, rate limiting, security misconfiguration, etc.

• Lab: run the Security Scanner against a captured session from a real third-party API. Identify three findings, classify their severity, and propose a fix for each.
• Discussion: the scanner is passive — what kinds of vulnerabilities can it never find, and what would you need to add to detect them?
• Bonus: have students pair Security Scanner findings with the JWT Viewer and Cookie Manager to compose a full security audit of a single session.

Module 7 — Network conditions and resilience

Open Tools ▸ Network Throttleand pick a preset (Wi-Fi, LTE, 4G, 3G, Edge, 2G, “Very Bad Network,” or 100% loss). Apply it globally, then have students perform the same task as in module 3. Reality changes character at 400 ms latency; production code that ignores this is fragile.

• Lab: profile a single-page app under Wi-Fi, LTE, 3G, and Edge. Identify which loading state is missing, which timeout is too aggressive, and which retry policy is broken.
• Discussion: what is the right default timeout for an authenticated API call? Why doesn't a single value work everywhere?

Module 8 — WebSockets and persistent connections

Pair this with the textbook chapter on persistent vs. request/response protocols. Capture a WebSocket connection (most chat apps, collaboration tools, and modern dashboards use one) and walk through the upgrade handshake plus the resulting frame timeline. Show how the same TCP socket carries thousands of frames in both directions.

• Lab: capture a chat application for 5 minutes, identify the ping interval, the close code, and the rough byte budget per message.
• Discussion: when would you choose WebSocket vs. Server-Sent Events vs. polling? What does each tell you about the server's assumptions?

Three project ideas for the final unit

For the back third of the semester — or for a final lab — give students a structured project they can ship a writeup for. Each of these lands well as a 3-4 page report with screenshots.

Project A — “Reverse-engineer an API”

Pick a public app (no authentication wall, no aggressive rate limiting) and produce a one-page OpenAPI sketch of its API based on captured traffic alone. Bonus credit for identifying inconsistencies between similar endpoints.

Project B — “Audit a SaaS”

Run the API Security Scanner against a full session from a SaaS product the student already uses. Produce a writeup of every critical / warning finding, a vendor-disclosure-style recommendation per finding, and a priority order. The discipline of writing this up cleanly is its own lesson.

Project C — “Mock the missing API”

Give students a half-finished frontend whose backend doesn't exist yet. Their job is to design and implement the entire backend contract using Map Local files and Scripting rules so the frontend works end-to-end against Traceptor alone. This teaches API design by forcing students to be on both sides of the wire at once.

Practical notes for setting up a lab

• University Wi-Fi:some campus networks block arbitrary outbound ports and PAC URLs. If the setup portal isn't reachable from a phone on the same SSID, fall back to a local hotspot from one of the Macs.
• Shared Macs: if students share lab machines, have them remove the Traceptor CA from the keychain at the end of each session. The setup is fast to redo and the alternative (a trusted MITM cert living on a shared machine) is a real security hole.
• BYOD classes: Apple Silicon is the smooth path. Older Intel Macs work but you may want to drop one or two of the heavier security tools from the lab plan.
• Demo apps: we recommend having one or two purpose-built demo apps the whole class can target without worrying about rate limits or terms of service. A small Next.js app the TAs maintain is a good fit.

Suggested rubrics

• Capture quality (20%): did the student successfully capture a clean, decoded session for the lab? Bonus for filtering and exporting a focused subset.
• Interpretation (40%): can the student explain what the wire is showing in their own words? Headers identified correctly, status codes understood, timing analyzed.
• Modification (30%): did the student use Map Local, Scripting, or Throttle correctly to produce a deterministic variant of the captured traffic?
• Writeup (10%):can the student communicate the experiment to someone who wasn't in the lab? Screenshots, captions, and clean prose.

Get your classroom license

Email support@traceptor.com from your institutional address with:

• The course name and number
• A syllabus link, if you have one online
• A rough student headcount for the term
• Your institutional email address (the one you're sending from)

Once we verify, support sends a 100% discount code you redeem at the normal checkout to bring the price to $0. We review every request and reserve the right to approve or decline, but real teaching applications — with a real syllabus and a real institution — almost always go through quickly.