Reverse-Engineering Internal APIs for Workflow Integrations: A Builder's Assessment

If you build automations long enough, you hit the same wall: the system you need to talk to has no public API, no Zapier connector, no n8n node, and no plans to ship one. Logistics portals, government sites, legacy ERPs, and niche SaaS tools all live here. Until recently, the only honest answer was to wait, or to hire a developer to scrape. A third path is now being tested in production: using LLM agents to reverse-engineer a platform's internal HTTP requests and turn them into runnable integration code.

The pattern shows up clearly in Integuru, an open-source agent released in late 2024. The idea is simple in principle. You record a HAR file from your browser while you perform a real action on the target site. You hand the file plus a short prompt to the agent. It walks the request graph, figures out which endpoints depend on which, and emits Python that calls those endpoints in the right order to reproduce your action.

For workflow builders, this changes the economics of the "no API" problem. A connector that used to take a contractor a week can be drafted in a single session. The hard part is no longer the code. It is everything around the code: authentication, breakage, and trust.

What the agent actually produces

Integuru's v0 release focuses on three concrete outputs, and they map closely to what a workflow builder would want from an n8n HTTP Request node or a Make HTTP module:

• A dependency graph of the browser requests needed to perform the target action, so the sequence of calls is explicit rather than guessed.

• Support for input variables, so the same generated code can target different records (a different year, a different account, a different postcode) rather than being hard-coded to one session.

• Runnable code that walks the graph, carrying cookies and tokens forward from one call into the next.

This is not generic web scraping. The output is meant to look like a normal API client, just one that targets endpoints the vendor never documented. The README is explicit that the agent is only viable for platforms where the network traffic from a real browser session is sufficient to reconstruct the action.

Where it works, and where it does not

The technique depends on three things being true about the target platform. First, the meaningful actions have to be visible as XHR or fetch calls in the browser, not stitched together entirely server-side. Second, the authentication has to be carried in cookies or headers you can replay. Third, the platform has to be stable enough that the request shape does not change between the time you record your HAR file and the time your workflow runs.

Several practitioners in the original discussion pointed out the limits:

• Anti-botting layers, JavaScript challenges, and per-session token issuance defeat the approach quickly. If the platform's defence is "you must run this in a real browser to get the right token," a recorded HAR will not reproduce it.

• If the action you want is rendered server-side and returned as full HTML with no separate JSON endpoint, there is nothing for the agent to extract as an API call.

• The moment the vendor ships a redesign, your generated connector stops working. There is no versioned contract, only a snapshot of one session.

That last point is the most important one for automation builders. A reverse-engineered integration is, by construction, undocumented. You do not get changelogs, deprecation notices, or support. You get a workflow that worked on the day you recorded it.

The data-handling question

Several commenters raised a concern that any buyer of this style of tool should take seriously. A HAR file contains every request the browser made during the recording, including any endpoints that touched sensitive endpoints, plus cookies, plus any URLs or bodies that referenced account IDs or tokens. If you hand that file to a hosted service, you are sending a record of your authenticated session to a third party.

For a single user with a single account, the risk is manageable. For an agency that automates client accounts at scale, it is a different conversation. Run the agent locally, audit the generated code before it touches a credential, and treat the resulting integration the way you would treat a custom scraper: as privileged access to a system you do not own.

How this fits alongside official integrations and marketplaces

Reverse-engineered connectors are not a replacement for proper APIs or vetted marketplace templates. They live in the same gap that marketplace connectors, official partners, and custom builds also try to fill, but they occupy a specific corner of it: low-priority internal endpoints inside platforms that have decided not to expose them.

A useful mental model for deciding which approach to use:

OptionBest fitFailure modeOfficial API or partner connectorStable, supported, documented behaviour at any volumeMissing endpoint, rate limits, slow vendor releasesMarketplace template (e.g. via AutoStack)Common patterns across well-known tools, vetted by a creatorTemplate drift after platform updatesReverse-engineered internal APIPlatforms with no public API, low traffic, ad hoc workflowsVendor redesigns, anti-bot defences, session replay riskBrowser-automation tool (Playwright, Puppeteer)JavaScript-heavy UIs that cannot be captured as HTTPSlow, fragile, expensive to run at scale

If you are buying or commissioning an automation and the only way to wire the source system is by recording browser traffic, treat the resulting workflow as a prototype, not infrastructure. Budget for the next breakage, and keep the recording artefact somewhere you can re-run the agent against when the platform inevitably changes.

Practical rules if you build with this approach

1. Record against a dedicated test account, not a production user. The HAR will inherit whatever permissions that account has.

2. Inspect the generated dependency graph before you run it in a workflow. You are looking for calls to endpoints you do not recognise, particularly anything that writes data.

3. Isolate the credentials. Use a short-lived token where the platform supports it, and rotate it on a schedule your usual secrets workflow can enforce.

4. Plan for monitoring. A reverse-engineered connector should be the first thing your alerting covers, because it is the thing most likely to silently break.

5. Document the dependency. Anyone inheriting the workflow needs to know that the connector is unofficial and that a platform change will require re-recording.

The wider point is that the integration landscape is splitting into two layers. Public APIs and vetted marketplace templates cover the systems that want to be integrated. A growing class of LLM-assisted tools covers the systems that do not, by reconstructing the contract from observed behaviour. Both have a place. Confusing them, or assuming a reverse-engineered connector behaves like an official one, is how automation programmes quietly accumulate risk.

For most agency and operations teams, the right starting question is still: is there an official connector, a partner integration, or a marketplace template that does this already? Only when the answer is no across all three does reverse-engineering move from a curiosity to a reasonable option, and even then it should ship behind the same review process you would apply to any other piece of infrastructure.