FlowRunner
PricingContact
Theme
Start Free

legacy-use

Developer Tools

Turn a legacy desktop application into a REST API with legacy-use, which drives it through an AI computer-use agent over RDP, VNC, or TeamViewer. Agents automate systems that were never given an interface.

24 actions API key available
Capability data verified 2026-08-01
A claim reaches the point where the policy record has to be read out of the legacy client
Agent checks List Sessions and confirms the target machine has a live remote desktop session
Agent calls Start Job with the API definition name and the claim's parameters
Agent polls Get Job and finds the status has stopped at paused rather than reaching success
Agent reads Get Job Logs to see exactly what the computer-use agent saw on screen
Agent posts that screen state and the fact the target's queue is now blocked to the claims channel
Claims supervisor fixes the desktop state and chooses between Resume Job and Cancel Job

What This Integration Enables

Every other connector in this part of the catalog is about the web. This one is not, and that is the entire argument. legacy-use drives a legacy desktop application over RDP, VNC or TeamViewer using an AI computer-use agent, which means the target is a Windows-only insurance client, a terminal emulator, an ERP that predates the idea of an integration. There is no page to parse and no endpoint to call. The agent looks at the screen and works the application the way a person does. Screen width and height are part of the target configuration for exactly that reason: the agent reasons over screenshots at precisely that resolution, so it has to match the real desktop.

It is also self-hosted, and for the systems this connector is pointed at, that is not a footnote. The base URL is your own instance, not a vendor host, so the screenshots of a policy record or a patient chart never leave infrastructure you control. Work is organised as API definitions: named, parameterised tasks with a declared parameter list, an example response and a JSON response schema the extraction step must produce. Definitions carry a version history, and Export API Definition and Import API Definition together give you backup, promotion between environments and version control of automations that were previously undocumented habits.

Without FlowRunner

No interface, no integration The system holding the record was built before APIs were expected, so nothing can reach it
Rekeying between screens Someone reads a value off a green screen and types it into a modern system
Undocumented tribal steps The click path through the legacy client lives with whoever has done it longest

With FlowRunner

The application behind a job A named, parameterised task runs against the desktop and returns structured JSON
Data moves without a person retyping it Extracted values land in the modern system in the same flow that requested them
Steps as a versioned definition The task is a definition with a parameter list, a response schema and an edit history

Use Case Scenarios

Reading a policy record out of a legacy claims client

A claim needs the policy details that only exist inside a Windows-only application. The flow confirms the target has a live session, calls Start Job with the read policy definition and the policy number as a parameter, and polls Get Job until the status is terminal. On success the extracted JSON arrives in the result field and the agent writes it into PostgreSQL alongside the claim, with the job ID recorded so the extraction can be traced back to the exact run and its screen logs.

Filing into a system that only accepts keystrokes

The other direction is harder and more valuable. A decision made in a modern system has to be entered into the legacy application. The agent calls Get API Definition first to build a correct parameters object, since the job fails outright when a required parameter is missing from the prompt template. It then calls Start Job and waits. Because jobs on a target run one at a time, the flow does not fire a batch of filings at once; it queues them and lets the target work through them in order, checking queue status with Get Target between submissions.

Promoting an automation from test to production

An API definition is tuned against a test instance until its extractions are reliable. Rather than rebuilding it by hand on the production instance, the agent calls Export API Definition to get the raw internal format, including the agent prompt, cleanup prompt, custom actions and response example, and calls Import API Definition on the target instance. An import of a definition whose name already exists is stored as a new version rather than overwriting, so the edit history survives the promotion. The exported payload is archived in S3 as the release artifact.

Human-in-Loop Highlight

legacy-use ships with the pause already built in, and the connector's own guidance says to pair it with a human step. A job can stop at paused when the agent sees something on screen it was not expecting: a modal it has no instruction for, a session that timed out, a record in a state the definition never anticipated. What makes this the sharpest gate in the batch is what a pause costs. Jobs on a target run one at a time, and a paused or errored job blocks that target's queue until somebody cancels or resolves it. One confused job does not stall itself. It stalls the machine, and everything queued behind it.

That is a digital andon cord in the most literal sense available in software, so the agent treats it as one rather than as an error to clear. It reads Get Job Logs, which is the clearest account of what the agent saw on screen and which actions it took, and posts to the claims channel: "Job 3f21 on target VM-CLAIMS-02 paused at the policy amendment screen. The agent expected the confirmation dialogue and found a warning about an unposted batch. Four jobs are queued behind it and the target is not running anything until this clears. Here are the last screen logs. Fix the application state and resume, or cancel and requeue?" A supervisor looks, fixes the desktop, and picks. Resume Job puts the job back with its context intact, which is why the connector recommends it over starting fresh. Cancel Job clears the queue. What nobody does is let an agent guess its way through an unexpected dialogue in a system with no undo.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via preferred channel
Human decides
Agent resumes with decision

Agent Capabilities

24 actions

Targets

