A material study in bright daylight. Several broad ribbons of clear turquoise glass, each carrying a pearl silver spine, pass through one another at a single crossing point and splay outward in every direction.
  1. Home
  2. Insights
  3. Integrations and Data
  4. Connecting two systems

Decision guide

Before you connecttwo systems.

Whether two systems can be connected has eight checkable answers: is there an interface, can it write as well as read, how does it authenticate, what are the limits, is there a test environment, who administers it, how do the two agree which record is the same record, and what happens when one of them is down.

Every question below has an answer that can be established in a phone call with the vendor or an hour in the administration screens, before anybody is paid to build anything. Written 23 September 2026.

HUREAL / Material studies

The framing

An integrationis not a pipe.

Moving data between two systems is the easy part and it is the part everybody pictures. The work is in the standing agreement the two systems have to keep: that this customer is that customer, that this field means what the other field means, that a change on one side is reflected on the other in a known amount of time, and that when one of them is unavailable the other does something sensible rather than something silent.

That is why an integration is priced per connection rather than per record, and why two connections cost more than twice one. The second connection also has to agree with the first about which record is the same record, and about which of the three systems is now right when they disagree.

The eight questions below are the ones that establish whether the agreement is possible and what it will cost to keep. All eight have answers that can be found before anybody writes code, usually in a phone call with the vendor and an hour in the administration screens.

The eight questions

Eight answers,all available today.

  1. Is there a documented interface, and does it write as well as read

    A read-only interface supports reporting and a portal that shows things. It does not support a booking, an order or a status update flowing back. A good answer is public documentation with example requests. A weak answer is that the vendor could build something for you, which means a project inside somebody else's roadmap.

  2. How does it authenticate

    A good answer is a token-based scheme with refreshable credentials and a service account separate from a person. A weak answer is a username and password belonging to an employee, because the integration then breaks when that person leaves and every action in the other system is attributed to them, which makes its audit trail useless.

  3. What are the limits, and what are they per

    Requests per minute, per day, per key or per account. This decides whether a nightly synchronisation of forty thousand records is a five minute job or an eleven hour one, and whether a busy Monday morning will exhaust the day allowance before noon. Ask for the number and ask what happens when it is exceeded.

  4. Is there a test environment with realistic data

    Both halves matter. An empty sandbox proves that requests are accepted and proves nothing about the data. Where no test environment exists, every change is tested in production against real customers, and the project needs a different and more careful shape.

  5. Who administers the system, and can they issue a service account

    This is the least technical question on the list and it stalls more projects than any other. If the answer is a reseller who has to raise a ticket, or a former employee's account nobody can access, that is calendar time, and calendar time on the critical path belongs in the plan rather than in the first status meeting.

  6. Which system is the source of truth, field by field

    Not for the record. For each field. Price may be authoritative in one system, stock in another, the delivery address in a third and the email address in whichever one the customer last updated. Writing this down is an hour of work and it prevents the most common class of integration bug, which is two systems taking turns overwriting each other.

  7. How do the two systems agree a record is the same record

    This is the real work and it has its own section below.

  8. What happens when one side is down, slow, or answers incorrectly

    A good answer is that work queues, retries with increasing delays, and surfaces to a person after a defined number of attempts. A weak answer is that it will be fine. The difference shows up on the first day the other vendor has an outage, which is a day that will happen.

The hard part

Two systems, one customer,two different keys.

Every system has its own idea of who a customer is, and the ideas almost never line up. The accounting package knows an account number. The CRM knows a company and several contacts. The website knows an email address. The industry system knows a job site. None of those is a key the others hold, and the work of the integration is largely the work of reconciling them.

Three shortcuts are commonly attempted and all three fail in predictable ways.

  • Matching on email address

    Fails wherever a business shares a mailbox, which in trades, construction and distribution is most of the time. Two people at one company, one address, and a system that now believes they are the same person or that a company is a person.

    Works for consumer stores. Fails for business to business almost immediately.

  • Matching on name

    Fails on spelling, on abbreviation, on legal name against trading name, and on the same company appearing twice because somebody typed it again in a hurry. Fuzzy matching converts a hard failure into a quiet one, which is worse.

    Acceptable as a suggestion to a human. Never as a decision.

  • Assuming one system will just use the other key

    Usually true at launch and false within a year, because somebody creates a record directly in the second system, as they are entitled to do, and it has no key from the first.

    The most common source of the orphan records nobody can explain.

The durable answer is a mapping table: a single place that records that identifier A in one system corresponds to identifier B in the other, owned by one system, populated once by a reconciliation exercise, and maintained by the integration from then on. The reconciliation exercise is manual work, it is proportional to how messy the existing data is, and it belongs in the quote rather than in the first week of the build. A supplier who has not asked about duplicate records has not priced this.

Three transports

Push, pull,or a file at midnight.

There are three ways for data to move and the choice is usually made by what the other system supports rather than by preference. It is still worth understanding, because it decides what happens on the day something is missed, and something will be missed.

