Reverse API Engineer: generating API clients from captured browser traffic

The problem: turning observed traffic into a maintainable client

Most scraping work starts the same way. You open DevTools, watch the network panel, find the XHR call that returns the data you want, copy it as cURL, paste it into a script, and then spend an afternoon replacing hardcoded headers with variables. The README describes that loop directly: it exists so you stop manually opening DevTools, copying cURL commands, and gluing together a client. The tool's pitch is narrower than a general scraper. It does not parse HTML for you. It watches what the browser already fetched and writes code that calls the same endpoints. The audience is engineers who need a repeatable client rather than a one-off script, and who are comfortable handing the generation step to a language model. The output is a directory, not a snippet: the quick start shows ./scripts/apple_jobs_api/ containing api_client.py, README.md and example_usage.py. That packaging choice matters, because it means the artifact is meant to be committed and imported, not pasted into a notebook.

Capture to HAR, then model-driven code generation

The pipeline has four stages, per the README. You supply a URL and a goal, phrased in natural language, such as fetching all Apple jobs from a careers page. A browser visits the site, either driven by you or by an AI agent. Network traffic is written to a HAR file. Then your configured model reads that traffic and writes a client. The separation between capture and generation is the design decision worth noting, because it makes generation replayable. The engineer mode exists precisely for that: engineer <run_id> re-runs generation against a previous capture. If the model produces a client with a wrong header or a misread query parameter, you do not have to re-browse the site. You re-run the generator on the same HAR. That is a real workflow improvement over tools that fuse capture and generation into one irreversible pass. The output language is a config value, not a flag, and the supported set is python, javascript, typescript, go, java, csharp, php, ruby and c. The README notes that C output needs a POSIX toolchain with cc and libcurl headers, on macOS or Linux, or WSL or MSYS2 on Windows. That is the one target with a build dependency outside the tool itself.

Agent mode, manual mode, and what each one drags in

There are four modes, cycled with Shift+Tab. Manual mode hands you the browser and generates from what you captured. Agent mode has a model drive the capture. Engineer mode regenerates from a stored run. Collector mode has the agent gather structured JSON or CSV using web search plus fetch, which is a different job from reverse engineering an endpoint. The install split follows the modes. Since v0.12.0 the base install is lightweight and Playwright is optional. Agent mode, which the README calls the default, captures through npx-launched browser tooling and needs no extra Python packages. Manual mode needs the extra: uv tool install "reverse-api-engineer[manual]" plus playwright install chromium. So a fresh install gives you agent mode with no Python browser dependency, but it does assume Node is present, because the capture path goes through npx. The chrome-mcp provider drives your real Chrome so existing sessions and cookies carry over, and it requires Chrome 146+ and Node.js 20.19+. That is the provider to pick when the endpoints you want sit behind a login, and it is also the one with the tightest version floor. The agent-browser provider resolves a binary at session start: it uses whatever agent-browser is on PATH, otherwise runs npm install -g with the configured pin, prints a yellow notice, validates with --help, and only falls back to npx -y if npm cannot install. The pin is configurable through agent_browser_npx_package or RAE_AGENT_BROWSER_PACKAGE. The first Chromium fetch needs agent-browser install, with --with-deps on trimmed Linux images. Nothing in that chain is exotic, but it is a chain, and each link can fail independently.

Configuration surface and the model providers you can point it at

Settings live in ~/.reverse-api/config.json and are editable through /settings in the CLI. The documented keys include agent_provider, output_language, output_dir, real_time_sync, sdk, and per-provider model names such as claude_code_model, collector_model, copilot_model and cursor_model. The sdk value selects the backend and accepts claude, opencode, cursor or copilot. This is the part of the project that has grown the most, and it shows. OpenCode support is described in unusual detail: with sdk set to opencode, RAE reuses an existing server or downloads and starts opencode-ai@latest through npx, so a global OpenCode install is not required. Fresh configurations default to the free opencode/big-pickle model. The /settings flow shows a loading spinner, then a searchable provider and model picker populated from the server's connected, tool-capable catalog, and it marks free options. Before creating a session it revalidates the saved pair and suggests currently available free models if the configuration is invalid. Node.js 20+ is required for automatic startup, and password-protected servers use OPENCODE_SERVER_PASSWORD with an optional OPENCODE_SERVER_USERNAME. Ollama runs through OpenCode as a provider choice: RAE starts an installed daemon if needed and lists only installed models that support tool calling and 64k or more context, and the README states models are never downloaded silently. That last constraint is the right call. A tool that quietly pulls a multi-gigabyte model during a CLI session would be worse than one that refuses.

