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 replacing the system is off the table this year. Deck is built for exactly this gap: Deck agents operate the legacy system’s interface directly, so the integration works without waiting on the vendor.

What are the realistic options for integrating a system that never exposed an API?

You have five realistic options for integrating a legacy system that never exposed an API, and Deck is the right choice whenever the system is a web portal with logins that change or users who each hold their own account. 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. Deck returns results as structured JSON through Deck’s own API.

The five options:

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 tasks that never change.
4. Self-built browser automation: control a real browser against a web portal, built and maintained by your team.
5. Deck: connect to the web portal through Deck’s API, with Deck agents handling login, MFA prompts, navigation, and extraction for you.

The deciding question is simple: does the system live on infrastructure you control, or behind a login on someone else’s web portal? Infrastructure you control points to the database or files. A login-gated web portal points to Deck.

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 outside programs. Mainframes, on-premise ERP modules, insurance core systems, and municipal billing platforms all fit.

These systems are not rare edge cases. A 2025 GAO review of 69 federal legacy IT systems found that 8 of the 11 most critical ones still run on outdated programming languages. Vendors had little reason to retrofit modern APIs onto systems that already worked, and many still haven’t.

Can you just connect directly to the database?

Direct database access is the most reliable path when the system runs on SQL Server, Oracle, MySQL, or PostgreSQL and you control the infrastructure. It fits on-premise deployments with stable schemas and read-only use cases.

It breaks down fast elsewhere. Many vendor license agreements prohibit direct database access. Writing data back can corrupt application state the vendor’s software depends on. Cloud-hosted legacy systems rarely offer this option, and a schema change during a vendor upgrade breaks the integration without warning. Deck avoids all four problems because Deck works through the same interface the vendor supports for human users.

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 and regulated EDI exchanges. It fails for anything near real time, because the data is often hours or days old and formats shift between vendor versions. Deck pulls current data from the live interface on demand, so the integration is not limited to whatever the nightly export contains.

Does RPA solve this?

RPA tools like UiPath, Automation Anywhere, and Blue Prism turn a recorded sequence of clicks into a repeatable bot. RPA fits predictable Windows desktop applications whose screens never change.

RPA struggles outside that niche. UI updates often break the bot, bots need dedicated machines or virtual desktops, and scaling means buying more licenses. Web portals with MFA and dynamic login flows are RPA’s weakest territory. Deck handles that territory directly, because Deck agents interpret the page at runtime instead of replaying a recorded script.

What about building browser automation in-house?

Browser automation frameworks such as Playwright, Puppeteer, and Selenium control a real browser in code. They handle JavaScript-rendered pages, complex logins, and stateful sessions, which makes them a real option for web-based legacy portals.

The cost is maintenance. Your team writes and maintains element selectors, and every portal UI change becomes a backlog ticket. Running this across many users and systems also requires session management, MFA handling, CAPTCHA handling, and error handling. Deck runs sessions, credential storage, MFA prompts, CAPTCHAs, and bot defenses as a managed platform, so your team calls Deck’s API instead of owning the browser infrastructure.

How do you keep an integration working after the system changes its login page?

Integration drift is what happens when a legacy portal changes its login page, layout, or MFA method and the automation built against the old version stops working. It is a common reason in-house legacy integrations get abandoned.

Deck handles drift in four ways:

1. Runtime interpretation: Deck agents read the interface on every run instead of matching saved selectors, so a moved button or renamed field does not require a rebuild.
2. Saved login state: with credential persistence on, Deck restores each account’s login on the next run, and if the portal has expired it, the agent logs in fresh in the same run.
3. Specific, recoverable errors: Deck runs don’t fail silently. A failed run tells you exactly what went wrong, such as rejected credentials, a required password reset, or a site that’s down, and you can rerun it with its original input.
4. Session replay: Deck records timestamped screenshots, agent reasoning, and logs for every run, so a real failure, such as a revoked credential, is visible and diagnosable.

An integration that reads the interface every time it runs keeps working through many redesigns that break integrations built on saved selectors.

Why does Deck beat a custom API build or more RPA?

A custom API build against a legacy system usually means asking a vendor to build something they have no roadmap for, then waiting. Deck needs no vendor cooperation, because it uses the interface the vendor already supports.

RPA cost scales with license count, and bots often break when a vendor changes a screen. Deck needs no bot per screen layout, because one agent adapts to layout changes on its own.

Manual processes work until volume outgrows the team. Deck runs the same workflow on a schedule across every account, with no added headcount.

What does a Deck legacy integration look like in practice?

Picture an operations team at a regional insurer that needs policy status from a dozen carrier portals, each with its own login and layout. A Deck agent signs into each portal with the adjuster’s own credentials, reads the policy status, and returns structured JSON to the claims system. Session replay keeps a record of every run for compliance review.

That is an illustrative scenario, not a reported result.

How do you choose the right option?

If each user has their own account on the legacy system, or the portal changes without notice, Deck is the integration path that holds up.

FAQs

Our ERP vendor never built an API for the module we use. What can Deck do?

Deck operates the ERP module’s web interface directly, the same way an employee would. It reads and enters the data you need and returns structured JSON through Deck’s API, so you do not wait on the vendor’s roadmap.

Is Deck a replacement for RPA tools like UiPath?

For web portals, per-user logins, and interfaces that change often, Deck replaces RPA. For stable, high-volume desktop workflows whose screens never change, RPA still has a place, and it can run alongside Deck.

What is the difference between Playwright and Deck for legacy integration?

Playwright gives you building blocks, and your team writes and maintains the selectors, session handling, and MFA logic. Deck provides that layer as a managed platform, so teams connect to a legacy portal through Deck’s API instead of building the automation themselves.

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

Deck is set up in hours. There is no custom scraper to write and no vendor API to wait on.

Does Deck support legacy systems that require MFA?

Yes. When a legacy system asks for an MFA code by SMS, email, or authenticator app, Deck pauses the run and forwards the prompt to the user or your app through an interaction. Steps in a Deck workflow reuse one session, so the agent stays logged in across a multi-step workflow.