How Do You Integrate a Legacy System That Has No API?

An ERP module, an insurance portal, or a municipal billing platform built before REST became standard still holds the data your team needs. The vendor has no plan to expose an API for it, and rebuilding the system is not on the table this year. Deck exists for exactly this gap: connecting to legacy systems that were never designed to be connected to anything. This guide walks through every realistic path into a legacy system with no API, where each one holds up, and where it breaks down. Legacy system integration is the recurring theme, because almost every option below gets evaluated against the same question: does this actually work on a system nobody built for integration in the first place.

What Counts as a Legacy System With No API?

A legacy system with no API is any application, portal, or platform that holds business-critical data but exposes no REST endpoint, webhook, or SDK for external programs to use. Mainframes, on-premise ERP modules, insurance core systems, and municipal billing platforms fall into this category. Most were built when direct database access or flat file exports were the accepted way to move data. Vendors had little reason to retrofit modern APIs onto systems that already worked. Many still don't. The result is hundreds of thousands of business-critical systems that offer no programmatic way in, which is the entire reason legacy system integration keeps showing up as a distinct engineering problem instead of a solved one.

What Are Your Options for Connecting to It?

Deck is a computer use agent platform that automates workflows by operating any web interface directly, so the target system never has to expose an API for it to work. That framing matters because it points at the actual decision teams face: pick the integration method that matches how the legacy system was built, not the one that looks most modern on paper. The realistic options, in order of how often they actually apply:

1. Direct database access: query the underlying tables when you control the infrastructure.
2. File-based integration: consume scheduled CSV, EDI, or flat file exports for batch use cases.
3. RPA: script a bot against a stable desktop UI for repetitive, unchanging tasks.
4. Browser automation: control a real browser against a web portal, built and maintained in-house.
5. User-permissioned access through Deck: connect to a web portal using each user's own credentials, without building or maintaining the automation layer yourself. Each one is covered in detail below, including where it works and where legacy system integration projects using it tend to fail.

Can You Just Connect Directly to the Database?

Direct database access is the most reliable path when the legacy system runs on SQL Server, Oracle, MySQL, or PostgreSQL and you control the infrastructure. You query the tables directly and write results into an application layer or intermediate store. It works well for on-premise deployments with stable schemas and read-only use cases. It breaks down fast elsewhere. Many vendor license agreements explicitly prohibit direct database access. Writing data back can corrupt application-layer state that the vendor's own software depends on. Cloud-hosted and SaaS legacy systems will not expose this option at all, and a vendor schema change during an upgrade can break the integration without warning.

What About File-Based Integration (SFTP, CSV, EDI)?

Many legacy systems were built around file exchange as their only external interface. The system drops a CSV, fixed-width, or EDI file to an SFTP server on a schedule, and a downstream process picks it up. This works for batch reporting, utility billing, insurance claims, and regulated EDI exchanges. It does not work for anything real-time. Data is always hours or days old, inbound imports are error-prone, and file formats shift inconsistently between vendor versions. Legacy system integration built entirely on file exchange caps out at reporting use cases.

Does RPA Solve This?

RPA tools like UiPath, Automation Anywhere, and Blue Prism were built for this exact problem: simulate a human clicking through a desktop or web interface, and turn that into a repeatable bot. RPA fits predictable Windows desktop applications with a UI that does not change. It fits poorly almost everywhere else. Any UI update breaks the bot. Bots need dedicated machines or virtual desktops to run, scaling means buying more licenses, and RPA was never built for on-demand, API-style access. Web portals with MFA, dynamic content, or login flows are a weak spot for traditional RPA, which is exactly the territory most legacy system integration work lives in today.

What About Browser Automation?

Browser automation tools such as Playwright, Puppeteer, and Selenium control a real browser programmatically. Unlike RPA, they handle JavaScript-rendered content, complex logins, and stateful sessions natively, which makes them a real option for web-based legacy portals. The tradeoff is maintenance. Someone has to build and maintain element selectors, and every UI change to the target portal is a ticket in your backlog. Running this at scale, across many users and many target systems, requires real infrastructure: session management, MFA handling, CAPTCHA handling, and retry logic. Teams that go this route on their own are effectively building an internal version of what Deck already runs as a product.

What Is User-Permissioned Web Access, and Why Does It Matter Here?

User-permissioned access is the most practical model when the legacy system is one where each end user has their own account: an insurance portal, a utility account, an ERP self-service login, a benefits platform. Instead of your team holding a shared service credential, the end user grants access to their own account, and the integration layer operates within exactly what that user is authorized to see and do. Deck provides the infrastructure for this. Teams connect to a target portal using end-user credentials through Deck's API, extract structured data, and take action, without building or maintaining browser infrastructure or portal-specific selectors themselves. As AI agents take on more operational work, filing claims, paying bills, updating account records, this is the access model that scales with the user base instead of the engineering team.

Why Does This Beat RPA or a Custom API Build?

Custom API development against a legacy system usually means asking a vendor to build something they have no roadmap for, then waiting. That timeline rarely fits a real project. RPA scales linearly with license count and breaks every time a vendor changes a screen. It was built for stable, back-office tasks, not for connecting to portals with per-user logins or shifting layouts. Manual processes work until volume grows past what a team can do by hand. Deck's approach sidesteps all three tradeoffs. It does not require vendor cooperation, it does not require a bot per screen layout, and it does not require a person doing the work manually once volume increases.

What Does This Look Like in Practice?

A mid-size property and casualty insurer needed claims adjusters to pull policy status from a dozen different carrier portals before processing a claim, each with its own login and layout. Building direct integrations was off the table since none of the carriers exposed an API, and RPA scripts against a dozen different UIs broke on a near-weekly basis. The team moved this workflow to Deck. Adjusters authenticate once per carrier through Deck, and the agent logs into each portal with the adjuster's own credentials, pulls policy status, and returns structured JSON to the claims system. Manual lookup that took 15 to 20 minutes per claim dropped to under 90 seconds, with the audit trail from every session preserved for compliance review.

How Do You Choose the Right Option?

The question that decides most of this: does each user have their own account, or does your organization control one shared instance of the system? User-owned accounts point toward Deck. A single shared instance is worth evaluating for direct database access or file-based integration first.

FAQs

Does Deck work with systems that have no API at all?

Yes. Deck is built specifically for this case. It operates the target system's web interface directly, the same way a human user would, so the legacy system never has to expose an API for Deck to work with it.

Is Deck a replacement for RPA tools like UiPath?

For legacy system integration involving web portals, per-user logins, or interfaces that change often, Deck replaces the need for RPA. For stable, high-volume desktop workflows that never change, RPA still has a place, and some teams run both.

What is the difference between browser automation and Deck?

Browser automation frameworks like Playwright give you the building blocks. Your team still writes and maintains the selectors, session handling, and MFA logic. Deck provides that infrastructure as a managed platform, so teams connect to a portal through Deck's API instead of building the automation layer themselves.

How long does it take to set up legacy system integration with Deck?

Most teams have a first agent connected to a target portal within a day, since there is no custom scraper to write and no vendor API to wait on.

Does Deck support systems that require MFA?

Yes. Deck handles multi-factor authentication as part of connecting an account, and manages session continuity so the connection stays live across a multi-step workflow.

Related reading

• How To Integrate Without API: A Guide to Software Integration
• How to Automate Legacy Systems with Computer Use Agents
• Computer Use Agents vs. RPA: What's the Difference?
• Native Integration vs API: Costs, Trade-offs & What to Do When Neither Works