API Tests from Real Traffic: 4 Tools Compared

If you want API tests built from traffic your service already serves, the four names that come up are Keploy, Speedscale, WireMock and Hoverfly, and they are not interchangeable. Keploy records a running service in the background and replays what it recorded back as tests. WireMock records through a proxy and then serves the captured stubs back in playback, which answers your code as the dependency instead of testing your code. Hoverfly documents that same capture step as a mode of its own. A HAR file is a fifth path and the narrowest one: a converter reads the browser session and writes a script from it. Search results will not settle the choice for you: Google’s AI Overview answers with Keploy alone, while ChatGPT answers the same question with WireMock.

What “tests from real traffic” actually means

Two different jobs hide under one phrase.

The first is capture from a running service. A recorder sits beside or inside the process, watches requests arrive and outward calls leave, and writes both sides down. Replaying that recording pushes the same requests at a new build and compares what comes back.

The second is conversion of an exported browser session. A HAR file is what the browser’s network panel saved, and a converter turns it into a script. Grafana’s k6 documents that path: the har-to-k6 converter is a NodeJS tool that reads a HAR file, a browser session, and writes a k6 script.

Between the two sits fidelity, and fidelity is a range, not a yes or no. The one long-form treatment of the category in the source set grades replay tools by level, and its level one is exact byte-for-byte reproduction. A byte-for-byte replay goes stale the moment a token expires, which is the practical reason to ask any tool how far past level one it goes, and the reason a recording of yesterday’s traffic is not automatically a test suite.

Search results do not sort this out either. The AI Overview for the head term answers with a single vendor and cites that vendor’s own homepage.

The criteria, and what this comparison can and cannot show

Every tool below is read against the same six questions:

1. Where it sits. Beside the process, in the network path as a proxy, or outside everything as a converter.
2. What it installs. An agent, a binary, a library, or nothing at all.
3. What it captures. The request and the response only, or also the calls the service makes outward.
4. How it replays. Driving requests at your service, or answering requests as a stand-in for someone else’s.
5. What happens to secrets. Whether scrubbing the recording is part of the tool or a step you build yourself.
6. What happens after the API changes. Whether a recording survives a new field, a renamed route or a rotated token.

One limit belongs up front. No run of these four tools sits behind this page. There is no measured setup time here and no measured replay fidelity. What follows is read from each tool’s own public documentation, the pages the search engines cite, and two captured assistant answers to the same buyer question.

mitmproxy, VCR and goreplay belong to the same conversation and are left out of the scoring for one reason: nothing read for this page covers them closely enough to score them fairly beside the other four.

Keploy

Keploy is the name both Google’s AI Overview and Claude put first. The AI Overview calls it the best tool for automatically generating API tests and dependency mocks from real application traffic. Claude’s answer describes it as open source and eBPF-based, recording live requests and responses in the background of a running service and replaying them as tests.

Where it sits and what it installs. Beside the running process, through an agent. Whether that costs a code change is the first thing Keploy’s homepage FAQ takes on, which is a fair signal of what people ask before they try it.

What it captures. More than a list of requests. The same answer has it auto-generating test cases and data mocks together, both from the recorded traffic, which is what lets a replay stand up stand-ins for what the request called. Keploy’s own documentation puts it as recording real API interactions and their dependencies and replaying them deterministically in local or CI. The docs list automatic dependency mocking as a feature in its own right.

Who it suits. A team with a running service they can attach an agent to, who want regression coverage they did not write by hand.

The caveat. Keploy’s homepage is the top organic result and the AI Overview’s first citation for this question, and that homepage argues the comparison against Postman and traditional mocking tools itself. Reading the leader through its own FAQ is how this whole category currently gets described.

Speedscale

Speedscale sells traffic replay and also publishes the document the rest of the category reads. Its definitive guide to traffic replay is the only long-form comparison of replay tools in the source set, and it carries a section headed “Comparing traffic replay tools”. Worth reading, and worth reading carefully: the house doing the comparing is one of the houses being compared. Two of its sections do work a neutral benchmark would otherwise have to invent: one grades replay by level, with level one as exact byte-for-byte reproduction, and another gives scrubbing a heading of its own, sanitising production data for safe replay. Both criteria are used on this page, and both arrived from a vendor.

Where it sits and what it installs. In the workload’s own traffic path. The capture documentation says to use the eBPF collector in Kubernetes to capture traffic without adding a proxy to each workload, and keeps the proxy sidecar available for existing deployments and workloads that do not meet the eBPF requirements. The install is a wizard that walks you through installing the Speedscale Kubernetes Operator, and the CLI is required if you are running on a local desktop or in Docker Desktop. There is a second shape for a developer with no cluster: proxymock runs entirely on your machine and creates tests and mocks by recording inbound and outbound requests while the app runs.

