How to Automate Software With No API: A Guide for Engineers

If you are building an AI product for a legacy-heavy vertical, the wall you hit is rarely the model. It is the last mile into your customer's system of record. The contract is signed, the workflow is scoped, and then you find out the API you were counting on does not cover the thing you actually need to write.

This guide covers the honest options for driving software programmatically when an API is not available for your workflow, how each option fails, and what it takes to keep an automation alive in production after the vendor ships a UI change.

"No API" usually means "no API for this"

Most of the time the vendor has an API. It just does not solve your problem. In practice the blocker takes one of four shapes:

• Read-only for the object you need. You can pull the record, but the write path for that field or that document type is not exposed.

• The workflow is not modeled. The API covers the common objects and stops before the multi-screen flow your customer actually runs.

• Tenant access you cannot get in time. Approval sits with the customer's IT organization or the vendor's partner program, and your go-live date is in three weeks.

• The step only exists on the desktop. Some part of the flow lives in a Windows client, a Citrix-published app, or a terminal emulator, and there is no server-side equivalent.

None of those get fixed by reading the docs harder. When the integration surface you need does not exist, the remaining option is to drive the interface a human would use.

Your three options, and how each one breaks

1. Screen scraping. Read pixels, match templates, click coordinates. It works on a demo machine and falls apart on a real fleet. Different resolutions, DPI scaling, theme changes, and a resized window all break coordinate matching. Skip it.

2. Traditional RPA. Bind to UI elements through the accessibility tree or window handles, then replay a recorded click path. This is a real improvement, and it is what most teams reach for first. The scripts are deterministic and fast. The problem is that they are also rigid: the automation assumes the UI it was recorded against, so a renamed field, a new modal, or a reordered tab stops the run.

3. Computer-use agents. Hand a vision-capable model a screenshot and let it decide what to click, every time, from scratch. This handles change gracefully, which is exactly what RPA cannot do. The trade-off is per-action reliability. Even a small error rate compounds badly: at 90% per-action accuracy, a fifteen-step workflow completes about a fifth of the time. Running a model on every click is also slow and expensive compared to executing code, and it is non-deterministic, which is a hard sell for a compliance reviewer looking at patient or financial data.

The useful conclusion is that these are not three competing products. They are three points on a reliability-versus-adaptability curve, and production needs both ends of it.

Maintenance is the actual cost

Writing the first automation is a weekend. Keeping thirty of them running across a dozen customer environments is a headcount.

This is the part that surprises teams. You ship the integration, the customer is live, and then your engineers spend their sprints on click paths instead of on your product. A vendor pushes a point release, a customer's admin rearranges a form, someone enables a new consent modal, and a run that worked yesterday now fails silently or, worse, writes to the wrong field. Every one of those is a page, a triage, and a patch.

Any evaluation of desktop automation that only measures how fast you can build the first bot is measuring the wrong thing. Ask what happens on the day the UI changes.

The architecture that holds up

The pattern that works in production is to separate the two jobs instead of picking one tool for both.

Run deterministic code on the happy path. Once the workflow is known, store it as deterministic code. It executes in milliseconds, costs nothing per run, produces the same result every time, and can be read and reviewed like any other code in your repo. This is what should handle the 95% of runs where nothing has changed.

Reserve the agent for recovery. When a step does not find what it expects, escalate to a computer-use agent instead of failing the run. Using a reflection agent that verifies and self-corrects every action works better than asking one model to do both. Minicor measures roughly 96 to 99 percent click accuracy using this approach, against roughly 80 to 85 percent for other computer use approaches. Those are Minicor's own numbers, not an independent benchmark, but the direction matches what anyone who has shipped this will tell you: grounding is a different skill from planning.

Verify every action before moving on. After each step, check the screen against what the step was supposed to accomplish. If the field did not populate or the dialog did not close, correct it in place rather than continuing into a broken state. This reflection step is what turns a silent bad write into a caught and retried one, and it is the difference between an automation you can put in front of a HIPAA auditor and one you cannot. There is more detail on how that recovery loop works in what is a self-healing automation.

What it needs before it touches real data

If your customer is a hospital, a lender, or a dealership group, the automation is not done when it works. It is done when it survives review.

• Where it runs. The client has to install on the machine that already has the legacy software, which usually means a Windows VM on the customer's own infrastructure, in cloud, or behind Citrix. Data leaving that boundary is often the thing that kills a deal.

• Proof of what happened. Video replay of each run plus granular per-action logs. When someone asks why a record changed at 2am, "the bot did it" is not an answer.

• Alerting that reaches a human. Failures should surface in the channel your on-call already watches, not in a dashboard nobody opens.

• Compliance posture. SOC 2 Type II and HIPAA are table stakes for healthcare and financial buyers, and they are usually a gate on the security review rather than a nice-to-have.

Walkthroughs by system

The general pattern is the same everywhere, but the specifics matter.

Where Minicor fits

Minicor is the version of this you do not have to build. You install the desktop client on the machine running the legacy software, record a video of a human performing the workflow, and get back an API endpoint. Calling it fires the automation on that machine: deterministic code on the happy path, agent recovery when the screen does not match, verification after every action, and video plus logs for the audit trail.

You call it the way you would call any other integration. Pricing is usage-based on successful writes, so you pay when the data lands.