An order comes in cleanly, the ERP accepts it, the webshop confirms it, and the warehouse sees it. Everything looks fine. Then one day a catalog update changes a field, an order gets blocked, and nobody knows whether the transaction is pending, cancelled, or duplicated.
Integrating systems is not about making them talk; it is about deciding who decides when they disagree.
That is the point many companies discover too late. API integration is usually sold as a technical project, but in practice it is an operational decision: which system is the source of truth, which errors are acceptable, what gets retried automatically, and what must be escalated to a person.
The usual failure: integration without an operating contract
The most common mistake is to think in endpoints instead of rules. The data flow is designed, but basic questions are never answered:
- Which system owns stock, pricing, orders, and customer records?
- What happens if the ERP responds slowly or returns a partial error?
- What validations happen before creating a record?
- How do you detect duplicates, format changes, or missing fields?
- Who gets alerted, and how quickly must they act?
Without answers, the integration becomes a chain of patches. Sales sees one status, operations sees another, and support ends up doing manual reconciliation.
The thesis is straightforward: a useful integration is not the one that moves the most events per minute, but the one that reduces operational exceptions and reveals failure before the customer feels it.
What must be decided before building
There are three decisions worth closing before a single line of code is written:
- Source of truth by object: saying “the ERP is the master” is not enough. Specify whether it owns stock, pricing, addresses, tax, availability, or order status.
- Error policy: a validation error should not be handled like a timeout. Some failures should queue, others should fail fast, and others should go to human review.
- Minimum observability: every integration needs traceability by order or transaction ID, message status, timestamp, root cause, and owner.
If this is not documented, the project becomes too dependent on the developer who built it. That is fragile.
A practical test: if the company cannot explain what happens to a failed order without opening the code, the integration is not mature yet.
Mini case: when it “worked” but was not operable
A mid-sized distribution company sold through ecommerce and managed orders in an ERP. The integration worked in the strict sense: orders arrived. But when shipping address validation failed, the system did not distinguish between a recoverable issue and a permanent one.
The result: some orders stayed in an ambiguous state for hours. Operations manually reviewed dozens of cases a day. Sales promised delivery dates the warehouse could not meet. And every minor outage triggered a long email chain.
The fix was not to “make the integration more robust” in the abstract. It was to introduce concrete rules:
- automatic rejection of incomplete addresses,
- a queue for temporary ERP incidents,
- alerts only for non-retriable errors,
- a status panel by error type,
- and one operational owner per exception.
The volume barely changed. The difference was that exceptions stopped being mysterious.
The uncomfortable decision: sometimes less automation is better
Here is the unpopular part: not everything should be automated end to end.
In critical integrations, automating 95% and leaving the delicate 5% for human review can be better than forcing full automation. This is especially true for:
- high-value orders,
- address changes after payment,
- customers with special commercial terms,
- inventory with high stockout risk,
- and flows affecting tax or invoicing.
The uncomfortable decision is admitting that apparent efficiency can hide operational risk. The question is not “can we automate it?” but “what is the cost of being wrong here?”
Signs the integration is actually mature
You do not need a huge platform to know whether an integration is healthy. These signals help:
- errors are categorized and owned,
- retries are limited and traceable,
- critical data is validated before entering the ERP,
- incidents are resolved with an internal SLA,
- and operations can see status without depending on the technical team.
There is also a very clear negative signal: if every incident ends with “restart the connector” or “run the job again,” the system is built to survive, not to operate.
The best API integration is not the most elegant one technically; it is the one that reduces invisible work in reconciliation, follow-up, and manual correction.
In projects like this, Codefuente usually starts with the operating contract before the implementation, because that is where the difference between real support for the business and another layer of complexity is decided.