Quick checklist
- Does the software you already pay for have an API?
- Which system should own each piece of information?
- What should happen when the connection fails?
- Is the sync one way or both ways?
- Who notices if it quietly stops working?
You’ve probably been told that two pieces of software “can integrate”, or that something “has an API”. Both statements are usually true and neither tells you much.
Here’s the version that’s actually useful when you’re deciding whether to spend money.
What an API is
An API is a door that software leaves open for other software.
Your accounting package has screens for people. It also has a set of instructions other programs can use — give me all invoices from March, create a new customer with these details, tell me when this one gets paid. That set of instructions is the API.
It’s the difference between a shop with a counter and a shop with a loading dock. Same goods, different entrance, designed for a different kind of customer.
When someone says two systems can talk to each other, they mean one of them has a loading dock and the other knows how to reverse up to it.
Why it matters more than it sounds
Almost every “our systems don’t talk to each other” problem is an integration problem, and almost every integration problem shows up as a person retyping something.
The customer’s details in the quote, then in the job, then in the invoice, then in the accounts. Four entries, one piece of information, three chances to get it wrong. That’s not a software limitation — the door was there the whole time, nobody had walked through it.
The four ways things get connected
Roughly in order of cost and robustness.
1. It’s built in already. The two products have a supported integration you switch on. Always check for this first. It’s free, someone else maintains it, and people regularly pay to build what was included.
2. A connector service. Tools like these sit between two systems and pass information across based on rules you configure. Cheap, quick, no development. They suit simple flows — when this happens, put that there — and get expensive or fragile once the logic gets complicated.
3. A custom integration. Purpose-built code that talks to both APIs. More expensive up front, and the right answer when the rules are specific to how you work, when the data needs transforming on the way through, or when the volume is high enough that reliability matters.
4. Files, as a last resort. One system exports, another imports, on a schedule. Unglamorous and still genuinely common, because some software has no API at all. Works. Fails quietly. Use it when there’s nothing better.
The decision people skip
Before connecting anything, decide which system owns each piece of information.
If a customer’s phone number can be changed in two places, you will eventually have two different phone numbers and no way to tell which is right. This is by far the most common cause of integration projects going wrong, and it’s a business decision rather than a technical one — no developer can make it for you.
Usually the answer is: one system is the source of truth for each thing, and the others receive a copy. Two-way syncing is possible and it’s roughly twice the work, plus a set of rules about what happens when both sides change at once.
What goes wrong
It stops and nobody notices. The API changes, a password expires, a rate limit is hit. Information stops flowing and everything looks normal for a fortnight. Any integration worth building includes something that complains loudly when it fails.
Rate limits. Most APIs cap how often you can knock. Fine day to day; a problem the first time you try to move five years of history through the same door.
Vendor changes. APIs get versioned and old versions get switched off, usually with notice. This is the main reason an integration is something you maintain rather than something you finish.
Half a record. The customer was created, then the job failed. Now there’s a customer with no reason to exist. Good integrations handle this deliberately; quick ones tend not to.
The data doesn’t match. One system’s “customer” is a person, the other’s is a company. One requires a postcode, the other doesn’t. Most of the real work in an integration is this translation, not the connecting.
Questions worth asking before you buy
- Does it have an API, and is it included in my plan? Some vendors charge extra, or reserve it for higher tiers.
- Is there a supported integration with the other things I use?
- Can I get my data out in bulk if I leave?
- How are changes to the API communicated?
That last one matters more than people expect. A vendor who breaks their API without warning will cost you more over time than one whose software is slightly less good.
The honest summary
An integration is not a switch. It’s a small piece of software that runs continuously, depends on two systems it doesn’t control, and needs someone to notice when it breaks.
That’s not a reason to avoid them — the retyping they remove is real, permanent and compounds. It’s a reason to build them properly and to know who’s looking after them afterwards, which is one of the things an ongoing technology partnership is for.
And before any of it: check whether the connection you need already exists and is sitting switched off. It happens more often than you’d think.
Bottom line
An integration is a small piece of software that needs looking after, not a switch you flip once. Decide which system owns each piece of information before you connect anything.
Want a hand with this?
Tell us what you're trying to sort out and we'll give you practical, plain-English advice before you spend money.
