System Integration

How to Tell What’s Causing Integration Failures

Pierce Solutions 16 September 2026 · 11 min read

Start with the hop that can prove something

When an integration fails, the first job is not to fix it, it is to prove where the message stopped being true. That sounds blunt, but it saves hours. Most teams lose time because they trust the loudest log, not the most reliable one.

If you are asking, How can I tell whether integration failures are caused by the source system, the target system, or middleware?, start by treating each hop as a witness, not a verdict. Source logs, middleware traces, and target logs all lie in different ways. Some omit payload details. Some log before a transaction is committed. Some only record what they tried to do, not what actually happened.

The fastest path is simple:

1. Capture the exact payload leaving the source.
2. Confirm the exact payload entering middleware.
3. Confirm the exact payload leaving middleware.
4. Confirm what the target actually accepted, not just what it said in a generic status line.

That sequence sounds basic because it is. The work is in being disciplined enough to do it every time.

The first thing experienced teams check

When the target says “request received” but the source says it sent successfully and middleware shows no obvious error, the first check is the transport boundary, not the application error. In practice, that means looking at the handoff between source and middleware, or middleware and target, depending on where the last confirmed payload exists.

If the source says “sent”, that usually means the application handed the message to its connector, queue, API client, or file drop. It does not mean the downstream system processed it. In an API flow, check whether the source received a 200, 202, or just a local success message from its own integration library. In a file-based flow, check whether the file was actually written to the watch folder, SFTP location, or object store, and whether the middleware picked it up. In queue-based flows, confirm the message was enqueued and not just published locally.

This is where teams chase the wrong problem for hours. They see “message sent successfully” and assume the source is cleared. It is not. That log only proves the source believes it did its part.

Key takeaway: The most useful question is not “who says it worked?”, it is “which hop can show the payload in its hands?”

Use evidence, not confidence

How can I tell whether integration failures are caused by the source system, the target system, or middleware? By trusting the first immutable evidence, not the first reassuring log line. Immutable evidence means something you can verify independently, such as a message ID in a queue, a raw payload captured at an API gateway, a file checksum, or a database audit record showing the row was committed.

Here is the order I use when logs disagree:

| Evidence | What it tells you | How much I trust it | |---|---|---| | Source transaction audit or outbound queue record | The source attempted to send something | Medium | | Middleware ingress trace or broker consumer record | The message arrived at middleware | High | | Middleware egress trace or transformation log | The message left middleware in a specific shape | High | | Target application audit, API receipt, or database insert log | The target actually accepted it | Highest |

If the source claims success but there is no middleware ingress record, the source is probably not the problem, but the handoff is. If middleware has ingress but no egress, that points to middleware issues. If middleware shows clean egress and the target rejects it, that is usually target system errors or a contract mismatch.

For Australian businesses running mixed stacks, this often shows up in .NET apps talking to Xero, supplier portals, or legacy ERP systems. The pattern is the same whether the message is JSON, XML, CSV, or a flat file. The evidence still has to line up.

When the payload looks fine by the time it reaches the target

A payload can look valid at the target and still be wrong. That is the trap. Middleware transformation bugs often preserve structure while breaking meaning.

A few examples I see in real integrations:

• A date changes from dd/MM/yyyy to MM/dd/yyyy, and the target accepts it, but the record lands in the wrong period.
• A code maps from ABC to A-BC because of a lookup table rule that silently normalised the value.
• A numeric field is rounded or trimmed during XML-to-JSON transformation, so the target receives a syntactically valid value that fails business validation later.
• A null becomes an empty string, which passes schema validation but fails a downstream rule.

If the payload reaches the target and the target says “invalid data”, do not assume the source sent bad data. Compare the raw source payload with the transformed payload in middleware. If the source record is clean and the middleware output changed field values, formatting, or encoding, that is a middleware issue until proven otherwise.

This is where integration mapping tools, message inspectors, and transformation logs matter. If you are using middleware like an iPaaS, ESB, or even a custom .NET service on Azure, you need a way to inspect the payload before and after mapping. Without that, you are guessing.

For a deeper look at the upstream side of this problem, see API Integration Strategy for Growing Australian Businesses. If the payload originates in a spreadsheet or migration script, How Do I Migrate Spreadsheet Data Without Losing Anything? is the better starting point.

The fastest way to isolate the failing hop

How can I tell whether integration failures are caused by the source system, the target system, or middleware? By narrowing the failure to the first hop that cannot prove custody of the message. That is the fastest way to isolate the break.

Use a three-point test:

1. Freeze the payload

Take one failing message and stop changing it. No resubmits with edits. No manual “fixes” before you know where it fails. Save the raw outbound payload from the source, then save the transformed payload from middleware, then save the inbound payload at the target if you can.

2. Compare timestamps with suspicion

Different systems timestamp events differently. Source may log when it queued the message. Middleware may log when it received it. Target may log when it finished validation. If the clocks are out by even a minute or two, the sequence will look wrong.

