From the DevTools Network Tab to an API Test Suite

If you build for the web, you’ve probably done this a hundred times. Something’s acting weird, so you pop open DevTools, click over to the Network tab, filter down to Fetch/XHR, and watch the requests roll in. Find the one that looks off, right-click it, Copy as cURL, paste it into a terminal, and start poking at it.

It’s one of the most useful little habits in web development. It’s also, if you think about it, the first step of writing an API test. You’ve got a real request, captured from real usage, that you can run again whenever you want. The only problem is that it usually ends up in a terminal history or a Slack message, never to be seen again. So what would it look like to take that habit seriously and turn it into an actual API test suite?

Why the Network tab is secretly a test generator

Think about what’s sitting in that Network tab after you click through a feature. Every request your frontend sent. The exact URLs, headers and payloads. Every response the backend sent back, status codes and bodies included. In the right order, too.

That’s basically everything an API test needs. Real inputs. Real expected outputs. Real sequence. Nobody had to sit down and guess what payload the checkout endpoint expects, because the frontend already sent it.

Compare that to writing API tests from scratch, where someone reads the docs, guesses at the request shape, and hopes it matches what the UI actually does. The Network tab skips all that guesswork.

Where copying single requests stops scaling

Copy as cURL is great for one request. It gets painful fast after that.

For one thing, auth. That cURL command has a session cookie or a bearer token baked right into it, and those expire. Run it tomorrow and you’ll probably get a 401. Then there’s sequence. A lot of real flows are chains. Create a cart, add an item, check out, each step using an ID from the step before. Copy them one at a time and you lose the thread connecting them.

And there’s no notion of “correct.” A cURL command just fires a request. It doesn’t know what response is supposed to come back, so it can’t tell you when something’s broken. You’re the assertion, squinting at JSON in a terminal.

Capturing whole flows instead of single requests

The upgrade is to stop copying requests one by one and start capturing entire user flows.

DevTools can take you part of the way. Turn on “Preserve log” so requests don’t vanish when the page navigates, click through the flow, then export everything as a HAR file. A HAR is just a JSON log of every request and response in the session. Recent versions of Chrome even offer a sanitized export that leaves out sensitive stuff like cookies, which is a nice safety net if you plan to share the file.

That gets you raw material. Turning it into tests is still manual work, though. Someone has to pull out the relevant calls, untangle the auth, stitch the sequence back together and add checks.

This is where dedicated recorders earn their keep. Instead of exporting and hand-converting, they let you record API calls from your browser and turn them into tests more or less directly. You click through your app like a normal user, the recorder captures each XHR and fetch call along with its headers, cookies and auth context, and the captured flow comes out the other side as runnable tests, often with assertions already in place. Same habit you already have, just without the copy-paste.

Turning captures into a real API test suite

Whichever way you capture, a few things separate a pile of recorded requests from a test suite you’d actually trust.

Filter down to what matters

A raw capture includes way more than your API. Analytics pings, fonts, third-party widgets, that one chat bubble script. Filter by your API’s domain or path before anything else. If you can set a URL filter while recording, even better, since the junk never gets captured in the first place.

Keep complete request and response pairs

Every test needs both halves: what was sent and what came back. Background requests sometimes get captured with a missing body or status, especially when the page navigates away mid-request. Toss incomplete pairs, or repair them, before they turn into confusing tests.

Sort out auth for replay

Captured tokens won’t live forever. The usual fix is having the suite log in fresh at the start of each run, then reuse that session for every test. That way recordings stay valid long after the original session expired.

Add assertions that won’t break for no reason

Comparing the entire response body sounds thorough, but timestamps and IDs change every run. Focus on the status code, the overall shape of the response and the handful of fields that actually matter, like an order total or a user’s role.

Keep each flow in one piece

If a flow depends on order, keep it together as a single test. A checkout broken into separate, unrelated requests will just fail in confusing ways.

Running it on every change

Once the suite exists, put it where it’ll actually get used. Running it in CI on every pull request means backend changes get checked against real user flows before they merge. And because these tests skip the browser entirely, they’re fast. A flow that takes a minute to click through can replay in a second or two.

Keeping it fresh is pleasantly low effort. When a feature changes, record that flow again and replace the old captures. Review the diff in a pull request, and any new field or changed status code jumps right out.

Conclusion

The way I see it, the DevTools Network tab has been a test generator hiding in plain sight this whole time. Every developer already uses it to grab real requests. The only leap is treating those captures as something worth keeping, then capturing whole flows instead of single calls and turning them into a suite that runs on its own.

Want to try it? Pick one flow you test by hand all the time, maybe login or checkout. Capture it once from your browser, turn it into a test with a couple of sensible assertions, and run it next to your normal suite. The next time that flow breaks, you’ll hear about it from CI instead of from a frustrated user.