Most ERP integration problems are not about the API. They are about what happens on the third failure at 2am, whether anyone finds out, and whether a partial load left the system in a state somebody has to unpick by hand.
What this covers
- Order, item and pricing flows between an ERP and the systems either side of it — CRM, e-commerce, warehouse, finance.
- Bulk maintenance that goes out through an export and comes back through an import. Reshaping one export into several differently-formatted files by hand works, takes a long time, and fails in the worst possible way: halfway through a load, leaving a partial mess behind.
- Loading tooling that refuses to half-finish. Validate everything, then commit, so a mistyped identifier is a rejected row rather than a partial state.
- Retries, circuit breakers and monitoring as part of the build rather than as a later addition.
The constraint that shapes all of it
The schema usually belongs to the vendor. That makes supportability a question you answer before a technical one, and it is why the integration sits alongside the ERP rather than inside it wherever that is possible.
See it in detail
The integration showcase has production-shaped code for these patterns across Salesforce, HubSpot, Zoho, Epicor P21 and Kinetic, Infor and Dynamics NAV. Prophet 21 and Kinetic covers the platform-specific traps.
Who this is for
Distributors and manufacturers where the ERP is the system of record and something else — a CRM, a webstore, a WMS, a trading partner — needs the same data and currently gets it from a file. Usually there is already an integration; the question is whether anyone would know the night it stops.
It is the wrong service if the two systems do not yet agree on what a customer or an item is. That is definition work, and doing it after the integration is built means building it twice.
What we would look at first
- What happens on a failure today. Not what the runbook says — what happened the last time, and who found out first.
- Whether a partial load is possible. If a run can stop halfway and leave rows behind, that is the finding, and it usually predates every other symptom.
- How identity is resolved between the two systems, and what the code does when the match is missing rather than wrong.
- What the vendor supports. Whether there is a supported extension point, and what an upgrade does to anything that does not use one.
What determines the cost
How many systems have to agree, and whether any of them is a system of record for the same field. Whether the identity mapping already exists or has to be established. Whether the work can sit alongside the ERP or has to reach inside it — the second is more expensive to support for years, which is a decision made early and in the open. And whether there is any monitoring today, because an integration with no alerting is two projects rather than one. The same four variables apply across all of this work.