6
  • List Targets Lists the machines legacy-use can drive, each with its connection type, host, screen size and live queue state. The queue status shows whether a target is currently paused by a blocking job, and the session flags show whether a remote session is already up. Passwords and VPN credentials stored on the target are never returned in full.
  • Get Target Retrieves a single target by ID with its connection settings and current queue state, including the jobs currently blocking its queue. Queue status is checked before starting work, because a target whose queue is paused will not run new jobs until the blocking job is cancelled or resolved.
  • Create Target Registers a machine legacy-use can drive over RDP, VNC or TeamViewer, optionally tunnelled through Tailscale, WireGuard or OpenVPN. Screen width and height matter, because the AI agent reasons over screenshots at exactly this resolution and it must match the real desktop. VPN variants additionally need the VPN config and credentials.
  • Update Target Updates a target's connection settings. Only the supplied fields change, so a password can be rotated or the virtual desktop resized without resending the whole configuration. Changing width or height affects what the agent sees on its next session, so definitions tuned to the old resolution may need revisiting.
  • Archive Target Archives a target so it no longer appears in the default listing and cannot receive new jobs. A soft delete: the target and its job history are preserved and can be brought back with Unarchive Target.
  • Unarchive Target Restores a previously archived target so it appears in listings and can run jobs again. Archived target IDs are found by calling List Targets with archived entries included.

API Definitions

6
  • List API Definitions Lists the API definitions on this instance. Each is a named, parameterised task the agent can perform against a legacy application, carrying the parameter list, an example response and the JSON response schema its extraction step must produce. The starting point for discovering what an instance can do.
  • Get API Definition Retrieves a single definition by name, including its parameter list, example response and generated JSON response schema. Read to build a correct parameters object before Start Job, since the agent fails the job when a required parameter is missing from the prompt template.
  • Get API Definition Metadata Returns lightweight metadata for one definition: internal ID, description, created and updated timestamps and whether it has been archived, without the parameter list or response schema. Cheaper than the full retrieval when only existence or archived state is in question.
  • Export API Definition Exports a definition in its raw internal format, including the agent prompt, cleanup prompt, custom actions and response example. Exactly the shape Import API Definition accepts, which is what makes backup, promotion between environments and version control possible.
  • Import API Definition Imports a definition from an exported JSON object. When a definition with the same name already exists, the import is stored as a new version of it rather than overwriting, so the full edit history survives. Paired with Export API Definition to promote an automation between instances.
  • List API Definition Versions Returns the version history of a definition. Every import or edit creates a new version and exactly one is active at a time, which is how prompt drift is audited and a known-good version identified for restoration.

Jobs

8
  • Start Job Queues a definition to run against a target and returns immediately with a job in pending state while the agent drives the remote desktop asynchronously. Parameters must match the definition's declared names, since they are rendered into the agent's prompt template. Jobs on one target run one at a time, so a queued job waits for that target's queue.
  • Get Job Retrieves a single job for polling after Start Job. Status moves through pending, queued and running to success, error or canceled, and may stop at paused when the agent needs human input. On success the result field holds the extracted JSON; on failure the error field explains why. Token counts and duration are included for cost tracking.
  • List Jobs Returns a paginated list of jobs across every target, filterable by status, target and definition name. Used to find jobs stuck in paused or error that are blocking a target's queue, or to reconcile a batch of submissions. Offset paginated rather than cursor based.
  • List Target Jobs Returns the job history for one target, newest first, with simple offset pagination. Used to audit what has run against a particular legacy machine, or to find the last successful extraction when a fresh run fails.
  • Cancel Job Cancels a job and marks its status as canceled. Used to abandon a run that is stuck or taking too long, and to unblock a target whose queue has paused behind it. The safe way to clear a blocked queue without discarding the job record.
  • Resume Job Puts a paused or errored job back into the queue so the agent retries it. Designed to be paired with a human step: when a job pauses because the desktop showed something unexpected, a person fixes the machine state and the job resumes with its context rather than starting fresh.
  • Get Job Logs Returns the log entries recorded while the agent worked on a job, which is the clearest account of what it saw on screen and which actions it took. Read when a job errors or produces the wrong extraction, before anyone edits the definition's prompt.
  • Get Job HTTP Exchanges Returns the raw request and response exchanges between legacy-use and the computer-use model for a job, showing the exact prompts sent and the tool calls the model chose. The deepest debugging view available, and a large one, since every screenshot round trip is recorded.

Sessions

4
  • List Sessions Lists the remote desktop sessions legacy-use is running, each with its target, lifecycle state and the status of the container hosting the connection. A target needs a live session before jobs run, so this is the first thing to check when jobs sit in queued forever.
  • Create Session Starts a remote desktop session for a target, spinning up the container that holds the RDP or VNC connection. The session returns in initializing state and becomes usable once ready, so the flow polls Get Session before queueing work. Reuse Existing attaches to a live session instead of creating a second one.
  • Get Session Retrieves a single session with its lifecycle state and container details. Polled after Create Session until the state reports ready, which is the point at which jobs queued against the target actually start running.
  • Archive Session Archives a session and tears down its container, freeing the connection to the target machine. Sessions cost resources while alive, so they are closed when a batch of jobs is finished. Jobs still running on the session are left to finish and a warning is logged.

Frequently Asked Questions

What can FlowRunner do with legacy-use?

FlowRunner agents can run List Targets, Get Target, and Create Target in legacy-use, plus 21 more actions.

Does connecting legacy-use to FlowRunner require OAuth?

No. legacy-use connects to FlowRunner with an API key, no OAuth flow required.

Can legacy-use trigger a FlowRunner workflow automatically?

legacy-use doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with legacy-use

$100 in credits. No card required. Connect in minutes.