Connecting two systems that don't talk means making what's recorded in one show up on its own in the other, without anyone copying it by hand. You get there in three ways, from least to most involved: by exporting and importing a file (a CSV), by connecting them through their API, or by putting glue in between (an automation tool like Make, Zapier or n8n, or a small piece of custom software). The rule is to start with the simplest route that solves your case, not the flashiest.
It's worth it when someone types the same data twice —the sale logged in the online shop and again in the accounts, the customer set up in two places—. If the transfer happens once a month and takes five minutes, leave it by hand: automating it costs more to maintain than to do.
What does it mean for two systems to "talk"?
That one passes data to the other without anyone lifting a finger. Today, when two systems don't talk, the bridge is a person: someone looks at one screen and types the same into the other. Connecting them is taking that person out of the middle so the data travels on its own: a sale in the online shop that shows up in the invoicing system, a new CRM customer that gets created in the delivery system too.
It isn't "making the two systems one". It's that the data which already exists in one stops being retyped into the other.
What do you need to know before you start?
Three things, none of them technical:
- What data has to pass, from where to where, and in which direction. Do sales go from the shop to the accounts, or the other way? One direction or both? Sketch it on a napkin before you touch anything.
- How often. "In the moment" isn't the same as "once a day". The less immediate it needs to be, the simpler and cheaper the bridge.
- Who's in charge. If the same customer lives in both systems, one has to be the source of truth and the other obey. If you don't decide it, chaos will: two versions of the same data fighting each other.
With that clear, look at what door each system offers: whether it has an API (the good route), whether it at least lets you export to CSV, or whether it offers nothing.
How do you do it, step by step?
Six steps, in this order:
- Define the data and the direction. Which specific field travels (the order, the contact, the invoice), from which system to which. Just one to start, in one direction.
- Look at each system's door. Search its help for "API", "integrations", "webhooks" or "export". That word tells you where you'll get in and out.
- Pick the simplest method that works. If exporting a CSV each night is enough, start there. Only move up to an API or an automation tool if the case demands it.
- Build the bridge. With an automation tool (Make, Zapier, n8n) if both have a connector; with a small piece of custom software if the case is specific or the volume is high.
- Test with a few records. Send three, not three thousand. Check they arrive correctly and, above all, that they don't duplicate when the send repeats.
- Set an alert for when it fails. An automatic bridge fails one day —a key that expires, a format that changes—. Have it warn you, rather than go quiet and stop passing data without anyone noticing.
The step people skip is the sixth, and it's the one that separates a serious bridge from a time bomb. A bridge that fails silently is worse than no bridge: you think the data is passing and it's been a week since it did.
Which method do I choose?
It depends on what door each system has and how much data you move. From least to most:
| Method | When to use it | Cost | Maintenance |
|---|---|---|---|
| Export/import CSV | One or both systems have no API; the transfer can go in batches (each night) | Almost nil | Watch duplicates and formats by hand |
| Automation tool (Make/Zapier/n8n) | Both have a connector; low to medium volume; simple rules | Monthly fee by volume | Low, but tied to the platform |
| Custom software (talks to the APIs) | Specific case, high volume, particular business rules | Higher up front | Yours; no fees or third-party limits |
There's no "best" method. There's the simplest one that solves your case today. Starting with a nightly CSV and moving up to an API when you genuinely need to is almost always cheaper than building the perfect integration from the start.
How much does it cost and how long does it take?
A simple bridge between two systems with connectors is set up in a day or two with an automation tool, and the cost is the platform's monthly fee. A custom bridge between two APIs takes longer —from days to a couple of weeks depending on the fields and the rules— but then it pays no fee and doesn't depend on a third party maintaining the connector.
What you save is measured in the usual sum: if someone types the same data twice for thirty minutes a day, that's over two hours a week gone, plus the copy-by-hand errors that stop turning up on the invoice.
When is it NOT worth it?
- When the transfer is occasional. Once a month, five minutes: doing it by hand works out better than building and maintaining a bridge.
- When one of the two systems is about to disappear. If you're about to change your invoicing software, don't invest in connecting the one you're going to throw away.
- When no one has decided who's in charge. If both systems can edit the same data and there's no source of truth, connecting them multiplies the mess instead of fixing it. Decide that first; connect second.
What mistakes do people usually make?
Almost all of them come from wanting total integration from minute one.
- Connecting everything at once. Ten fields in both directions. When something fails, you don't know which of the ten. One field, one direction, and grow from there.
- Not controlling duplicates. If the bridge resends what it already sent, you end up with every invoice in triplicate. Each record needs a mark that says "this one already passed".
- Depending on the screen. Reading a system's data off its screen (scraping) looks like the fast route when there's no API. It's the most fragile: the day they move a button, it breaks. Use it only as a last resort.
- Leaving no failure alert. Already said, but it's the most expensive. A mute bridge that stops working makes you trust data that's been days without updating.
Frequently asked questions
What is an API and why does it matter for connecting systems?
An API is the door a system offers so others can ask it for data or send it data without going through its screen. If both systems have an API, they can be connected in a stable, automatic way. If one doesn't, you fall back to exporting and importing files, which works but is more fragile and needs watching.
Do I need Zapier or Make to connect two applications?
Not always. Those automation tools —or n8n, which you can host yourself— are the fast route when both systems have a connector and volume is low to medium. If the case is very specific, high volume or has its own rules, a small piece of custom software talking directly to both APIs usually works out better, with no fees or third-party limits.
What if one of the systems has no API?
You use whatever it offers: a scheduled CSV export the other one imports, or a file in a shared folder. It's less elegant and you have to watch for duplicates and formats, but it solves most cases. Reading the system's screen is the last resort and the most fragile.
When is it NOT worth connecting two systems?
When the transfer happens once a month in five minutes, when one of the two is about to be retired, or when no one has decided which of the two is in charge of the shared data. In those cases, automating costs more than it saves.
Start with the simplest bridge, not the most elegant
Connecting two systems is taking out the person who types the same data twice. You can do it by file, by API or with an automation tool in between; the good route is the simplest one that solves your case today, not total integration from the start. Define one field, one direction, test with a few records, and grow from there.
Before you connect anything, decide who's in charge of the shared data and leave an alert for when the bridge fails. A bridge that fails silently is worse than none. And if the transfer is occasional, doing it by hand is still the best automation.
Do you have two systems that don't talk?
If someone's typing the same thing into two places, we can look at what door each system offers and tell you whether a simple bridge is enough or your case needs something custom. If simple does the job, I'll tell you and we'll leave it there. Tell me which two systems you want to connect.
See the automation service Let's talk about your case