Three ways to move data between systems, compared
Compared on A webhookThe source pushes PollingYou ask, on a schedule A scheduled fileAn export at a fixed time
How current the data is Seconds. As current as the interval, and the interval is limited by the rate limits. As current as the schedule. Usually a day.
If a message is missed It is gone, unless the source retries or you reconcile periodically. Picked up on the next pass, because you are asking for everything since a marker. Picked up in the next file, if the file is a full export rather than a change set.
Load on the source system Lowest. It sends only when something changes. Highest. Most requests find nothing new. One job, at a time you choose.
What it needs from you An endpoint that is always available and answers quickly, and a way to verify the message came from the source. A stored marker of what you last saw, and tolerance for the rate limits. Somewhere to put the file, and a process that notices when it does not arrive.
When it is right Anything a customer is waiting on: payment, booking, order status. Systems with no push support, and any case where reliability matters more than latency. Large volumes, overnight reconciliation, and systems with no interface at all.

Scroll the table sideways to read it.

The arrangement that holds up in practice is often two of these together: a webhook for immediacy, and a periodic reconciliation pass that catches whatever the webhook missed. The reconciliation is the cheap insurance, and it is the thing that turns an integration from something people trust into something people can check.

Failure

The worst failureis the silent one.

An integration that breaks loudly is an inconvenience. An integration that stops quietly is a data problem that compounds every day until somebody notices, and by then the reconciliation is weeks of work rather than an afternoon. Five things prevent the second case, and they are ordinary engineering rather than anything exotic.

  • Retries with increasing delays

    An outage at the other end is temporary. Retrying immediately and then giving up converts a ten minute outage into permanently missing data.

  • Idempotency, so a retry cannot duplicate

    A request that succeeded but whose response was lost will be retried. Without a key that makes the second attempt a no-op, that is a duplicate order, a duplicate invoice or a duplicate charge.

  • A queue a person can read

    Items that failed after every retry go somewhere visible, in plain words, with what was being attempted and why it did not work.

  • An alert that points at a named person

    Not a shared inbox, and not a dashboard somebody would have to think to open. The difference between finding out in an hour and finding out in a month is entirely this.

  • A replay path

    Once the cause is fixed, the failed items are reprocessed without anybody re-entering them by hand. If replay was not designed in, the recovery from any outage is manual.

  • A heartbeat

    Something that expects the integration to run and complains when it does not. A connection that fails by never starting produces no errors at all, which is why an error alert is not enough on its own.

The question that reveals whether all of this exists. Ask a supplier what a person sees on the morning after the other system had a four hour outage overnight. A good answer describes a queue, a count, an alert that already went out and a replay. A weak answer describes checking whether everything looks all right.

Questions

Questions peopleactually ask.

  • Our vendor says they have an API. Is that enough?

    It is the first of eight answers. The ones that decide the project are whether it writes as well as reads, how it authenticates, whether a test environment exists, and whether anybody at your organisation can create a service account for it. A read-only interface with no sandbox is a reporting connection, which is a useful thing and a different thing.

  • Can you connect to a system that has no interface at all?

    Sometimes, through a file exchange, a database replica or a scheduled export, and each of those is a legitimate engineering answer with its own limits. What should be refused is screen automation that types into a user interface, because it breaks silently at the vendor next release and it usually requires storing somebody personal login, which makes an audit trail meaningless.

  • How long does an integration take?

    The engineering is rarely the long part. The long parts are getting credentials issued by whoever administers the other system, discovering that the test environment does not have realistic data in it, and the reconciliation exercise that builds the first record mapping. Those are calendar time rather than effort, and they are the reason an integration should start on week one rather than week six.

  • What happens when the other system changes?

    It will, and the integration has to be built expecting it. That means version pinning where the vendor supports it, alerts when a response stops matching what was expected, and a test that runs against the live interface on a schedule rather than only at build time. A connection that is only tested at launch is a connection that is verified once.

  • Is middleware worth it?

    It is worth it when you have several connections rather than one, because the value is in having one place where mappings, retries and logs live instead of several. For a single connection it usually adds a subscription, a dependency and another vendor to the failure path. The question to ask is how many connections you expect to have in two years, not how many you have today.

Read next

Three that followfrom this one.

The service behind this article

The answers comebefore the estimate.

An Integrations and Data engagement establishes all eight answers for every named system before a number is given, because an estimate built on an assumption about an interface is an estimate that will move. Where a system genuinely cannot be connected, that is said in discovery rather than discovered in the build.

The discovery call names every system, and each one is checked before the proposal. The interface, the authentication, the limits, the test environment, the administrator, the identity keys and the failure behaviour, system by system, written down. What comes out is a scope that already knows where the hard part is.

Book a discovery call

More on this subject in the Integrations and Data index, and everything else at Insights.

A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

Software you own from day one.

HUREAL / Material studies