Integuru v0: generating integration code from browser network traces

The gap Integuru v0 fills: platforms with no public API

Plenty of services a business depends on expose no documented API, or expose one that omits the action you actually need. The browser still performs that action, which means the requests exist and can be observed. Integuru v0 takes that observation as its input. According to the README, the workflow is: run create_har.py to capture a file of browser network requests plus a cookies file, write a prompt describing the action you triggered in the browser, and let the agent emit runnable Python that hits the platform's internal endpoints.

The intended user is an engineer comfortable with Python, Poetry and browser dev tools, who needs a scheduled or scripted version of something a human currently clicks through. It is not a no-code connector builder, and the README does not present it as one. The repository topics describe it as an agent, an unofficial-API tool and an RPA-adjacent project, which matches the mechanism: it is automation built on a captured session rather than on a contract the vendor agreed to.

How the dependency graph is built from captured requests

The mechanism is described step by step in the README, using a utility-bill download as the worked example. The agent starts from the request that performs the desired action, for instance a URL of the form https://www.example.com/utility-bills?accountId=123&userId=456. It then looks for dynamic parts of that request, here accountId and userId, and searches the capture for the requests that produce them.

Each producing request becomes a dependency, and the agent repeats the search on those requests until it reaches ones that depend on nothing but the authentication cookies. The result is a dependency graph, which the repository builds with networkx. The README states that the agent then traverses the graph from nodes with no outgoing edges up to the master node, converting each node into a runnable function. The traversal order is the point: leaf requests run first, their values feed the parents, and the final call reproduces the original action.

Two constraints are visible in the code layout rather than the prose. The step budget is capped by --max_steps, default 20, so a deep chain of dependent requests can exhaust the budget before the graph is complete. And the README notes that input variables (choosing a YEAR, for example) are currently supported only for graph generation, with input variables for code generation listed as coming soon. If your action needs a parameterised value in the emitted code, that gap is real.

Installing Integuru v0 and running a first capture

Setup assumes Poetry and an OpenAI key. The README instructs you to set the OPENAI_API_KEY environment variable, install dependencies, enter a Poetry shell, and register the virtual environment as a Jupyter kernel so main.ipynb works. Note the interpreter constraint in pyproject.toml: python = ">=3.12,<3.13".

export OPENAI_API_KEY=<your key>
poetry install
poetry shell
poetry run ipython kernel install --user --name=integuru

The next step spawns a browser through Playwright. You log into the target platform by hand and perform the action you want automated, such as downloading a utility bill; the script writes the captured requests and cookies to disk.

poetry run python create_har.py

With network_requests.har and cookies.json in place, you run the agent with a prompt and a model. The README recommends gpt-4o for graph generation because it supports function calling, and says Integuru switches to o1-preview for code generation when that model is available on the account. Add --generate-code when you want the full integration rather than just the graph.

poetry run integuru --prompt "download utility bills" --model gpt-4o --generate-code

The CLI accepts --har-path and --cookie-path if your files are not at the defaults ./network_requests.har and ./cookies.json, and --input_variables key value for graph-time parameters. Unit tests run with poetry run pytest. The README also documents that 2FA sites work the same way as long as you complete the second factor in the browser and capture the resulting cookies and tokens.

Where the generated integration breaks

The output is a snapshot of one session against one version of the site. Nothing in the README describes schema checks, response validation or a repair loop when an endpoint changes shape. If the platform renames a query parameter or moves the bill download behind a new request, the generated functions keep calling the old chain and fail at runtime. There is no documented rollback, no retry policy and no drift detection in the repository.

Authentication is the second failure mode. The README's privacy section states that collected data is stored locally in network_requests.har and cookies.json. Those cookies are session credentials for a real account, sitting in plain files on disk, and they expire. Nothing in the README describes a refresh mechanism, so the practical pattern is re-running create_har.py whenever the session dies. For a platform with strict session binding or frequent re-authentication, that maintenance load can exceed the value of the automation.

Finally, the tool is the wrong fit when a documented API exists. Reverse-engineering an internal endpoint to avoid reading a public API's docs trades a stable contract for a private one, and the README offers no argument for doing so.

Integuru v0 compared with Playwright scripting

The obvious alternative is to keep the browser and script the UI directly with Playwright, which is already a dependency here. That approach drives the same session you captured, so it survives backend changes that do not alter the page, and it needs no LLM calls. Its weakness is the opposite one: DOM selectors and render timing are fragile, and a UI redesign breaks the script even when the underlying endpoints are untouched.

Integuru v0 sits between the two. It produces HTTP-level code, which is faster and less brittle than clicking through a page, but it derives that code from a single capture rather than from documentation. The README frames the project as the earliest public version of the agent and points to www.integuru.com for the current one, so the honest comparison for a new project is against the current product, not against this snapshot. Treat v0 as a way to see the approach and to generate a first draft of the request chain.

Maintenance, licence and what the snapshot costs

The repository is not archived, and the last push was on 2026-06-24. The README describes v0 as the earliest version released publicly and directs readers to integuru.com for the newest version, so the maintenance question is really a question about which codebase you intend to depend on. For v0 itself, the upgrade surface is the dependency set in pyproject.toml: langchain-openai, langchain-core, langgraph, playwright and networkx all move, and the Python pin to 3.12 means an interpreter bump is a deliberate change rather than a routine one. The CI workflow in .github/workflows/ci.yml runs pytest on Python 3.12 for pushes and pull requests to main, which is the only automated check the repository documents.

The licence is AGPL-3.0, per the LICENSE file at the repository root. That is a copyleft licence with a network-use clause, which matters for a tool whose whole purpose is to be embedded in a service that talks to third parties. Whether your deployment triggers the source-availability obligation depends on facts about your product that this article cannot assess; read the licence text and get your own advice. Separately, the README's privacy section states that the tool sends captured data to OpenAI's GPT-4o and o1-preview models and that the LLM is not trained on your usage. Captured cookies and request bodies leaving your machine is a decision to make before pointing it at a production account.

Editorial conclusion

Integuru v0 is for engineers who already have a logged-in browser session against a platform with no usable public API and want a draft of the request chain rather than a finished integration. Skip it if you need the current product, since the README points to integuru.com for that, or if the target site changes its request shape often, because the generated code is a snapshot of one capture. Before adopting it, confirm Python 3.12 is available (pyproject.toml pins >=3.12,<3.13), check that your OpenAI account can call the models named in the README, and read the AGPL-3.0 LICENSE file to decide whether your distribution plan is compatible with it.

Frequently asked questions

Official sources

1. Integuru-AI/Integuru on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README