The systems you already pay for, finally agreeing with each other.
Your ERP, your CRM, your webshop and the spreadsheet somebody built to cover the gap between them. We connect what you already run so a record gets entered once and the rest keeps up, instead of somebody retyping it into the next screen by hand.
What this is
System integration is making two or more systems that were never built to know about each other agree on the same facts: the same customer, the same order, the same stock count, without a person carrying the number between them. It is not a process with a decision in the middle, that is workflow automation, and the two pages are worth reading separately if you are not sure which one you need. This is closer to plumbing: continuous or scheduled agreement between systems that each already do their own job well.
The API call is rarely the hard part. The hard part is that system A's idea of a customer is a single name field with no duplicate check, and system B needs a first name, a last name and a tax ID, and rejects a duplicate silently on a bad day. Getting two systems to agree means naming a single source of truth for each field, building a mapping table because most vendor systems do not share a common ID, and deciding on purpose what happens when a record was edited in both systems since the last sync, rather than letting whichever one ran last quietly win.
We build read-only first: pull data into a shadow copy, compare it against both systems by eye, and only turn on writes once the mapping has survived a few days of real traffic. A write bug in an integration can corrupt a record in a system somebody is using right now to invoice a customer; a read bug corrupts nothing. Rate limits, pagination and a vendor changing their API without much warning are the normal week, and the sync gets an error queue and alerting from day one so a broken mapping is a ticket, not a customer noticing their order never arrived.
What you get
Field mapping
Every field either system stores for the record in question, with the source of truth named for each one, written down and not just implemented.
The sync mechanism
Webhook-driven where the vendor supports it, polled on a schedule where it doesn't, sized to the vendor's rate limit rather than hammering it.
A record-matching table
Linking a record in one system to its counterpart in the other, since most vendor systems share no common ID and matching by name alone attaches invoices to the wrong customer.
Reconciliation logic
An explicit answer for what happens when a record changed in both systems since the last sync, decided on purpose rather than last write wins by accident.
An error queue
Records that fail to map are held and flagged for a person, not dropped and not retried forever into something worse.
Monitoring and alerting
A sync that silently stops is worse than one that never ran, so somebody is told before a customer is.
A read-only validation phase
Days of comparing the shadow copy against both systems before a single write happens, so the cutover to live sync is a decision made on purpose.
The source and the mapping documentation
Handed over so the sync can be maintained, audited or extended by someone who was not in the room when it was built.
When this fits, and when it does not
A good fit
- You're paying for two or more systems that each need the same record, a customer, an order, a stock count, and today a person keeps them in agreement by hand.
- One of the systems is already the one you trust for a given fact, stock level, price, customer status, and you need the others to follow it instead of arguing with it.
- You've been burned by a CSV export that's a day stale by the time anyone reads it, or a spreadsheet that is quietly the real source of truth nobody admits to.
- The systems involved have an API, even an awkward or undocumented one. If neither does, that's a different and uglier project and we will say so before starting.
- The volume is high enough that a mistyped or missed record matters: a hundred orders a day is where a typo turns into a chargeback rather than an apology.
Not a good fit
- The job is one vendor API wired into software you already own, in one direction, and no second business system has to be kept in step. That is the narrower case and it has its own page: API integration.
- If what you need is a decision or approval routed through people before anything happens, that is workflow automation rather than this.
- There is no second system yet, you need one stood up in the first place. That is ERP implementation, and this page assumes the systems being connected already exist.
- The two systems between them cover under about a hundred records a month. Exporting and importing by hand is faster to build than an integration, and nobody should be embarrassed to just do that.
- One side has no API and no plan to get one, which some older accounting software genuinely doesn't. The honest answer there is a fragile UI-automation workaround, and we'll tell you that's what it takes rather than pretend otherwise.
- You want one unified database that replaces both systems rather than connecting them. That's closer to internal tools or a migration, and a different conversation.
How it runs
- 01
Read both sides
Every field either system stores for the record in question, and which one is correct when they disagree. This is where the project turns out simple or turns out to need real thought.
- 02
Map and match
A field mapping and a record-matching key between the two systems, written down before any sync code exists.
- 03
Build read-only first
Pull data into a shadow copy and check it against both systems by eye, so a mapping mistake is caught before it can write anything.
- 04
Turn on writes
With the error queue and alerting already running, not added after the first incident proves they were needed.
- 05
Hand over
Mapping documentation, credentials and the source, so the sync keeps running once we are no longer the ones watching it.
Questions we get
What happens when a record exists in both systems but they disagree?
We answer that before writing any sync code, not after it corrupts something. One field usually has an obvious source of truth, stock count lives in the ERP, not the webshop. Where it genuinely doesn't, the conflict goes to a queue for a person instead of getting resolved by whichever system happened to sync last.
Do both systems need proper APIs?
They need some API, even a rough one. A vendor with only CSV export and no webhooks is still workable, just on a schedule instead of in real time. No API at all turns this into UI automation, which we will say plainly before starting, because it is a more fragile kind of project and priced differently.
Real-time or scheduled sync?
Webhook-driven where the vendor supports it and the volume justifies watching for live events; a scheduled pull, usually minutes to an hour apart, where it doesn't. Real time sounds better in a meeting than it is usually worth for data that a person only checks once a day anyway.
Can you connect to the specific platform we use?
Probably. Name it in the first conversation and we'll tell you plainly whether we've worked with that API before or would be reading its documentation cold, and the timeline reflects the difference honestly rather than after the fact.
More automation
Retyping the same record into a second system?
Tell us which two systems and what a customer, order or invoice looks like in each. An engineer reads it and gives you a straight answer on whether an integration is worth building.