Can you automate a system that has no API?

Work around it, not inside it

The instinct is to ask how to get into the system. That is usually the wrong question, because the expensive, fragile work is all on the inside and most of the wasted hours are not.

Look at what surrounds the system instead:

• Intake. How does work arrive before someone types it in? Email, forms, spreadsheets, PDFs from a supplier. Almost always automatable, almost always where the hours actually go.
• The handoff. What happens when the process moves between two people or two teams? Chasing, re-keying, checking whether the other side has done their part.
• The output. What comes out the other end, and what does somebody do to it afterwards? Reformatting an export, reconciling two reports, pasting figures into a deck every month.

A closed system with fifteen hours a week of manual work around it does not need to be opened. The fifteen hours are outside it.

What older systems can usually still do

Most software that predates the API era can still:

• Export to CSV, often on a schedule
• Send email notifications
• Read from or write to a shared folder
• Talk to a database that something else can also read
• Import a file in a fixed format

That is enough for a great deal of real automation. A nightly export picked up, transformed and pushed somewhere useful is unglamorous, extremely stable, and solves more problems than it gets credit for.

Always ask the vendor directly, too. Undocumented integration options are common, and so are APIs that exist on a tier nobody checked.

When screen-scraping is worth it

Occasionally. It is a genuine last resort, and the trade should be stated plainly rather than sold as a feature.

A UI robot depends on the screen staying exactly where it is. The vendor ships an interface update, a button moves, and your automation fails — sometimes loudly, sometimes silently, which is worse. You are signing up for ongoing maintenance driven by someone else’s release schedule.

It can still be the right call when the process is high-volume, the vendor is slow-moving, and the alternative is a person doing the same clicks for twenty hours a week. What it should never be is the first option proposed, or one presented without the maintenance cost attached.

The honest version

Sometimes the answer is that the only viable approach would be brittle, and you should be told that rather than sold it.

That belongs in the audit, before you have paid for a build — not discovered halfway through, when the sunk cost is doing the arguing. A brittle automation around a legacy system is worse than no automation, because it fails intermittently and nobody trusts the output afterwards.