Can you automate software that has no API?

Why this question comes up so often

Automation projects tend to stall at the same place. The customer records, the finance system or the government portal at the centre of the process turns out to have no way of connecting to it, and that is almost always the system holding the data worth automating. The usual advice is to wait for the vendor, replace the software, or accept that the process stays manual. All three are expensive, and none of them is the only option.

The honest position is that every route below is a compromise against a proper interface. They differ in how durable they are, how much maintenance they carry, and how badly they fail. Choosing correctly between them is most of the work.

The four routes, in the order to try them

1. The vendor interface you were not told about

A surprising proportion of software described as having no interface has one. It may be undocumented, sold as a paid add-on, restricted to a higher licence tier, or exist only as a partner programme nobody mentioned during the sales process. It is worth an hour to check the support portal, ask the account manager directly, and inspect what the software's own web client sends when a member of staff uses it, because a hosted application is almost always talking to an interface of some kind. When this route exists it beats every other option outright: it is supported, it is stable across upgrades, and it does not depend on the screen staying the same.

2. Direct access to the database

Where the software runs on your own servers, the data usually sits in a database you control. A read-only account against a reporting replica is the cleanest arrangement in this whole list: fast, reliable, and invisible to the application. Writing directly into those tables is a different matter. The application enforces validation, sequence numbers and audit rules in its own code, and writing underneath it can create records the software itself regards as invalid. As a rule, read from the database and write through something else.

3. Scheduled file exchange

Nearly every business system can produce a report and nearly every one can import a file. A nightly export dropped onto a shared location, or a scheduled report emailed to a monitored address, is unglamorous and remarkably durable. It survives software upgrades, needs no credentials held by the automation, and is easy for an auditor to follow. The cost is latency: this route suits daily reconciliation and reporting, and does not suit anything that has to happen while a customer is on the line.

4. Driving the interface, the way your team does

The final route is to operate the software through its own screens: signing in, navigating, reading fields, typing values and confirming. This is robotic process automation in its browser and desktop forms, and in 2026 it is considerably more capable than its reputation suggests, because a model can now read a screen and adapt to a moved button rather than replaying fixed coordinates. It is the route that unlocks portals, internal platforms, government systems and software a supplier has no intention of ever upgrading. It is also the most fragile of the four and the one with the most conditions attached, which is why it comes last rather than first.

Which route applies when

The risks, stated plainly

Anyone offering to automate a system with no interface should raise these before the contract rather than after the first failure.

1. 1

   The terms of service may prohibit it

   For software your organisation licences and your staff already operate, automated access is usually a contractual question rather than a legal one, and many agreements permit it. Hosted platforms, third party portals and government systems frequently prohibit it outright. Read the terms first. Where they prohibit it, the answer is no, and a supplier who does not check has transferred that risk to you without saying so.

2. 2

   Multi-factor sign-in is the most common blocker

   Workable options are a service account whose authenticator secret the automation can compute, an allow-listed network address, or a person approving a single sign-in at the start of a scheduled run. Hardware keys and one-time codes sent to a personal device usually end the conversation, and it is better to find that out in discovery than in week three.

3. 3

   The screen will change eventually

   Internal and legacy systems change rarely, which is why they are good candidates. Modern hosted platforms redesign several times a year, and each redesign can break a step. This route therefore carries a permanent maintenance obligation. Whoever owns that obligation should be named in writing.

4. 4

   Credentials have to live somewhere

   The automation needs an identity. It should be its own service account with the minimum permissions the task requires, never a member of staff's login, and its secrets should sit in a managed store rather than in a script. A shared personal login also destroys the audit trail, because every action then appears to have been taken by that person.

5. 5

   Silent failure is worse than loud failure

   The characteristic failure of this approach is not a crash but a run that completes having done nothing, because a page loaded slowly and a field was empty. Every step needs a positive confirmation that it worked, and a run that processes zero items should raise an alert rather than report success.

What a well built version looks like

• A dedicated service account with least privilege, not a member of staff's credentials.
• Every step verified by reading the result back, so a run cannot report success having done nothing.
• A screenshot or a written record of each action, so an auditor can reconstruct what happened and when.
• Rate limiting that keeps the automation within the pace a human user would plausibly work at, which also keeps it inside most acceptable use policies.
• An exception queue for anything unexpected, and an alert to a named person when a run fails twice in a row.
• A documented rollback for anything that writes, because the ability to undo a bad run matters more than the speed of a good one.

Our own position, marked as ours

This is the part of the market we deliberately built for, because most automation suppliers stop at the first system without an interface and that is usually the system that matters. A typical legacy bridge we build removes in the region of three days a month of re-keying between systems. That is a figure typical of a first build rather than a measured result for a named client, and it depends entirely on how much manual transfer the process contained to begin with. Where the terms of service prohibit this approach, we say so during discovery and we do not build it.

Reviewed 25 July 2026. Market figures change; where this page quotes a range from a third party, the source is named above. Figures described as ours are our published fees or typical results for a first build, not measured results for a named client.