Modern automation assumes your ERP has an API. Plenty of capable, widely used systems don't: desktop accounting and ERP packages like Sage 50, older Macola and Vantage installs, and countless vertical-market systems that run entire companies from a Windows server in a back room. The standard advice is "replace it," which is a $200K+ answer to a connectivity question. The better answer, most of the time: give the ERP an API it never had, with a small bridge service running next to it. We have exactly this pattern in production today, posting sales orders and invoices into Sage 50 from a modern web application, and this article explains how it works.
Why "No API" Doesn't Mean "No Integration"
Almost every legacy system has at least one of these doors, even without a REST API:
- A vendor SDK. Many desktop ERPs ship a programming interface (often COM-based, Windows-only, sometimes 32-bit) intended for local add-ons. Sage 50's SDK is a good example: full read/write access to customers, orders, and invoices, with the ERP's own validation enforced. It just can't be called from the cloud, or from anything that isn't a Windows process sitting next to the ERP.
- The database. Most legacy ERPs sit on an accessible database (Pervasive/Actian, older SQL Server, Btrieve descendants). Reading it directly is usually safe and fast. Writing to it directly is how you corrupt an ERP: the application's business logic lives above the tables, and bypassing it skips validation the vendor never documented.
- Import/export mechanisms. File-based imports the ERP itself supports. Clunky, but they run through the application's validation, which makes them safer than raw table writes.
The pattern that turns any of these doors into a real integration is the same: a bridge service.
The Bridge Pattern
A bridge is a small service installed on (or next to) the machine that runs the ERP. On one side, it speaks the ERP's native interface: the COM SDK, the local database, the import mechanism. On the other side, it exposes a clean, modern HTTP API: POST /sales-orders, GET /invoices/123. Everything else in your stack (web apps, AI automation, integrations) talks to the bridge like it would talk to any modern system, and never needs to know the ERP predates the cloud.
In our production Sage 50 deployment, the bridge is a compact Windows service wrapping the official SDK. A web application that ingests customer purchase orders with AI extraction posts finished sales orders through the bridge; the bridge writes them through Sage's own API layer, so every order gets the same validation a human entry would. The web app also reads open orders back out for shipping and invoicing workflows. From the automation's point of view, Sage 50 has a REST API. It just happens to be one we built.
What Makes or Breaks a Bridge
The concept is simple. Production-grade is in the details, and these are the ones that matter:
Respect the ERP's session model
Desktop ERPs often license by seat, and an SDK connection can occupy one. The bridge has to manage that seat like the shared resource it is: open the connection when work arrives, release it when idle, and give administrators a way to take the seat back for maintenance without the bridge fighting them for it. A bridge that hogs a license seat makes enemies fast.
Writes go through validation, always
Every write goes through the SDK or the import layer, never raw SQL, no matter how tempting the table looks. The one time direct writes "work" in testing is not evidence; it's a delayed invoice for a corrupted data file. Reads, by contrast, can go straight to the database when the SDK is slow. Legacy SDKs are often slow, so filtered, bounded reads matter. An unfiltered "list all orders" against two decades of history can run for minutes; the bridge should enforce sensible filters by default.
Plan for the ERP being down
Legacy systems get rebooted, backed up, and locked for month-end. The bridge must fail loudly and distinguishably: "ERP unavailable, retry later" is a different condition from "this order is invalid," and everything upstream should treat them differently: one queues and retries, the other goes to a human. Collapsing both into a generic error is how orders silently vanish.
Idempotency
When a network hiccup interrupts a post, the caller will retry. Without a duplicate check keyed on something real (the customer's PO number, an external reference the bridge stores), retries create duplicate orders that get built and shipped twice. This is the single most common flaw in homegrown bridges.
What It Costs, and When to Do It
A production bridge for one ERP (a handful of endpoints, session management, logging, and monitoring) typically runs $15,000-$40,000 depending on the SDK's temperament, and takes 4-8 weeks alongside the integration that uses it. That's against the alternative: a full ERP replacement costing 5-20x that, taking a year, and being justified mostly by the sentence "it has no API."
The honest caveat: a bridge extends a legacy ERP's useful life; it doesn't make the ERP good. If the system is also failing at its actual job (can't handle your volume, vendor is gone, runs on hardware you can't replace), integrate nothing and plan the migration. But if the ERP does its job fine and its only sin is isolation, a bridge buys you modern automation now and makes the eventual migration easier, because by then your workflows already run through clean interfaces that can be repointed.
Uptimize Solutions integrates modern automation with whatever ERP you actually run, including the ones without APIs. If you've been told your system is too old to automate around, see our integration services or book a free workflow audit. Bring the name of the system and we'll tell you which door it has.