Automating Software That Has No API
Plenty of Australian businesses run an ERP, a practice management system or a trade package that was written before anybody expected software to talk to anything else. The vendor has no integration roadmap, the support desk suggests exporting to a spreadsheet, and meanwhile two people spend their mornings retyping the same numbers into a second system. That is a real problem and it has real answers, but the answers are not equally good.
A screen level robot, one that drives the software the way a person does, is the answer most people arrive at first. It should be the answer you arrive at last. This page sets out the ladder from best route to worst, tells you honestly what breaks and how, and explains why we will not build a robot for anyone who is not willing to pay for its upkeep.
Realistic ROI
Four Things to Understand Before You Buy a Robot
Screen level automation is a genuine tool and we build it. It is also the most fragile thing in the toolbox, and most of the disappointment around it comes from four misunderstandings.
A robot is the last rung, not the first idea
The instinct when a system has no API is to reach straight for something that clicks the buttons. Skipping the ladder is expensive, because the rungs above it are cheaper to build, far cheaper to keep alive, and usually already sitting in the software waiting to be switched on. We have lost count of the systems described to us as closed that turned out to have a nightly export, an ODBC driver, a documented report writer, or a paid integration module the client had never been told about. Spend the three hours checking before you spend the money building.
Screen automation breaks silently, and that is the real danger
When a supported interface breaks it usually returns an error, and an error can be caught, alerted and retried. When a screen robot breaks it often does not error at all. A field moves two rows down, the robot types the invoice total into the reference box, presses save, and reports success. Ten days later somebody notices the ledger is wrong and nobody can say which of the four hundred records the robot touched are affected. Every design decision in a screen automation project should be aimed at making that scenario impossible or at least immediately visible.
Maintenance is part of the product, not an optional extra
A screen robot is coupled to a user interface that somebody else controls and can change without telling you. That means it needs somebody watching it, a defined response when it fails, and a budget for the fix. Priced honestly, ongoing upkeep is a real line item rather than a rounding error, and a business that cannot carry that line should not buy the robot. We would rather talk a client out of the project at the quoting stage than hand over something that will quietly rot after the first vendor update.
Governance is what separates a tool from a liability
A robot that logs in as Sharon from accounts is indistinguishable from Sharon in every audit trail the system keeps, which is a problem the day something goes wrong or the day Sharon leaves. It needs its own named account with only the permissions the task requires, its own record of every action it took with a timestamp and a before value, and a human sign off on anything that moves money or leaves the building. None of that is expensive to build in at the start. All of it is painful to retrofit after an incident.
The Decision Ladder, Best Route to Worst
Work down this list in order. Stop at the first rung that works, because every rung below it costs more to build and much more to keep running.
Rung 1
Ask the vendor directly, in writing, whether there is an API, a web service, a partner integration programme or an add on module that exposes data. Ask their partner channel too, because resellers often know about interfaces the front line support desk has never mentioned. Even a paid, limited or poorly documented interface beats a robot by a wide margin, because it is a contract the vendor has some obligation to honour. If one exists, the conversation changes from automation engineering to integration work, and the whole project gets cheaper and steadier.
Rung 2
Many older on premise systems sit on a standard database and can be read directly, often through an ODBC or SQL connection the vendor already supports for reporting purposes. Reading is usually safe and enormously useful, because it gets you clean data for dashboards, reconciliations and downstream systems without touching a single screen. Writing directly to a vendor database is a different matter and normally a bad idea, since it bypasses the application logic that keeps records consistent and will void your support agreement. Get permission in writing, treat it as read only unless the vendor says otherwise, and take a copy rather than querying the live server during business hours.
Rung 3
Almost every business system can write a file, and a surprising number can do it on a schedule to a folder or a file transfer destination. A nightly CSV of jobs, invoices or patients dropped into a watched folder is unglamorous, boring and remarkably robust, and it will still be running in five years. The same works in reverse for import, where many systems accept a formatted file that the vendor already documents for data migration purposes. If the export exists but the schedule does not, ask whether the vendor can run it from a command line or a scheduled task, which is often a small piece of paid work.
Rung 4
If nothing else, most systems can email a report to somebody every morning, and a report arriving as a PDF or spreadsheet attachment in a monitored mailbox is a usable data feed. It is one sided and it is slow, but it is stable and it requires no cooperation from the vendor at all. This route is often enough for the actual business need, which is frequently reporting, reconciliation or an alert rather than genuine two way integration. Be honest about what the job really requires before dismissing it as too crude.
Rung 5
Before building anything fragile, price the alternatives properly: a paid custom export from the vendor, an upgrade to a version that has an interface, an add on module, or a third party connector built specifically for that product. Vendors will sometimes quote a fixed fee for a one off extract or a custom export, and it costs nothing to ask for that quote in writing before assuming a robot is the cheaper path. Weigh whatever comes back against several years of robot maintenance rather than against the build cost alone, and the sums often land somewhere different from where people expect.
Rung 6
Only when every rung above has genuinely been ruled out does a screen level robot make sense. It logs in with its own account, navigates the software the way a trained person would, reads what is on screen and enters what needs entering. Done properly it is checked against expected values at every step, it stops rather than guesses when the screen does not look right, it writes a full record of everything it did, and a person reviews anything financial before it becomes real. Done improperly it is a very fast way to fill a database with wrong data.
Common Jobs and the Route That Usually Wins
| Task | Traditional | Route to check first | Notes |
|---|---|---|---|
| Get yesterday’s sales into a dashboard | Robot opens the report screen daily | Scheduled export or read only database query | Reporting is a read problem, and read problems almost never need a robot. This is the single most over engineered request we see. |
| Push new customers into the accounting system | Robot types into the customer screen | Check for a supported import file first | Most accounting packages, even old ones, document a contact import format because they need it for migrations. |
| Raise invoices in an old practice system | Robot fills the invoice form | Vendor import route, then a robot only if refused | Anything touching money should carry a human check, whichever route you take. Volume decides whether the effort is justified at all. |
| Reconcile two systems that disagree | A person compares two screens | Export both sides and compare the files | Comparison is a data job. Getting data out of both systems is far easier than driving either one. |
| Book jobs from a web form into a trade package | Robot keys the job in | Check the mobile app or partner interface | A vendor with a mobile app usually has an interface behind it, even if it is not publicly documented. Ask the partner channel. |
| Chase overdue accounts | Robot reads the aged debtors screen | Scheduled aged debtors report to a mailbox | Once you have the list, the chasing happens outside the old system entirely, which removes the fragile part. |
| Keep stock levels in step across two systems | Robot updates quantities on screen | Whichever system has a real interface becomes the master | Two way syncing through a screen is the highest risk pattern there is. Make one system authoritative and publish one way. |
| Extract history before a migration | Robot pages through records | Ask the vendor for an extract, in writing | Vendors are usually cooperative about exit data because the alternative is an unhappy customer telling people about it. |
What Actually Goes Wrong With Screen Level Automation
Silent failure that corrupts rather than stops
The failure mode people prepare for is the robot crashing, which is the easy one because you notice. The failure mode that hurts is a layout change that shifts a field, so the robot keeps working and keeps writing values into the wrong places. Defend against it by validating what is on screen before every write, reading the record back after saving and comparing it to what was intended, and stopping the whole run the moment anything does not match rather than skipping the record and carrying on. A robot that halts loudly at record twelve is a minor inconvenience. A robot that quietly mangles records twelve through four hundred is a month of reconstruction.
Shared logins and borrowed credentials
The quickest way to get a robot working is to let it use a staff member’s login, and it is the decision you will regret. Every action the robot takes becomes attributable to a real person in the audit log, which undermines any investigation and is unfair to the staff member. It also means the robot dies the day that person changes their password or leaves. Create a named service account with the minimum permissions the task needs, store the password properly rather than in a script, and check that the licence actually permits an additional non human user, because some vendors charge per named user. Borrowing a person’s credentials is frequently a straight breach of the terms in any case. MYOB’s business terms, to take one published Australian example, tell subscribers never to let anyone else access the product using their username and password, whether acting as their agent or not (checked August 2026).
Vendor terms and support agreements
Read what you signed, because this is not a hypothetical risk. Atlassian’s acceptable use policy, to take one published example, prohibits accessing or searching any part of its services by any means other than its publicly supported interfaces, and names scraping specifically (checked August 2026). Other vendors do not forbid automation but will decline support for any environment where it is present, which matters the day you have a genuine unrelated problem. Terms vary enormously between products and get revised without fanfare, so read your own rather than assuming the general case, and put the question to the vendor in writing before you build. The answer is sometimes a shrug and sometimes a paid integration option you did not know existed.
Nobody owning it after go live
Screen automation accumulates undocumented knowledge fast: which screen has the slow load, which popup appears only on Mondays, which field must be tabbed rather than clicked. If that lives in one contractor’s head, the first vendor update after they move on becomes an emergency. Insist that the automation is documented as a written deliverable, that the failure alerts go to a monitored address rather than an individual’s inbox, and that somebody inside the business knows how to turn it off and do the work manually for a week if needed.
Timing, popups and the small print of a user interface
A screen robot is racing an interface that was designed for human patience. Pages that load in one second on a quiet morning take eight during end of month, dialogues about expiring passwords or new terms appear without warning, and a system that logs you out after inactivity will do so mid run. The right response is generous waiting for specific things to appear rather than fixed pauses, explicit handling of the known interruptions, and a run window chosen for when the system is quiet. Most robots that are described as unreliable are actually just impatient.
Automating a process that should have been deleted
The most expensive screen automation is the one that faithfully reproduces a bad process. Before automating the retyping, ask why the data has to be in both systems at all, whether the downstream system is still needed, and whether the report anyone is producing is still read by a human being. We have seen requests to automate a daily transfer that existed only because of a reporting need that ended three years earlier. Delete first, simplify second, automate third.
How Yes AI Approaches Software With No API
We hunt for a real route before we quote a robot
The first piece of work is a structured search for a supported path: a written question to the vendor and their partner channel, a look through the export, report and scheduling menus, and a check for third party connectors built for that product. You get the findings in plain language whether or not we end up building anything.
We will talk you out of it when the numbers do not work
If the task is twenty minutes a week, or the vendor will sell you an extract for a few thousand dollars, or you are already scoping a system replacement for next year, we will say so. A screen robot is only worth building where the volume is genuinely high, the process is stable, and the business can carry the upkeep.
Built to stop rather than guess
Every automation we build validates the screen before writing, reads the record back afterwards, and halts the run on any mismatch instead of continuing. Every action is logged with a timestamp and the values involved, and anything touching money or leaving the business waits for a human to approve it.
Maintenance is quoted with the build, not after it
The proposal includes the ongoing arrangement: who watches the alerts, what the response time is, and what happens when the vendor changes the interface. If that arrangement is not agreed, we do not build the robot, because an unsupervised one becomes a data quality problem rather than a saving.
From Stuck System to Something That Runs
Five steps. Two of them are aimed at avoiding the robot entirely, which is the point.
Map the real job and count the volume
We watch the task being done, record what actually happens including the exceptions people handle without thinking, and count how many times a week it runs. That number decides whether any of this is worth doing and which route can justify its cost.
Hunt for a supported route
A written question to the vendor and their partners, a search of the export, report, scheduling and integration menus, a check for a database connection the vendor permits, and a look at third party connectors. Findings written down, with prices where a paid option exists.
Design for failure if a robot is the answer
Its own named login with minimum permissions, screen validation before every write, read back verification after, a hard stop on any mismatch, complete action logging, and a human approval gate on anything financial. Agreed before a line is built.
Run it in shadow beside the humans
The automation runs alongside the existing manual process for a defined period, producing output nobody acts on, so its results can be compared against what people actually did. Discrepancies are investigated before the manual process is switched off.
Hand over with a maintenance arrangement in place
Written documentation, alerts routed to a monitored address, a named owner inside your business, a tested manual fallback for the week something breaks, and an agreed support arrangement with response times.
Related Reading
RPA for Australian SMEs
Robotic process automation without the enterprise vocabulary, including honest economics.
Screen Automation for Legacy ERP
For the business on an old on premise system that is not going anywhere soon.
Legacy System Integration
Connecting older business systems without replacing them first.
Custom API Integration
When a supported interface does exist and needs building against.
Eliminate Double Data Entry
The problem most of these projects are actually trying to solve.
Data Migration Services
Getting your history out when the answer turns out to be replacement.
FAQ
Find Out Which Rung You Are Actually On
Book a call. We work through the ladder with you, ask the vendor the right questions, and tell you plainly whether a robot is justified or whether there is a cheaper route you have not been shown. If the honest answer is do nothing, you will get that too.
All discussions held in confidence. Australian-based consultants.