What it captures. Traffic flowing through the application, inbound as well as outbound. What a replay is handed is a snapshot, described as a point in time set of captured traffic containing all the inbound and outbound traffic to and from a service. The recording is not limited to HTTP either; the proxymock documentation names Postgres, gRPC, AWS services and GCP services among the protocols it records and plays back.

How it replays. At your service, which puts Speedscale on Keploy’s side of the split, opposite WireMock. A generator sends the inbound traffic at your application, while a responder replays the outbound traffic responses observed during capture. Those third-party responses are presented to your application as they were received, and the stated purpose is validating that changes to your application work as expected against your production environment.

Who it suits. A team whose service runs in Kubernetes and wants a candidate build checked against recorded production behaviour before release, and, through proxymock, a developer who wants the same loop on one machine.

WireMock

WireMock is what ChatGPT reaches for when the question is a general-purpose, widely used tool for recording live API traffic and replaying it as tests. Its own documentation page for the feature is titled Record and Playback.

Where it sits and what it installs. In the network path, first as a proxy that records, then as a server that answers.

How it replays, and why that matters. Here is the structural split in the category. ChatGPT’s description has WireMock recording through a proxy and then serving the captured stubs back in playback. Playback answers your code’s outbound calls with what the real dependency said. It does not push traffic at your API and check the response, which is what a regression replay does. Both are useful, and they test different things.

How the recorder is driven. Three ways, per the same answer: a UI, a REST API, or a Java DSL.

Who it suits. A team that wants its dependencies pinned to recorded behaviour so its own tests run without them. A team hunting for a generated regression suite against its own service is looking at a different shape of tool.

Hoverfly

Hoverfly is the clearest way to see how this half of the family is built, because capture is not the whole product. It is one mode. The documentation page ChatGPT cites is titled Capture mode and sits among the tool’s key concepts beside its other modes. Record first, simulate after.

Where it sits and what it installs. In the network path, and the tool is the proxy. A proxy server passes requests between a client and server, and by default Hoverfly starts as a proxy server. In Capture mode it runs as that proxy server and intercepts communication between the client application and the external service.

What it captures. Its own page says capture mode is used for creating API simulations, and that Hoverfly transparently records outgoing requests from the client and the incoming responses from the service API. That is the dependency side of the conversation, which is a different recording from one taken beside the service under test.

How it replays. In Simulate mode Hoverfly uses its simulation data in order to simulate external APIs, responding itself each time it receives a request instead of forwarding it on to the real API, and no network traffic will ever reach the real external API.

What happens when one call has to answer differently the second time. This is the part a flat recording cannot do, and it is the strongest reason to look at Hoverfly instead of a plain stub file. Hoverfly holds a map of keys and values which it uses to store its internal state, and request matchers can be made to match only when it is in a certain state, or set to mutate that state. Built on top of that, a sequence recreates a series of different responses that may come back given a single request: Hoverfly keeps track of the caller’s position in the sequence and moves them forwards, and once it reaches the end it continues to return the final response.

Who it suits. A team that wants the record step and the simulate step in one tool with a switch between them, and that needs a stand-in dependency to answer a repeated call differently the second time.

What the source set still does not cover. Hoverfly’s scrubbing features, and whether a captured simulation keeps working once the real API it stands in for changes. Neither question is answered on the pages read here, so neither is scored.

The four side by side

Five of the six questions fit a grid; the sixth is discussed under it. Every cell below is read from the tool’s own documentation or from a captured assistant answer, and a cell is left blank only where those pages say nothing.

Tool	Where it sits	What it installs	What it captures	Replays as	Suits
Keploy	Beside the running service, recording in the background	Not stated on the documentation pages read here	Real API interactions and their dependencies	A deterministic replay, run locally or in CI	Teams with a running service they can record
Speedscale	In the workload’s traffic path: an eBPF collector in Kubernetes, proxy sidecar as the fallback	A Kubernetes Operator via the install wizard, plus the CLI for local and Docker Desktop use	Inbound and outbound traffic, kept as a point in time snapshot	A generator driving inbound traffic while a responder answers the outbound calls	Teams validating a change against recorded production behaviour
WireMock	In the network path, as proxy-based recording	The WireMock server, recording through its proxying feature	Stub mappings, created only at the point the recording is stopped	A stub server answering your code	Teams pinning dependencies for their own tests
Hoverfly	In the network path, between the client application and the external service	Hoverfly itself, which starts as a proxy server by default	Outgoing requests from the client and incoming responses from the service API	Simulate mode, answering as the external API so no traffic reaches it	Teams needing a stand-in dependency that answers a repeated call in sequence

