How to connect two systems with no shared API - CRM, warehouse, accounting

Two systems with no shared API can usually be connected anyway - through file export and import, reading the database directly, or browser automation. The lack of an official API makes integration harder but rarely impossible; the key is checking what a given program actually exposes and building a bridge for that specific case. Most often none of the systems needs to be replaced.

Below: what “no API” actually means, the proven ways to connect, a real example of a flow, and what to take care of so the integration is stable.

What “no API” means and why it’s not the end of the road

An API is a program’s official “socket” - the way it lets other systems read and write data in an orderly manner. When a program has an API, integration is simple. When it doesn’t, you have to enter through a different door. And there’s almost always one, because the data is somewhere: in files the program can export, or in the database it runs on.

In other words: “our programs have no API” isn’t a verdict, it’s information that the bridge has to be built differently than usual.

Ways to connect without an API

In practice you use a few routes, chosen to fit what the system exposes:

• File export and import (CSV, XML). The most common route. Program A exports data, a script processes it and pushes it into program B. It works anywhere systems can read and write files - and almost every one can.
• Reading the database directly. If the program runs on a database you can access, data can be read from it (and sometimes written) without going through the interface.
• Browser automation. A script clicks in the program’s panel exactly as a person would - logs in, opens a tab, pulls or enters data. It rescues situations where the only entrance is the interface.
• Scraping your own panel. Reading data from the system’s views that you have access to. It’s the daily work of integrations and automation - connecting things that “can’t be connected”.

Example: CRM, warehouse and accounting

A typical flow in a small company looks like this: an order lands in the CRM, someone retypes it into the warehouse to issue a dispatch document, then once more into accounting for an invoice. The same data three times, three chances for a mistake.

After integration, an order saved in the CRM creates the dispatch document in the warehouse on its own and passes the data to accounting. Nobody retypes anything, stock levels don’t drift, and the invoice comes from the same data, not a copy of a copy. None of the three programs was replaced - we added a bridge between them.

What to take care of so the integration is stable

Integrations without an API can be more sensitive to changes in the programs - which is why how they’re built matters:

• Error handling and logs. Every flow leaves a trace, so you can check what happened and when - and undo it if needed.
• Handling unusual data. An empty field, an odd character, a different format - the bridge has to catch it, not quietly pass it through.
• Visible failure. Better for the integration to stop and report a problem than to quietly corrupt data for a week.

That’s the difference between “works on my machine” and something you can rely on.

Summary

The lack of a shared API doesn’t mean two systems can’t be connected - it means the bridge has to be built another way: through files, the database or interface automation. Most often without replacing programs, but with error handling so the whole thing is stable. The result: data flows on its own, and you stop retyping it.

If you have two programs you handle by hand today - tell us what you retype and from where to where. We’ll check how to connect them and for how much. No obligation.