Integrating with Legacy Systems That Have No API: A Practical Playbook

Government portals and enterprise legacy systems represent one of the most common unresolved integration problems in modern software. They hold data your product needs. They have web interfaces that work reliably for human users. And they were built before REST APIs existed as a standard, which means the path to programmatic access requires a different approach than adding an API key and reading the docs.

This is not a permissions problem or a procurement delay. It is a technology-era problem, and treating it like something else is why so many teams end up with brittle RPA bots or a growing backlog of manual data entry.

Why legacy systems rarely have public APIs

Most legacy enterprise systems were built between the mid-1980s and early 2000s, before REST API conventions emerged as the standard. IBM WebSphere, Oracle Application Server, and older Microsoft stacks were designed for browser-based human interaction. Their architecture optimized for rendering pages, not for machine-readable responses.

Government systems add a second layer of delay. Public sector procurement cycles run on multi-year timelines, and modernization projects require budget approval, legislative cycles, and often federal contractor involvement. A state licensing database or court docket system built in 2003 may still be running the same application stack in 2026, not because the agency is unaware it is outdated, but because replacing it costs more than maintaining it.

Enterprise iPaaS platforms like Workato and MuleSoft are strong options for connecting modern SaaS tools that expose REST or GraphQL APIs. They rarely cover the long tail of government portals and older on-premise systems that never published an API in the first place.

The three options teams typically try

When engineering teams hit a platform with no public API, they typically evaluate three paths before finding one that works in production.

Official modernization partnerships are the ideal solution and almost never the practical one. Formal API partnership programs require months of application review and enterprise contract minimums, a timeline that rarely fits the window between signing a customer and shipping the integration. For government portals, waiting on an official API can mean waiting years for a budget cycle and a procurement award.

File exports via SFTP or CSV are available on many legacy platforms and genuinely useful for certain workflows. But they are batch-only. You get a snapshot of data at the time of the export, with no ability to run real-time queries, trigger event-driven workflows, or write data back into the system. For any use case that requires current data or outbound actions, file exports are a workaround, not an integration.

Browser automation and RPA appear to solve the problem by interacting with the web interface directly. Tools like UiPath, Automation Anywhere, Selenium, and Puppeteer can technically operate any interface a human can operate. The issue is maintenance, and on legacy systems that maintenance burden is especially acute.

Why RPA is especially fragile on legacy platforms

A government portal redesign triggered by a federal contractor update can break every RPA bot that touches it: overnight, with no versioning and no migration guide.

Modern SaaS platforms follow predictable release cycles and provide changelogs. Legacy systems and government portals do not. A state agency may roll out a visual redesign under a new IT services contract without any advance notice to the organizations whose workflows depend on that interface. The portal looks different on Monday morning. The element selectors your RPA bot relied on no longer exist. The bot fails, silently or loudly, and someone is manually logging in to catch up on data that was supposed to be automatic.

Legacy authentication compounds the problem. Older systems frequently use session-based cookie flows that expire unpredictably, CAPTCHA implementations that block automated traffic, and multi-step login sequences that RPA tools handle inconsistently across environments.

At Integuru, we have seen this pattern repeatedly: a team builds an RPA integration against a legacy platform, it works in staging, ships to production, and requires meaningful engineering time to maintain within the first six months. The compounding cost of that maintenance is what usually brings teams to us.

On legacy Oracle stacks, the failure mode is usually not a crashed bot but a silently degraded one. A session cookie that expires mid-batch leaves the integration returning partial results with no error signal, so the problem surfaces in the data layer rather than the logs. On state agency portals managed by rotating contractors, the specific issue is auth endpoint drift: the login POST target changes path, the form field names get renamed, or a new CSRF token is injected, and nothing in the old RPA script accounts for it because there was no API changelog to follow. The bot keeps running. It just returns nothing, or the wrong thing.

What "no public API" actually means

"No API" almost always means no documented REST API, not that the platform communicates exclusively over HTTP. This distinction matters.

Every web application communicates over HTTP. When you log into a state licensing portal, fill out a search form, and retrieve results, your browser is sending POST requests with form data and receiving server-rendered HTML responses. When you submit a patient record in a legacy EHR system, the browser sends an HTTP request, the server processes it, and returns a response. The application is using HTTP. It just is not using REST conventions, and it has not published documentation for those requests.

Legacy systems typically use one of several patterns:

• Form submissions (POST with application/x-www-form-urlencoded): the standard for server-rendered web apps built before AJAX became common

• Session-based authentication: login establishes a server-side session identified by a cookie, not a bearer token

• XML/SOAP responses: common on enterprise middleware stacks from the 2000s, still present on many healthcare and government platforms

• Server-rendered HTML responses: the platform returns HTML that needs to be parsed for the data your integration needs

