Seven questions to answer before connecting another system to your stack

Connecting two systems looks like the simplest kind of software work: read from one, write to the other. In practice it is where a surprising share of operational incidents come from — duplicated orders, contradictory records, silent gaps that nobody notices until a customer does. Almost always, the cause is not the API. It is a question that was never asked before the data started flowing.

Before connecting another system to your stack, settle these seven questions. They take an afternoon to answer and save weeks of untangling later.

1. What is the source of truth?

For every piece of data that will exist in both systems — a customer, a price, a stock level, an order status — decide which system owns it. The owner is where a human changes it and where every other system reads it. When two systems both believe they own the same field, they will eventually disagree, and no amount of syncing resolves a disagreement about who is right.

2. Which way does the data flow?

Once ownership is settled, direction usually follows: data flows out from its owner. Be explicit about it anyway, field by field. One-way flows are far easier to reason about than two-way sync, and many integrations that were scoped as “keep both in step” only actually need data to move in one direction.

3. How are records identified across systems?

Two systems will name the same real-world thing differently. You need a stable, shared identifier — and a plan for records that exist in one system but not yet the other. Matching on names, emails or anything a human can edit is a common and painful mistake; those change, and the match breaks quietly.

4. What happens when it fails?

External systems are unavailable sometimes. The question is not whether a call will fail, but what happens when it does. Does the work retry? Does it queue? Does someone get told? A connection that fails silently is worse than one that fails loudly, because you lose the one thing you need — the knowledge that something did not happen.

Retries and duplicates are the same question

The moment you add retries, you risk doing the same thing twice — charging a card, sending an order, creating a duplicate record. Any operation that changes something must be safe to repeat, usually by carrying an idempotency key so the receiving system can recognise a repeat and ignore it. Design the retry and the duplicate protection together, or you will build one and discover you needed the other in production.

5. Who is allowed to do what?

An integration runs with credentials, and those credentials have power. Give each connection the least privilege it needs — read-only where it only reads, scoped to the specific data it touches — so that a mistake or a leaked key does the least possible harm. A single all-powerful key shared across integrations turns a small incident into a large one.

6. What are the provider's limits?

Every external service has rate limits, quotas and maintenance windows. If your integration ignores them, it works in testing and fails at your busiest moment. Read the limits before you build, handle them deliberately — backing off, spreading load, respecting the provider's signals — and treat a rate-limit response as an expected state, not an error.

7. How will you know it is working — and who owns it?

An integration is not finished when it first succeeds. It needs monitoring that tells you it is still working: how many records moved, how many failed, how far behind it is. And it needs an owner — a person who is responsible for it, who sees the alerts and who decides what to do when the provider changes something. An unowned integration decays until it breaks.

A good integration is not a connection that works once. It is one that fails visibly, recovers safely, does not duplicate important actions, and tells someone when it needs attention.

Answer them first

None of these questions require code to answer. They require a decision — about ownership, direction, identity, failure, permissions, limits and responsibility. Written down before the build, they become the specification for a reliable integration. Discovered afterwards, they become the incident report. The afternoon spent settling them is the cheapest work in the whole project.