Connecting Two Systems: What to Check Before Promising an Integration

"Can the two systems talk to each other?" is a question that can't be answered. Talk to do what: which data, in which direction, how often, and who's right when the two disagree. This guide will help you answer before making a commitment, because an integration promised without being verified turns a project into endless maintenance.

Almost all failed integrations have the same story: it worked in testing, then an unforeseen case came up — a canceled order, a customer with two records, a deleted item — and no one noticed that nothing had gone through for three days.

One Row for Each Piece of Data

The starting document is a list: one row per data item, four columns. If you can't fill it in, it's not yet time to look at the technical specifications.

The last column is the one that avoids arguments. If an item's price differs between the two systems, which one wins? If the answer is "it depends," the integration will produce inconsistent data no matter what technology you use.

Data That Changes Owner Along the Way

Some data changes ownership, and that's the trickiest case. An order belongs to the website until it's acquired; from that point on, the truth lives in the management system, and the website only shows a copy of it. If both can modify it, sooner or later two changes will collide, and the last one in will win — which isn't necessarily the right one.

There's just one practical rule: for each piece of data, at any given moment, only one system can write it. The others read.

What Interfaces Don't Tell You on the First Page

• Permissions. The credentials you're given might not cover all the fields you need, and the authorization can expire or require a periodic renewal that someone needs to remember to do.
• Limits. How many calls per minute or per day, how many records per request. A large catalog might not fit within the limits at the frequency you need, and that changes the project, not just the code.
• The fields actually available. The documentation lists the objects, but doesn't always say whether your custom fields are exposed: you need to check against your own data, not the example.
• The test environment. If none exists, every check is run on real data, with everything that implies. It's a constraint to plan for beforehand, not to discover later.
• The vendor's terms. What's allowed, under which plan, and whether access to the data exchange is included or is a separate cost.

Integration Sheet: The Order That Arrives Twice

The case to design for isn't the normal one, it's the messy one. An order is sent to the management system, the response doesn't arrive because of a network issue, the system retries, and the order gets entered twice. It's the most common failure of all.

1. Every message carries a stable identifier, decided by the sender: the website's order number, not a sequence number generated at the moment of sending.
2. The receiver checks whether that identifier has already been processed. If so, it does nothing and responds that it's already handled. This property is what makes it safe to retry.
3. Retries happen at increasing intervals and for a defined number of times; after that, the message ends up in an error queue that a person reviews. Retrying forever hides the problem instead of solving it.
4. At regular intervals, the two systems are compared over the period: how many orders on one side, how many on the other, which are missing. This is reconciliation, and it's the only thing that truly tells you whether the integration is working.
5. Recovery is a written procedure: who deletes the duplicate and in which system, what happens to any document already issued, who notifies the customer if they received two confirmations.

The same sheet needs to be filled out for customer records, where the typical failure is different: two records for the same company, created with the VAT number written two different ways. You need a matching rule decided in advance, and a place where unclear cases land while waiting for someone to review them.

Who Notices When It Stops

An integration always stops, sooner or later: the vendor updates something, a password expires, a certificate isn't renewed, a field changes format. The question isn't whether it will happen, but how long it will take before someone notices.

• A check that verifies recent data has passed through and alerts you when the flow stops, instead of waiting for a customer's phone call.
• A named recipient for that alert, and a second name for when the first one is unavailable.
• A log of exchanges that can be checked without calling a developer: when an order doesn't arrive, the first question is always "did it go out?"
• A clearly assigned responsibility for maintenance, with credential and certificate expiration dates noted somewhere someone actually checks.

What This Guide Doesn't Cover

This guide covers designing the exchange between two systems meant to coexist. Bringing in historical data — from an old management system or from spreadsheets — is a different task, with its own data-cleaning and result-checking issues, and has its own dedicated guide. The specific case of connecting an online store to inventory is also covered separately.