Consider an order that exists in a customer application but has not appeared in the fulfilment system. Both teams can show successful requests in their logs. The customer still has no usable answer about the order.
An integration needs more than compatible interfaces. It needs an agreement about the meaning of the information moving between them and the responsibility for resolving disagreement.
Decide which system is allowed to be right
Start with ownership at the field or business-concept level. One system may own the order identity, another the shipment status, and another the customer contact details. “Both systems have a copy” does not explain which update should prevail.
Walk through a concrete change. If a customer edits an address after fulfilment begins, can the change still be accepted? Where is that decision made? What does the customer see if the answer is no?
Those rules should shape the interface contract. An integration that successfully transmits an update can still fail the product if the receiving system interprets it differently.
Treat uncertainty as a state
Suppose a request times out. The sending application may not know whether the receiving system completed the operation. Retrying without a way to recognise the same operation could create a duplicate; refusing to retry could leave the work unfinished.
Agree on how an operation is identified, how its status can be checked, and what the receiving side does with a repeated request. Test those behaviours with the actual integration, including interruptions. Do not infer the business behaviour from a successful response to one demonstration request.
The user-facing experience also needs a decision. A state such as “still confirming” can be more accurate than declaring either success or failure before the product knows which occurred.
Give exceptions a destination
Every unresolved item should have a route to investigation. That could be a visible queue with the relevant identifiers, an explanation of the latest known state, and a controlled way to reconcile or retry the operation.
Specify who watches that queue and when. Otherwise, it becomes a storage location for work nobody owns. Include what happens when the external partner is unavailable and which evidence your team can provide without exposing unnecessary customer data.
A useful integration review therefore includes the operating team as well as the engineers. They can identify whether the proposed recovery process is practical during an ordinary working day.
Keep the agreement alive
An integration's assumptions can change when either product evolves. Agree on how breaking changes are communicated and how representative flows are checked before release. A contact name in an old project document is not a durable change process.
The valuable deliverable is a connected product journey with understood states and responsibilities. The API connection enables it; the operating agreement makes it manageable.