Integrating with systems that have no API

“The system has no API” comes up constantly when an integration is being scoped, and it is almost never quite true. What it usually means is that there is no documented, supported web API. Data still gets in and out of the system every day, because people use it. The job is to find the way in that sits furthest from the screen.

The market’s default answer is robotic process automation: software that drives the application’s user interface the way a person would. Sometimes that is the right call. It is usually the last option worth reaching for, and the reason is structural rather than a matter of taste.

Every system has more than one way in

Before choosing a method, list every route by which data already enters and leaves the system. There are usually five, and they are worth considering in this order, because each is less stable than the one before it:

1. Ask the vendor. A paid integration module, a partner SDK or an API that exists but is not advertised is the only option here that comes with a promise attached. Finding out costs one email.
2. Files. Almost every business system can import and export something: a CSV, a scheduled report, an EDI message. A file format is a contract of sorts, and vendors change one far less often than they change a screen.
3. The database. A read-only connection to the underlying data, ideally through a reporting view or a replica rather than the live tables.
4. The private web API. A browser-based system talks to its own server through HTTP calls that are simply undocumented. They are more stable than the page built on top of them, but nobody has promised to keep them.
5. The screen. Automating the user interface itself.

In wholesale and retail the file route is often already in place. TRADACOMS, the UK retail EDI standard introduced in the early 1980s, has had no new message types since 1998, and GS1 UK withdrew all support for it on 1 July 2017. It is still in daily use between UK retailers and their suppliers. A dull, flat-file standard that has outlived its own maintainer is exactly the kind of interface worth building on.

Reading and writing are different problems

Most of the risk in a no-API integration sits in one decision that is rarely made out loud: are we reading from this system, or writing to it?

Reading is forgiving. If a nightly extract is wrong, you fix the query and run it again, and the source system is untouched. Some vendors provide read access on purpose. Sage’s own ODBC driver for Sage 50 Accounts is read-only: its documentation says you can retrieve data into other software, “but you cannot update information back into Sage Accounts”.

That is not an oversight. It is the right design, and it shows where the line is. An application’s business rules live in the application, not in its tables. Writing straight into the database of an accounting or stock system skips the validation, the stock allocation, the audit trail and whatever else the vendor runs when a record is saved through the front door. The new record looks correct, and the system around it is quietly inconsistent.

So the rule we apply is simple. Reads can come from whichever route is most stable. Writes go through an entry point the vendor built for writing: its import routine, its SDK, or, if there is genuinely nothing else, its own screens.

Read from wherever is most stable. Write only through a door the vendor built for writing, even when that door is a screen.

What screen automation really costs

The licence is the visible cost, and it is modest. Microsoft lists its Power Automate Process plan, which licenses one unattended bot, at £115.30 a month paid yearly, before VAT.

The real cost is that a screen is an interface designed for people, and its vendor promises nothing about it to anyone else. A relabelled button, a new confirmation dialogue or a field moved to another tab will break a bot, and the release notes will not mention it, because for a human user nothing important changed. Someone has to notice the failure, diagnose it and fix the script, and that work arrives whenever the vendor ships, not when you planned for it.

The harder problem is a failure halfway through a write. A bot that times out after pressing Submit cannot tell whether the order went in. Retry blindly and you create a duplicate; give up and you lose it. Any screen automation that writes needs a way to check before it retries, usually by putting a reference it controls into a field it can later search on. If the target system has no such field, that is a reason to question the approach, not a detail to solve later.

Screen automation is the right choice in narrower circumstances than it is usually sold for: modest volume, a system due to be replaced within a year or two, and a vendor who will not offer anything better. There it is a sensible bridge, and it should be built as one.

Build the integration to be thrown away

Whatever method you choose, the rest of your software should not know about it. Your order system should call something that means “create this order in the stock system”, and only one component behind that call should know it is really a CSV drop, a database query or a bot filling in a form.

That boundary is cheap to build at the start and expensive to retrofit. When the vendor finally ships an API, or the business moves to a new system, one component is replaced and nothing else changes. Without it, the workaround spreads through the codebase and becomes permanent.

The other thing to build on the first day is reconciliation. Every no-API integration fails silently at some point: a file that never arrived, a row the import rejected without saying so, a bot stopped at a dialogue nobody expected. A daily check that counts what was sent against what arrived, and alerts a named person when the two differ, turns a silent failure into a same-day fix.

Check the contract before the code

Some of these routes may not be yours to take. Software licences and portal terms commonly restrict direct database access, reverse engineering and automated use, and a vendor can decline to support a system whose data has been changed outside the application. Read the licence before designing around the database, and ask the vendor in writing where the terms are unclear. The same goes for a customer’s or supplier’s portal: automating a system you do not own is governed by their terms, not just by the fact that you have a login.

Upgrades belong in the same conversation. An undocumented table or an unadvertised endpoint can change in any release. Knowing when upgrades happen, and having a test that runs against the new version before it reaches production, is part of the integration rather than an extra.

The question worth asking first

Ask what happens to the business if this integration is down for a day. If the answer is a late report, the cheapest robust route will do. If the answer is orders not reaching the warehouse, it deserves a supported route even if that means a difficult conversation with the vendor, and screen automation should be the bridge to it rather than the destination.

Common questions

Written by the Voxalone team. If this raised a question about your own systems, get in touch — you will get a straight answer from an engineer, with no obligation attached.