Where it breaks, and when it is the wrong tool

The generation step is only as good as the traffic you captured. If you browse the wrong page, or the site loads its data lazily in a way your session never triggered, the HAR contains nothing useful and the model has nothing to read. Agent mode reduces that risk but does not remove it, because the agent is choosing what to click. There is no documented validation step that checks a generated client against the live endpoint. The README describes the output as a working client, but nothing in the supplied material describes a test harness or a replay check, so you should assume the generated code needs a manual run before you trust it. The dependency chain is the second failure surface. Agent mode needs Node and npx. chrome-mcp needs Chrome 146+ and Node.js 20.19+. OpenCode auto-start needs Node.js 20+. The C output target needs cc and libcurl headers, which on Windows means WSL or MSYS2. If your environment is a locked-down CI container with no Node and no outbound npm access, the default path does not fit, and manual mode with the [manual] extra plus a pre-installed Chromium is the only route. Finally, this is not a tool for sites that render everything server-side and expose no JSON endpoints. If the data only exists in the HTML, there is no API to reverse, and the HAR will be full of document requests the model cannot turn into a client.

How it compares to writing a Playwright script by hand

The obvious alternative is a hand-written Playwright or requests script, or a general scraping framework. The difference is what gets generated. A Playwright script drives a browser every time it runs. Reverse API Engineer uses the browser once, during capture, and then generates a client that calls the underlying HTTP endpoints directly. That is a meaningful distinction for cost and speed, since a client that issues plain HTTP requests avoids launching Chromium on every run. The trade-off is fragility of a different kind. A Playwright script breaks when the DOM changes. A generated HTTP client breaks when the site rotates a token, changes a header, or moves the endpoint. Neither approach is universally better; they fail on different changes. A second alternative is doing the reverse engineering manually and writing the client yourself. That takes longer but produces code you fully understand, which matters when the generated client will live in a repository for years. Reverse API Engineer's engineer mode partly addresses this by letting you regenerate from a stored HAR, but the generated code is still model output, and reviewing it is on you. The tool is a starting point that saves the reconnaissance phase, not a replacement for reading the code before you ship it.

Maintenance cost, licence, and what the release history shows

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it places no copyleft obligation on the clients you generate. This is not legal advice; check the LICENSE file in the repository for the binding text. On maintenance, the release cadence visible in the supplied material is active: v0.12.0 made Playwright optional and cut the base install down, v0.13.0 added a client_executed json-stream event, and v0.13.1 fixed a missing httpx dependency on fresh installs. That last one is instructive. A missing runtime dependency on a clean install is the kind of bug that only surfaces for new users, and its presence in a patch release suggests the install matrix has enough branches (base, manual extra, agent-browser, OpenCode, Ollama) that regressions are plausible. Budget for reading release notes before upgrading, particularly around the agent provider resolution logic, which the README describes in enough conditional detail to imply it has changed more than once. The configuration file lives at ~/.reverse-api/config.json, so upgrades that add keys will leave your existing file in place and the new keys will take defaults.

Adoption checklist before you point it at a real target

Start with a site whose endpoints are public and unauthenticated, and confirm the full loop works end to end on your machine before you involve anything that matters. That means checking that your chosen sdk and model are reachable, since the default is claude and the alternatives each have their own startup path. If you plan to use chrome-mcp, verify your Chrome version meets the 146+ floor and your Node version meets 20.19+ before you debug anything else. If you plan to run agent-browser, run the documented sanity checks first: agent-browser doctor --offline --quick and agent-browser skills list. For C output, confirm cc and libcurl headers are present, because the failure will otherwise appear late in the generation step. Then run generation once, read the produced api_client.py, and run example_usage.py against the live site yourself. The documentation does not describe an automated check for that, so it is your step. Keep the HAR file from the run, since engineer <run_id> lets you regenerate without re-browsing, and that is the cheapest way to iterate when the first client is close but not correct.

Editorial conclusion

Adopt Reverse API Engineer if you already pay for Claude, OpenCode, Cursor or Copilot access, work on macOS or Linux, and can install Node.js 20.19+ because the default agent path drives browser MCP servers through npx. Do not adopt it if you need a fully offline pipeline or a Windows box without WSL or MSYS2 for the C output target. Before committing, verify that your configured model can read the HAR files your target site produces, and check whether the endpoints you need sit behind a login that only chrome-mcp can reach, since that provider requires Chrome 146+.

Official sources

1. License: MIT
2. nottelabs/reverse-api-engineer on GitHub
3. Project website
4. README
5. Releases