Do not try to force the timestamps to agree first. Instead, look for a causal chain:

• source created message
• middleware received message
• middleware transformed message
• target accepted or rejected message

If one of those steps is missing, that is your failing hop.

3. Use a correlation ID only if it is truly end-to-end

Correlation IDs are useful only when every system preserves them untouched. In the real world, many do not. Some regenerate IDs. Some drop them in retries. Some only log them at one layer.

If correlation IDs do not line up, fall back to payload fingerprints. A hash of the raw message, a unique business key, or a combination of order number plus timestamp often works better than chasing a broken trace ID.

This is the same discipline you would use when diagnosing a custom portal talking to a legacy finance platform. If you need a practical example of that kind of mixed environment, A Guide to Integrating Custom Software with Legacy Systems is worth a look.

Source, target, or middleware, what each failure usually looks like

How can I tell whether integration failures are caused by the source system, the target system, or middleware? The error shape usually gives you the answer if you know where to look.

| Likely cause | Common signs | What to check first | |---|---|---| | Source system errors | Bad field values, missing mandatory data, stale master data, failed outbound queue write | Raw source record, outbound audit, business rules before send | | Middleware issues | Payload altered in transit, mapping failures, retries without delivery, schema mismatch after transformation | Transformation logs, queue depth, retry policy, dead-letter queue | | Target system errors | Validation failure, duplicate key, rejected authentication, “request received” but no commit | Target API response, application audit, database insert or validation logs |

A source problem usually starts before the message leaves the system. You will often see broken reference data, missing customer IDs, or malformed dates in the raw record itself. A target problem usually appears after a clean payload arrives but fails business rules, permissions, or uniqueness checks. Middleware problems sit in the middle, which is why they waste so much time. They can make a clean source look guilty and a strict target look broken.

If you are dealing with recurring patterns rather than one-off incidents, the issue may be systemic. That is when an integration audit becomes more useful than another round of firefighting.

Key takeaway: If the raw source payload is clean, the middleware output changed, and the target rejects the result, the middleware owns the failure until the mapping proves otherwise.

The generic error code problem

When middleware transformation bugs and target-system validation failures both surface as the same generic error code, ignore the code first and compare the last good payload with the first bad one. Generic codes are often useless because they hide the actual boundary where the failure occurred.

A middleware transformation bug usually shows this pattern:

• source payload is valid
• middleware output differs in a field, format, encoding, or namespace
• target rejects the payload or returns a generic validation failure

A target validation failure usually shows this pattern:

• source payload is valid
• middleware output matches the source or follows the expected contract
• target rejects it because of a rule the middleware cannot know, such as duplicate invoice number, inactive supplier, closed period, or missing reference record

That distinction matters. If the target refuses a record because the supplier code does not exist in its master data, that is not a middleware fault, even if the response code is bland. If the middleware strips a leading zero from an account code and the target then rejects it, that is middleware.

The shortest path is to compare:

• raw source payload
• transformed middleware payload
• target rejection details, including any validation subcodes or field-level messages

If you only have the top-level code, ask for the full response body, the HTTP headers, the broker error message, or the database constraint name. The useful clue is usually one layer deeper than the screen shows.

What to do when logs disagree

How can I tell whether integration failures are caused by the source system, the target system, or middleware? By building a tiny forensic chain, not a bigger log search. The chain should answer four questions in order:

1. Did the source create the message?
2. Did middleware receive it?
3. Did middleware change it?
4. Did the target accept it?

If you cannot answer one of those, that is the gap to close.

A practical debugging sequence looks like this:

1. Pull the exact business record from the source.
2. Export the raw outbound message.
3. Check whether middleware has an ingress record for the same business key or hash.
4. Inspect the transformed payload.
5. Compare the target response with the field-level data.
6. Test one controlled resend with logging turned up only for that message.

Do not widen the blast radius. One message, one path, one comparison. Anything else turns diagnosis into archaeology.

In Australia, I see this most often where a business has grown faster than its interfaces. The finance team is in Xero, operations is in a custom web app, and a supplier portal or ERP sits in the middle. That is exactly the sort of environment where Integration Services or a purpose-built web application can remove the guesswork by making each hop visible.

A quick rule that saves hours

If the source can show the raw record, the middleware can show the transformed record, and the target can show the rejection reason, the blame usually falls where the data first changes shape.

That is the practical answer to How can I tell whether integration failures are caused by the source system, the target system, or middleware?. Not by the loudest system. Not by the first error string. By the first place the message stops matching reality.

The next move

Start with one failing transaction and build a three-column comparison: source payload, middleware payload, target response. Add timestamps, correlation IDs, and any business key you can trust. If the IDs do not line up, use the payload hash or order number instead. That one exercise usually tells you whether you are dealing with source system errors, target system errors, or middleware issues.

If you want the faster path, Pierce Solutions’ Integration Services are built for exactly this kind of problem, connecting ERPs, CRMs, Xero and supplier portals, and making the handoffs traceable instead of mysterious. Book a call and have the failing flow mapped properly.