My Software Has No API. What Are the Options?

"Our system has no API" is something I hear often, and it is true in about half the cases. In the other half there is an interface - it is simply undocumented, sits behind an unpurchased module, or nobody in the organisation knows about it.

Before building anything, one email is worth spending.

Step 0: verify it is true

Three questions for the vendor, in writing:

1. "Is there any programmatic interface - API, scheduled export, webhooks?" - sometimes the answer surprises.
2. "Is there an add-on module that enables it?" - many established systems sell integration separately. If yes, that is a purchasing decision rather than a technical problem - and it belongs with whoever controls budget, not solved in code.
3. "What is your position on direct database access?" - better asked up front than discovered a year later to void support.

These answers determine which of the options below is even open to you. In writing, because in a year someone will ask.

The options, from durable to fragile

1. Scheduled export to a file

The system can export to CSV or Excel, either on an internal schedule or at the click of a button. You pick up the file and process it.

Why this is the most underrated option: it is boring, it survives version upgrades, and it requires nothing from the vendor. If your need is "a daily report", "stock sync" or "an up-to-date customer list" - and that is most cases - this is the answer and you are done.

What to watch: an export file is a spreadsheet, so it has no types. Dates flip, the leading zero on a phone number disappears, and ID numbers lose digits. Process the file as raw text rather than opening it in Excel on the way.

2. Direct database access

If the system runs on SQL Server or another local database, you can sometimes read from it directly.

Reading - usually acceptable, particularly for reporting and BI. Preferably with a dedicated read-only user.

Writing - almost always a mistake. The application assumes it is the sole owner: it maintains indexes, helper tables, counters and logs. Direct writes bypass all of that and produce data that looks correct and behaves incorrectly - and frequently voids the support contract.

A further trap: a closed system's schema is not a contract. A version upgrade can rename tables and change field meanings without notice, because to the vendor it is internal.

The rule: reading - maybe. Writing - only with written vendor approval.

3. A shared folder or FTP

Many established systems can drop a file into a folder, or pick one up from there. It looks archaic and works well.

What must be in place: a marker file signalling the write finished (otherwise you read a half-written file), moving to an archive after processing rather than deleting, and idempotency - the same file processed twice must not duplicate.

4. UI automation (RPA)

A script that drives the software like a user: opens screens, fills fields, clicks. It works even on old desktop software.

The real cost: it breaks on any interface change - a moved field, a new dialog, a version upgrade. And it breaks silently: the script "ran successfully" while filling the wrong field.

If you choose it, three rules:

• Budget ongoing maintenance, not a one-off project. That is not pessimism - it is the cost.
• Verify the outcome, not completion. After each run, confirm the data actually landed correctly. "The script did not crash" is not success.
• Never unattended on financial operations. A script issuing invoices without oversight is a risk not worth the saving.

5. Screen scraping a web interface

If the system is web-based, you can read from it as a browser would. Technically this extends web scraping to an internal system.

Before touching it: check the terms of use and the vendor agreement. An internal system you pay for is different from a public site, but it is not unrestricted - the agreement may explicitly prohibit automated access. And if it is a third-party system holding customer data, there are privacy considerations too. This is not a technical judgement, it is a contractual one, and with an external vendor it is worth asking a lawyer.

How to choose

That last row matters: if the requirement is real-time and there is no API, none of these options genuinely meets it. You can poll every minute, but that is fragile and expensive. In that case it is better to put the choice to the business explicitly - buy an integration module, soften the requirement, or change systems - rather than build something that will break.

What holds across all options

• Idempotency. The same file or record processed twice produces one result.
• An error queue a human sees. A failed record must appear somewhere someone checks each morning.
• A daily reconciliation job. Compare counts and totals across both sides. With fragile solutions this is not a luxury - it is the only way to know something broke before the business finds out.
• Document the assumptions. File structure, field names, button positions. When it breaks - and it will - whoever fixes it needs to know what was assumed.

The question worth asking at the end

Before building RPA or scraping: what is this automation worth per year, and what does it cost to maintain?

If someone types thirty records a month, that is five minutes a day. An RPA script that breaks once a quarter and takes half a day to fix costs more than the manual work - and adds the silent risk of data entered incorrectly.

Automation pays off when volume justifies it or when the manual delay costs money. Otherwise the honest answer is that it is not worth it - and it is fine to say so.