The system everything else has to go around
You want your website orders to go into the stock system. You want the CRM to show a customer's account balance. You want a report that pulls from two places. Every conversation ends at the same point: the old system has no API.
So people bridge the gap. Someone exports a CSV every morning and uploads it somewhere else. Someone reads a screen and types what they see into another screen. Integration projects get quoted, then abandoned, because the supplier said there is no way in, or wanted a large fee to build one.
Why no API does not mean no way in
An API is only one kind of door. Almost every business system stores its data somewhere, reads files from somewhere, or draws screens that a program can operate. Each of those is a way in, with different trade-offs.
| Route | How it works | Watch out for |
|---|---|---|
| Database access | Read, and carefully write, the system's own database | Undocumented tables, rules enforced only in the app |
| File import and export | Use the CSV, XML or EDI files the system already supports | Timing, file formats, partial loads |
| Reporting views | Read from the reporting layer or ODBC connection | Often read-only |
| Screen automation | A program drives the screens like a person would | Fragile if screens change, slower |
| Email or print output | Capture documents the system already sends | One direction only |
The reason these routes get dismissed is usually risk, and that concern is fair. Writing into another program's database without understanding it can corrupt data. The answer is to understand it first, and to prefer read access wherever possible.
What living without a connection costs
- Daily exports and imports that someone has to remember
- Retyping between the old system and newer tools, with the errors that brings
- Data in other systems that is always a day old
- New projects blocked because they cannot reach the core data
- Pressure to replace the whole system just to connect it, when the rest of it works
That last one matters. Plenty of old systems do their core job perfectly well. Replacing them only because they cannot connect is an expensive answer to a narrower problem.
Manual bridging also hides errors. When a CSV import half fails, or someone copies a figure from the wrong row, nothing flags it. The mistake surfaces later as a customer query or a stock count that does not add up.
How we build the way in
- Investigation. We look at how the system stores data, what import and export options exist, what the licence permits and whether the vendor offers anything undocumented.
- Read path first. Most value comes from reading the data. We set up a read-only connection or a scheduled export, and map the tables or files to clear business objects like customer, order and product.
- Write path with care. If data needs to go in, we prefer the system's own import routine, because it applies the system's rules. Direct database writes are used only when we fully understand the tables involved and can test against a copy.
- Wrapper API. We put a small API of our own in front of whichever route works, so the website, CRM or automation tools talk to something modern and documented.
- Change detection. We track what changed since the last read, so other systems get updates without full reloads.
- Safeguards. Logging, validation before any write, and alerts when the route breaks, for example after a vendor update.
Screen automation is our last choice, not our first. It works, but it breaks when screens change, so we use it only when nothing sturdier is available.
What you get
The old system stays, doing what it is good at. Around it, your other tools finally see its data. The website checks live stock. The CRM shows account balances. The morning export job disappears because the connection runs on its own.
And if you do eventually replace the old system, the wrapper API means the tools around it do not all need to change at once. You swap what sits behind the API.
Sound familiar?
- A key system has no API and the vendor cannot or will not add one
- Someone exports and imports files between systems every day
- Staff read one screen and type into another
- Integration ideas get dropped because the old system cannot connect
- You are being told to replace a system that otherwise works fine