Why integrations fail before the API is even written

When an integration between a CRM and an ERP goes wrong, the post-mortem usually points at the code: a timeout, a missing field, a webhook that fired twice. Those are real. But in most projects we're asked to rescue, the failure was locked in weeks earlier — in a meeting where nobody wrote down who owns the customer record.

Ownership comes first

Every shared entity — customer, product, order, price, stock level — needs exactly one system of record. Other systems may cache it, display it or enrich it, but only one system is allowed to decide what's true. Without that decision, two systems will eventually disagree, and the integration will faithfully copy the disagreement back and forth.

• Which system creates the record?
• Which system is allowed to change each field?
• What happens when an update arrives for a record that was changed locally?
• How are deletions represented — or are they never propagated?

Design for the API you don't control

Third-party APIs are slow sometimes, down occasionally, and inconsistent more often than their documentation admits. An integration that assumes success will lose data the first time a supplier returns an error at 2 a.m.

• Put a queue between your system and theirs so work survives outages.
• Make every write idempotent, so retries can't create duplicates.
• Set explicit timeouts and decide what the user sees when they're hit.
• Store the raw payload you received, so you can replay and debug.

Make failure visible

The most expensive integration failures are silent. Build a small operational view from day one: messages processed, messages failed, the oldest unprocessed item, and a way for a non-engineer to retry a failed record. It costs little and turns an incident into a routine task.

Good integrations are mostly agreements — about ownership, failure and visibility. The API calls are the easy part.