Automating against a system with no API

Most automation writing assumes both ends are modern software with a documented API. A great deal of real business software is not: the practice-management system from 2011, the industry package with four hundred customers worldwide, the tool someone built in-house years ago.

These are automatable. The question is which route in you take, and the answer changes the cost, the fragility and the maintenance obligation by an order of magnitude. This is how we work through it.

1. An undocumented API

Worth ruling out first, because it is more common than people expect. A system with a web interface built in the last fifteen years usually talks to a backend over HTTP, and that traffic is an API whether or not anyone documented it.

You can see it in the browser's network tab. Sometimes it is clean and usable. Two cautions, and they are serious. An undocumented interface carries no stability promise. The vendor can change it without notice because officially nobody was using it. And check the terms of service before relying on it; some vendors prohibit programmatic access outside their own tooling, and that is a commercial decision rather than a technical one.

Our position: worth investigating, only adopted where the terms permit it and the client accepts that it may break without warning. Never the recommendation when a supported route exists.

2. Scheduled export and import

The most underrated option on this list. Many older systems cannot answer a live query but will produce a file on a schedule: a nightly CSV, a report to an email address, a drop onto a shared folder. Many will also ingest one.

This is a real integration and it has genuine advantages. It is stable, because export formats change far less often than interfaces. It survives vendor updates. It fails in obvious ways: the file is there or it is not. And it is cheap.

What you give up is immediacy. You inherit the export's cadence, so a nightly file means a nightly automation. For reconciliation, reporting, syncing reference data or anything batch-shaped, that is not a real loss. For lead routing, where the whole value is responding in under a minute, it is fatal.

Designing for it

• Treat a missing file as an error, not silence. If the export does not arrive, something is wrong; the automation should say so rather than process nothing and report success.
• Checksum or hash each file. The same export processed twice is a duplicate-data incident. This is idempotency in its simplest form.
• Validate the shape before trusting the contents. Column added, column reordered, encoding changed: catch it on arrival rather than three steps later.
• Keep the raw files. When someone disputes a number in four months, the original export settles it.

3. Direct database access

Where the system runs on a database you control, reading from it is fast and reliable, and for reporting it is often the right answer.

Reading and writing are not equivalent risks. Reading is generally safe. Writing around the application is not: it bypasses whatever validation, business logic and audit behavior the application applies. You can create records the software itself considers invalid, and nothing will tell you until something downstream breaks in a way nobody can trace.

Our default is read-only from the database, with writes through a legitimate route even when slower. Where a write genuinely has to go direct, it needs a rollback plan and a validation pass that proves the application still agrees the data is sane.

The other hazard is schema drift. Undocumented schemas change on vendor updates: a renamed column, a changed type, a new nullable field with meaning. Build a schema check that runs before the real work and fails loudly.

4. Email and file drop

If the only outbound capability is printing to email, that is still a trigger. A surprising number of legacy systems can email a report, and an inbox is a perfectly good integration point.

You are now dependent on that report's layout, so extraction has to be defensive: validate that the fields you found are plausible, and route anything that fails to a person rather than guessing. Combine with document extraction if what arrives is a PDF.

One practical warning: email is not ordered and not guaranteed. Messages arrive late, out of sequence, occasionally twice. Anything built on it needs sequence handling and duplicate detection.

5. Driving the interface

Software clicking buttons and reading the screen. It works and it is genuinely the only route for some systems. It is also the most fragile option.

Why it is last

• It breaks on cosmetic changes. A button moves, a field is renamed, a dialog is added. Nothing functional changed and the automation is dead.
• Failures can be silent and destructive. A mis-click does not throw an error; it does the wrong thing confidently. Interface automation needs verification after every consequential action. Read back what was written and confirm it matches.
• It needs somewhere to run. A machine or virtual desktop that stays on, stays logged in, and does not get Windows updates at an inconvenient moment. That machine is now infrastructure.
• It is slow. Interface speed, not API speed. Fine for forty records, not for four thousand.

Doing it as safely as it can be done

1. Verify every write. Read the record back and compare. This single practice prevents most of the damage.
2. Anchor on stable identifiers where the software exposes them, rather than screen positions.
3. Make it stop, never guess. If the screen is not what was expected, halt and alert. Never "try the next thing".
4. Screenshot on failure. Debugging without one is guesswork.
5. Run it somewhere nobody uses. Not on a person's desktop, where a stray keystroke can interfere.
6. Budget maintenance from day one. This is a moving part. Treating it as a one-off purchase is the mistake.

The option most people miss

Automate everything around the legacy system and leave one manual step inside it.

Concretely: the automation collects the inputs, validates them, does the matching, prepares exactly what needs entering, and presents it as a single short list. A person spends four minutes a day typing it into the old system. Everything downstream then picks up automatically.

This is frequently the better deal. You get most of the time saving and almost none of the fragility, and the human step doubles as a check. When we price a no-API project, this is the version we quote alongside the full one, because for a system due for replacement in two years it is obviously correct and considerably cheaper.

Deciding quickly

Tell whoever is quoting which row you are on. It moves both the timeline and the price more than anything else you could say, and a quote that has not accounted for it will move later.