When a legacy system has no API
a browser agent does the clicking, carefully
Some systems, an old supplier portal, a government site, a cloud tool a provider locked you out of, simply have no API to integrate with. We build a browser agent that uses the interface itself, the way a person would, with the same guardrails we apply to any agent touching a real system.
What a browser agent actually does
Browser automation means controlling a real web interface the way a person would: clicking buttons, filling forms, reading rendered pages. We use it because the system offers no API to integrate with properly. It is the fallback option, not the default. A well-built automation respects the same system a human user interacts with, running on a schedule or a trigger, with logging and safeguards around every action.
When you actually need this
You need this when a system genuinely has no API and no reliable export. Think of an old supplier’s order portal, or a government service that only offers a web form. Or a SaaS tool a provider locked you out of, your data still trapped inside. It also fits recovering access after you lose administrative control of an account: reading what is there through the interface, because there is no other way in anymore.
You do not need browser automation if an API exists, even an undocumented or awkward one. A direct API integration is almost always more reliable and cheaper to maintain than driving a browser. Before you ask us for this, check for an API. If you already have, and confirmed there genuinely is not one, browser automation is the right tool.
How we build it
We build selectors to survive minor layout shifts, matching on stable attributes rather than brittle screen coordinates that break the moment a page’s CSS changes. Every action the agent takes gets logged. A failure captures a screenshot automatically, so debugging a broken run does not mean reproducing it blind.
The agent checks each page against what it expects: a missing element, unexpected text. If something is off, it stops rather than guessing its way forward on a real system. A kill switch stops the agent immediately if anything looks wrong. For actions that are costly or hard to undo, like submitting a form that commits to something, we add a human confirmation step first. It is the same approval discipline we build into any AI agent runtime.
Credentials go through secure storage, never hardcoded into the script. We used this same approach to rebuild a factory’s ERP access through browser automation, reading data out through the only interface still available. It also powers the OCR and browser-driven work behind our visa service bots.
Where this gets fragile
Browser automation is inherently more fragile than an API integration. It depends on a page’s structure staying roughly the same, and a legacy system’s owner can change that structure with no notice and no changelog. We build explicit failure detection so the agent never silently misbehaves on a changed page. Some maintenance after a real redesign is expected, not a sign of a bad build.
The other real question is whether automating this interface is actually allowed. Some platforms’ terms explicitly prohibit automated access, and we check that before building, not after. Budget for occasional maintenance when the target system changes, as an expected cost, not a one-time build that runs forever untouched.
Where the legacy system has a maintenance window or a known slow period, we schedule the agent’s runs around it on purpose. Running an automation at the same time administrators do manual maintenance is a common and avoidable way for changes to collide.
Price and timeline
| Scope | Price | Timeline |
|---|---|---|
| Single recurring task | from $1,500 | 2 to 3 weeks |
| Multiple related tasks, same system | from $4,000 | 4 to 5 weeks |
Related
Built as part of AI agents and automation of everything digital. Often paired with document OCR pipeline when the legacy system’s output is a scanned document, and follows the same approval discipline as an AI agent runtime. See it in a factory’s ERP recovery and running inside visa center AI support bots. Tell us which system has no API left to work with: get in touch.
FAQ
How much does browser automation for a legacy system cost?
A single recurring task, a form submission or a data pull from one portal, starts at $1,500. A fuller automation covering several related tasks on the same system runs $3,000 to $7,000.
How long does it take?
2 to 5 weeks. Building the automation is often the fast part. Making it hold up against the small layout changes a legacy interface always has takes real testing against the live system.
What happens when the legacy system's interface changes?
The agent checks the page against what it expects. If it does not match, the agent stops and alerts a person instead of guessing. We build selectors to survive minor changes, but a real redesign still needs a maintenance pass.
Is this the same as RPA?
The goal is similar: automating a manual interface task. But we build a controlled, logged agent with explicit error handling and a kill switch. A brittle macro recording breaks the first time anything on the page shifts, this does not.
Is this safe to run on a critical system?
That is the design goal: full action logging, a kill switch, and a habit of stopping rather than guessing when something looks wrong. For anything touching money or an irreversible action, we add a human confirmation step before the agent proceeds.