When two systems disagree

The payment went through. The order never appeared.

The customer updated their address. The CRM still has the old one.

The warehouse shipped the package. The website says it is being prepared.

Each system is doing something. None of them agrees on what happened.

This is where integrations become more than a technical task. They become a business problem.

Connecting APIs is the easy part

On paper, most integrations sound straightforward.

System A sends data to System B. System B processes it and sends back a response.

The documentation provides endpoints, authentication methods, and sample requests. A developer connects them, tests a successful response, and everything looks ready.

That is the happy path.

But production environments are full of less convenient situations.

A request times out. An API introduces a new field. A customer submits the same form twice. A service reaches its rate limit. Two systems update the same record at almost the same time.

None of these situations is particularly exotic.

They are normal conditions that a reliable integration needs to handle.

What happens when something fails?

Consider an online store connected to an external inventory system.

A customer places an order. The website records the payment and sends the order information to the warehouse.

Now imagine the warehouse API is temporarily unavailable.

Does the customer lose their order? Does the website keep retrying? Will the warehouse receive duplicate orders when the connection returns?

These questions need answers before the integration goes live.

A robust approach typically includes:

• Retries: Temporary failures should not require someone to repeat every operation manually.
• Duplicate protection: Sending the same request twice should not accidentally create two orders.
• Validation: Incorrect or incomplete data should be identified before it spreads between systems.
• Logging: Failed operations should leave enough information to understand what happened.
• Recovery: There should be a way to resume, reconcile, or safely repeat unsuccessful operations.

The important part is not that failures never happen.

It is that failures do not turn into invisible data loss.

Someone needs to own the data

One of the most common integration problems is surprisingly simple: two systems both believe they are the source of truth.

The website allows customers to edit their contact information. The CRM allows sales managers to do the same.

Which version wins?

Without clear rules, the integration may overwrite recent changes with older data. Or it may create inconsistent records that nobody notices until a customer complains.

Before exchanging information, it helps to define:

• Which system owns each type of data.
• When and how information should synchronise.
• What happens when records conflict.
• Who can correct an error and where that correction should happen.

These are business decisions expressed through technical implementation.

Developers can build the mechanism, but the rules need to be agreed upon.

Monitoring is part of the feature

An integration that works today can fail tomorrow without anyone changing the application.

Third-party services evolve. Credentials expire. API limits change. External providers experience outages.

If nobody is monitoring the connection, the first indication of a problem may come from a customer.

That is too late.

Useful monitoring does not necessarily require a complicated infrastructure. It requires visibility into the operations that matter.

Are requests succeeding? Is data moving between systems? Are queues growing? Are failures being retried successfully?

And, most importantly, will the right person know when something needs attention?

A log entry that nobody reads is not an alert.

Build for the disagreement

An integration should not be judged only by whether two systems exchange data during a demonstration.

It should be judged by what happens when one of them is slow, unavailable, or unexpectedly different.

Can the operation recover? Can the team identify what failed? Can the customer continue without creating a bigger problem?

Those questions are less exciting than connecting a new API.

They are also what separates an integration that works in a demo from one a business can depend on.