None of these patterns are inaccessible. They require a different analysis than reading an OpenAPI spec, but the HTTP layer is available to any process that can handle these request and response formats.

How HTTP-native integration works on legacy platforms

HTTP-native integration works by analyzing the actual network traffic the platform generates rather than automating a browser on top of it. Integuru maps the HTTP request sequences a platform uses (the form POST endpoints, the session initialization flow, the cookie parameters, the response structure) and generates a production-ready API that abstracts those patterns into clean, callable endpoints.

Because the integration layer is built directly on HTTP rather than on browser rendering, it does not break when the platform's visual interface changes. A government portal redesign that moves a button and renames a CSS class would break an RPA bot. It has no effect on an integration built against the underlying HTTP requests that the application was already sending.

This also means the integration can handle write operations cleanly. Submitting a form, updating a record, triggering a workflow: these are all HTTP requests. An HTTP-native integration can replicate them with the same reliability as read operations, something file exports cannot offer.

Authentication flows that are non-standard on legacy platforms (session cookies, multi-step logins, SAML, 2FA) are within scope, because Integuru maps the exact authentication sequence the browser performs and reproduces it programmatically.

How Integuru approaches legacy system integration

At Integuru, we build HTTP-native integrations for platforms across the verticals where legacy systems are most concentrated.

Government portals (including IRS e-file systems, state licensing databases, and court docketing platforms) typically run on older Oracle or IBM application stacks that predate REST. We map the session initialization sequence, the form submission patterns, and the response parsing required to extract structured data. Teams that need to query permit status, retrieve court filings, or submit regulatory reports programmatically get production-ready endpoints without waiting on a government modernization project.

Healthcare EHR systems (many of which were built in the 2000s and are not FHIR-compliant) expose their functionality only through web portals. FHIR covers structured read access for modern, certified EHR deployments, and vendor certification programs take months to approve. For platforms like legacy on-premise EHRs where the web portal is the only access point, Integuru generates endpoints that cover the actions your integration actually needs: retrieving patient records, submitting clinical data, querying appointment availability. Our healthcare EHR integration solutions cover more than a dozen platforms in production.

Logistics TMS platforms (transport management systems that run on older stacks and expose only web interfaces) are a common source of integration debt for logistics and supply chain companies. Carrier portals, load boards, and shipment tracking systems that predate modern API standards are accessible through their HTTP layer.

Legal research platforms: court databases, legal research tools, and case management systems in the legal sector frequently have no public API, only authenticated web interfaces with complex search and retrieval flows.

The principle is consistent across all of these: the platform's web interface already communicates via HTTP. Integuru maps that communication and makes it callable.

• <3 sec average response time per API call

• 99.9%+ reliability rate in production

• 24/7 on-call maintenance on production plans: Integuru handles integration upkeep, not your engineering team

• Edge case coverage: branching logic, multi-state flows, and variant account configurations are mapped automatically

What to look for when evaluating a legacy integration approach

Not every legacy integration problem has the same shape. Before selecting an approach, evaluate these five factors:

1. Authentication model complexity. Does the platform use session cookies, 2FA, SAML, or a proprietary SSO flow? RPA tools handle some of these inconsistently. HTTP-native integration maps the exact auth sequence the platform uses. File exports typically bypass auth complexity but sacrifice real-time access.

2. Response format. A platform returning JSON from a REST endpoint is a straightforward case. A platform returning server-rendered HTML or XML/SOAP responses requires parsing logic that RPA tools apply inconsistently across page updates. HTTP-native integration handles these formats by design.

3. Platform update frequency. For government portals and legacy enterprise systems on political or contractor-driven release cycles, the unpredictability of interface changes is the critical maintenance risk. An approach that is decoupled from the visual interface eliminates that risk. Browser automation is directly exposed to it.

4. Write operation requirements. If your integration only needs to read data, file exports may be sufficient depending on latency tolerance. If you need to submit records, trigger actions, or update fields, you need an approach that can replicate POST requests, which rules out file exports entirely.

5. Throughput and latency requirements. Browser automation serializes requests through a full rendering engine, which limits throughput and adds latency. HTTP-native integration sends requests directly, with response times under 3 seconds and the ability to handle concurrent calls at scale. For production workloads with volume requirements, this difference is significant.

For a deeper look at the technical tradeoffs between browser automation and direct HTTP integration, see our post on browser automation vs. direct HTTP.

Get Started

Integuru builds HTTP-native integrations for legacy systems and government portals that have no public API. If your team is blocked on a platform that only exposes a web interface, we can generate production-ready API endpoints from that platform's HTTP layer, typically within 10 to 20 minutes of account connection.

Get started with the CLI:

npm install -g integuru

Or connect directly at app.integuru.com.

For legacy platform discussions, book a call with the team.