How to integrate a system that has no API.

A client wants their booking system, their warehouse software or their accounting package connected to something else. You look for the API and there is not one, or there is one and it costs more than the project, or it exists and covers everything except the operation you need.

This is common, and it is not automatically a dead end. There are five workable approaches, and the skill is choosing the one that matches how much the client can tolerate breaking.

Check whether the API really does not exist.

Before designing around the absence, rule out four things.

The vendor may have an API on a higher plan. This is worth pricing, because an upgrade is frequently cheaper than the workaround and considerably cheaper than maintaining one.

There may be an undocumented API. Many web applications are a front end talking to a private JSON endpoint. You can see it in the browser network tab. Using it is possible, sometimes tolerated, and always fragile, because it can change without notice and may breach the terms of service. Read those terms before you build on it.

There may be a partner or integration programme that grants access on request. Ask. It takes an email.

And there may be an existing connector through an iPaaS vendor. If Zapier, Make or n8n already ships a node for that system, somebody has solved the auth problem and it may be sufficient on its own.

The five approaches, in the order you should prefer them.

Approach	Works when	Fails when
Scheduled file exchange	The system can export on a schedule to SFTP or storage	You need anything close to real time
Email parsing	The system already emails notifications or reports	The template changes, or the format is inconsistent
Direct database access	It is self-hosted and the client owns the database	It is vendor-hosted, or writes would corrupt state
Undocumented internal API	The web app is well structured and auth is obtainable	The vendor ships a change, which they will
Browser automation	Nothing else is available at all	Anything at all changes on the page

Prefer the top of that table. Each step down increases the chance that a UI change three months from now silently breaks a system your client depends on.

Scheduled file exchange is boring and usually right.

A nightly CSV to SFTP is unglamorous and it survives. Most business systems can export on a schedule even when they cannot integrate, and the format tends to be stable because customers depend on it.

Three details make the difference between this working and this quietly rotting.

Detect no file

A missing export is the most common failure and the least visible one. If the file did not arrive by the expected time, that must raise an alert. Without this the client discovers the problem weeks later through missing data.

Verify completeness

A truncated or partially written file will parse happily and import half a day of records. Check the row count against a manifest where one is available, or at minimum against a plausible range, and refuse to process a file that looks wrong.

Process once

Move or rename each file after processing. Reprocessing yesterday’s export because it was still sitting in the directory is how duplicate records get created at scale.

Email parsing works better than it deserves to.

If the system already sends a notification email for the event you care about, that email is a usable trigger. Route a copy to a dedicated address the workflow monitors.

Parse structure, not prose. Anchor on labels and table cells rather than on word positions, so a wording change does not break extraction. Where the useful data is in an attachment, take it from the attachment rather than the body.

Then assume the template will change, because it will. Validate every extracted field, and treat a field that suddenly fails to extract as an alert rather than as an empty value to write onward. Silently writing blanks over good data is the failure that turns a template change into data loss.

Direct database access, only with real ownership.

If the client self-hosts and genuinely owns the database, reading from it directly is fast and reliable. Read from a replica where one exists so you cannot affect the application’s performance.

Writing is a different question and the answer is usually no. Applications enforce rules in code that the schema does not express: derived fields, audit rows, cache invalidation, search indexes. Writing behind the application produces records that look correct in the database and behave incorrectly in the product. Read directly, write through whatever interface the application does provide, even if that interface is worse.

Browser automation is the last option, and it is a commitment.

Driving the interface with a headless browser does work, and sometimes it is genuinely the only route. Go in with the cost understood.

It breaks when a selector changes, when a modal is added, when a login flow introduces a verification step, when the page is slow. It usually cannot run unattended for long without maintenance, and multi-factor authentication can end the approach entirely.

If you build it, isolate it: a small service that does the browser work and exposes a clean interface to the rest of the workflow, so that when the vendor finally ships an API you replace one component rather than unpicking the integration. Tell the client in writing that this approach carries ongoing maintenance, and price that maintenance rather than absorbing it.

Say which approach you chose, and why.

Whichever route you take, write down what you used, what would break it and what the replacement path is. A future developer looking at a nightly CSV import needs to know it exists because the vendor has no API, not because somebody preferred CSVs.

If a client system has no usable API and you are weighing which of these is worth quoting, send us what the system is and what needs to move. We will tell you which approach we would take and what it would cost to keep running. Send us the details.