One split runs down the grid and it decides most shortlists on its own. The WireMock and Hoverfly rows describe tools that record a dependency and answer as it; the Keploy and Speedscale rows describe tools that record a service and replay at it. Read the Replays as column first, because a tool from the wrong half of that split will do the job you have badly no matter how good the rest of its row looks.

One cell is blank: the Keploy documentation page read for this comparison does not say what its capture installs, and the assistant answer that calls the capture eBPF-based is not the vendor saying so. The sixth question has no column at all, and that absence is itself a finding. Nothing on the four vendors’ own pages says what happens to a recording after the API changes, and nothing on them says whether scrubbing happens at capture or afterwards on a file already written to disk. Those are the two questions to put to a vendor directly, because searching does not answer them.

Converting a HAR file into API tests, and what the conversion loses

The third path skips the running service altogether. Export a HAR from the browser’s network panel, run it through a converter, get a script.

One converter sits at the top of the search results for this exact question. Grafana’s har-to-k6 is documented as a NodeJS tool that converts a HAR file, a browser session, into a k6 script, and that page holds position one for how to convert a HAR file into API tests. The tool it lands on is a load testing tool, which is a different destination from a regression suite. The question people ask and the answer the web hands back are aimed at slightly different jobs.

What the conversion loses follows from what a HAR is: a record of what the browser saw. Calls between your own services never appear in it, because the browser never made them. The state of a database or a queue at the moment of the request is not in it. Neither is anything behind a call the frontend did not make. A capture tool sitting beside the service works from the live requests and responses themselves and generates its data mocks from them; a HAR has no room for either.

The capture side of that is covered by dev.tools, the open-source API testing tool from the same team, in how to capture and replay a HAR.

The People Also Ask box for this question asks how to convert a HAR file to a JMeter script, which says something about who arrives here: people holding a file and no fixed tool, after the shortest path to something runnable.

Sanitising a recording before it leaves production

A recording of real traffic is not a test fixture yet. It holds whatever the real requests held: bearer tokens, session cookies, customer names, card fragments, internal IDs. That is one real difference between a recorded suite and a hand-written one, and it is the part that stops a recording from being pasted into a repository.

The category’s own reference guide treats scrubbing as a step, not an option. It gives the job a section of its own, headed sanitising production data for safe replay. When a vendor’s own marketing document puts scrubbing before its pipeline story, read that as the floor for anyone doing this work.

The practical question to put to a tool: does the scrubbing happen at capture, before the recording is ever written down, or afterwards, on a file that already sat on a disk with live tokens in it? Nothing in the source set answers that for any of the four.

When a replay is a regression test and when it is a load test

One recording answers two different questions, and the tool has to be told which one it is being asked.

Replayed once, it is a regression test. What matters is whether this build returns what the last build returned: status codes, bodies, the shape of the response. Nothing read for this page benchmarks how well any of the four make that comparison, which is the first thing to ask a vendor to show you.

Replayed many times at once, the same capture becomes a load test. Now the recording is a shape of user behaviour and the interesting output is what breaks first. That is the job the k6 converter aims at: it writes a k6 script, and k6 is a load testing tool.

dev.tools sets out what that second job needs on its own terms in its API load testing guide.

The requirements pull apart. A regression replay needs the response compared; a load replay needs the requests multiplied and timed. A tool built for one does the other badly, which is worth knowing before a single recording is picked as the source of both.

Where Stresseur fits

Plain disclosure: this page is published by Stresseur, which is a tool in this category. It sits at the end, outside the table, on purpose, and nothing above was scored to make it look better.

Stresseur is an AI test engineer for APIs: it learns how an API is actually used, creates the tests every change needs, and keeps them current on every pull request. That learning comes from real usage instead of from a hand-written spec alone, which is the same starting point the four tools above share. Any recorded flow can become a stress test, from one endpoint to ten thousand users, which covers both of the jobs the previous section pulled apart.

Stresseur is in early access: the site offers an early-access sign-up and no self-serve pricing. There are no benchmark numbers here to set against the four above, for the same reason there are none for them.

What to take from this

Three sources answering one question named three different tools, and each had a reason to. The way through is to put the same six questions to every option: where it sits, what it installs, what it captures, how it replays, what it does with secrets, and what happens once the API changes. The answers split these four cleanly. Keploy and Speedscale record a service and replay against it. WireMock and Hoverfly record a dependency and answer as it. A HAR converter does neither and is the quickest route to a load script. Pick by which of those jobs you actually have.