Integrations: How to Connect Your Website, CRM, Warehouse and Accounting
Integrations are the most common reason a project goes over budget. In the quote they are one line, but behind that line sits work whose scope cannot be estimated until somebody looks at what the other system actually gives you.
Here is what connecting systems consists of, which options exist, and what breaks most often.
What an integration really is
It is an agreement between two systems about who passes what, when, and in what form. The technical part is usually simple. The hard parts are elsewhere:
- Different reference data. On the website a product is “Oak dining table”, in the warehouse it is “TB-OAK-120”, in accounting it is “Table dining oak 120×80”. These cannot be matched automatically until somebody maps them by hand.
- Different notions of status. “Paid” on the site and “paid” in accounting often refer to different moments.
- Different sources of truth. If a price can be changed both on the site and in the warehouse system, sooner or later they will diverge.
So the first question in any integration is not technical: which system is authoritative for each kind of data.
Three ways to connect
| Method | How it works | When it fits |
|---|---|---|
| Direct API exchange | The systems call each other directly | Both sides have a documented interface |
| Webhooks | An event in one system immediately pushes data to the other | A real-time reaction is required |
| File exchange | Scheduled export, the other system collects it | Legacy system with no API, large volumes |
| Via a middleware layer | A separate layer reconciles formats and rules | More than two systems, different reference data |
The last option looks excessive while there are only two systems. With three or more it turns out cheaper: without it every pair connects separately, and the number of connections grows faster than the number of systems.
Direction and frequency
Two characteristics that determine complexity more than anything else.
Direction. One-way exchange is several times simpler. Two-way requires resolving conflicts: what to do when a record was changed in both systems at once. A practical rule: build two-way exchange only where you genuinely cannot avoid it.
Frequency. Real time is needed less often than people assume. Stock levels, yes. Reporting data, once a day is entirely sufficient. Every increase in frequency raises the load and the number of places something can break.
What breaks
| Problem | How it shows up | What helps |
|---|---|---|
| The other system is unavailable | An order never reached the CRM and vanished | A queue with retries |
| Duplication | One lead created three times | A unique operation key |
| Reference data mismatch | Products fail to match | A mapping table, maintained by a person |
| Silent failure | The exchange died a week ago and nobody noticed | Alerts on failure, not just logs |
| A change on the other side | The supplier changed the format without notice | Validating the data structure on arrival |
| Partial transfer | The order went through, stock was never deducted | All-or-nothing operations |
The most expensive row here is silent failure. An integration that died unnoticed is worse than no integration: the data diverges, and it surfaces weeks later, when reconciliation has to be done by hand.
Implementation sequence
- Describe what is transferred. A field list from both sides, not “we will sync orders”.
- Decide the authoritative system for each data type. That is a business decision, not a developer’s.
- Map the reference data. Tedious manual work that cannot be skipped.
- Launch one-way and at small volume. Ten orders a day, not the whole flow.
- Add failure alerts. Before opening the full volume.
- Expand gradually. Second direction, second system, higher frequency.
What to ask your supplier first
- What happens to an enquiry if the CRM is down at the moment of submission?
- How will we learn the exchange has broken, and how quickly?
- Who maintains the mapping table when a new product appears?
- What happens if the supplier changes the data format?
- Can an operation that failed to arrive be resent?
- Where is the exchange history stored and for how long?
The answers to these six questions separate an integration that runs for years from one that needs repairing every month.
What it actually costs
A benchmark: simple one-way transfer of enquiries from a site into a CRM is a few days. Two-way exchange of products and stock with an undocumented legacy warehouse system is weeks, and cannot be estimated precisely before starting.
So an honest quote for integration almost always has two phases: first a discovery in which someone looks at what the other system really provides, then an estimate. A proposal that prices a complex integration immediately and precisely usually means nobody looked.
Integrations are rarely elegant. But they are what turns a website from a shop window into part of the working process, and they are exactly what gets cut from budgets, after which people reconcile data by hand for another three years.
