Your Old System Doesn't Have an API. That's Not the Problem You Think It Is.

Nobody tells us their dispatch board has an API. We'd be surprised if it did. Legacy systems without APIs aren't the exception in logistics, healthcare, field services and manufacturing — they're the norm. The dispatch board, the quoting tool, the intake form, the nightly reconciliation — this is the software that breaks quietly, and it's usually the software nobody thought to make talk to anything else, because ten or fifteen years ago nothing else needed to hear from it.

So if you're staring at a system with no API and wondering if you're the problem, you're not. You're just late to a conversation everyone in your industry is having.

What "no API" actually means, and how each workaround breaks

There's a real menu here, and it's worth knowing all four items on it, because each one fails in a specific and predictable way.

Screen scraping and browser automation read the system the way a person would — by looking at the screen. It works right up until the vendor changes a screen layout, at which point it breaks completely and without warning. You find out when the numbers stop moving.

File drops move data in batches — an export at midnight, a CSV every hour. This is not real-time and never will be. It's fine for a lot of jobs. But a malformed file fails silently: nobody's watching a batch job the way they watch a live connection, so a bad file from Tuesday can sit there for a week before anyone notices the numbers are off.

Database triggers, writing or reading directly against the vendor's own database, can be the most reliable path when you control the infrastructure. It can also be the most dangerous. Many vendor license agreements explicitly prohibit direct database access, and even where they don't, writing data back into a system's own database can corrupt application-layer state that the vendor's software depends on to function. You're not just moving data. You're editing the assumptions the software makes about itself.

RPA band-aids script against a specific user interface — click here, read this field, type that. They work exactly as well as screen scraping and fail for the same reason: the day that UI changes, the script doesn't know, and it keeps clicking on nothing.

All four of these show up hardest on legacy systems, because legacy systems were never built with integration in mind. They were built to run one business process, in one place, and nobody on the original team was thinking about what would need to read from it in 2026.

The cost of the duct tape you already have

Here's the part that doesn't show up on an invoice anywhere, which is exactly why it survives so long. Someone on your team is re-keying data by hand between two systems every day — copying a job number from the CRM into the billing system, or a delivery confirmation from the driver's app into the spreadsheet finance actually trusts. That's the hour your team keeps losing to work that should be automatic, every day, forever, until someone decides it isn't normal anymore.

And somewhere in the building, there's a spreadsheet — the spreadsheet everyone secretly runs the business on — that has quietly become the reconciliation layer nobody officially built and nobody fully trusts. It's not on any architecture diagram. It's just where the truth ends up living because nothing else agrees with itself.

The honest fix: sync that tells you when it's wrong

A properly built integration doesn't eliminate the problems above. It makes them visible and recoverable, which is the whole difference.

Two-way sync with retry logic means a dropped connection doesn't mean a dropped record — the system notices the failed attempt and tries again, instead of quietly losing the update. Reconciliation runs on a schedule, not just at the moment two systems first connect, checking for drift even when everything looks fine on the surface. And when something does fail, the alert names the specific record that failed — not a generic "sync failed" email that tells someone to go check everything. Nobody has time to check everything.

This is what our integrations & data work is actually built to do — APIs where they exist, ETL and webhooks where they don't, with retry and reconciliation built into the design instead of bolted on after the first outage. It's not more exciting than duct tape. It's supposed to be boring. That's the point.

Not everything needs to be integrated

Here's the part most vendors won't say, because it shrinks the invoice: the instinct to wire every tool to every other tool creates more failure points, not fewer. Ten systems all syncing to each other is forty-five possible connections, each with its own way of breaking at 2am.

The better call, more often than people expect, is picking one system as the source of truth and syncing everything else to it — one direction, one owner, one place to look when the number looks wrong. It's less impressive on a slide. It's also cheaper to run and easier to debug at 2am.

We choose boring technology on purpose, and the same logic applies to the integration layer itself: novelty there is a cost paid every year after launch, by you, not by us. We'll say this in the first call, not the third, because a simpler fix is a simpler fix, and there's no version of this business where we make more money by pretending otherwise.

The end state worth building toward: one warehouse, not a tangle of point-to-point syncs

If you keep adding systems the way most companies do — one integration at a time, whenever the pain gets bad enough — you eventually end up with a dozen point-to-point syncs, each with its own failure mode, and nobody who can draw the whole picture on a whiteboard.

The better end state is one warehouse for cross-system reporting: everything feeds one place, and reporting reads from that one place instead of five systems that each claim to have the real number. This matters most for finance and reporting teams, who don't need five sources. They need one number they can defend in a meeting.

What this costs and how long it takes

Integrations & data work starts at $22k and typically runs four to ten weeks, depending on how many systems are involved and how much history needs to move, not just flow forward.

We don't quote that number blind. A discovery week — flat $4,800, credited back in full if you continue — ends in a written scope, an architecture sketch, and a fixed estimate. You're not committing to the project to find out what it costs. You're paying a small, fixed amount to get a real number instead of a guess. After that, billing runs on milestones, net 14. No surprise invoices, no "turns out the estimate was wrong" conversation three weeks in.

When not to bother

If a connector already exists that does the sync you need, the right answer is to say so, not sell you a custom build on top of it. We turn down projects a specialist would do better, or that an existing off-the-shelf product already solves for a tenth of the price. That's not modesty. It's just true, and you'll find out either way — better to hear it from us on the first call than discover it after the invoice.