When integrations quietly break online stores

The most dangerous integration bugs are the ones that don't look like bugs.

Most integration failures don't crash systems.

They quietly corrupt them.

I recently worked on a case where an e-commerce portal integrated with a CRM system. Customers could log in and view their invoices.

At some point something strange started happening.

Some customers began seeing invoices that did not belong to them.

There were no crashes.
No errors.
No obvious alarms.

But from a GDPR perspective this was a serious incident waiting to happen.

The symptom

From the outside everything looked normal.

The portal simply fetched invoices from the CRM using a filtered query.

For months this integration had worked without any issues.

Then gradually, inconsistencies started appearing.

Certain users suddenly had invoices in their account history that clearly belonged to other clients.

The system itself believed the data was correct.

The CRM returned it.
The portal displayed it.

Nothing in the logs suggested a failure.

Why this kind of bug is dangerous

Most engineering teams expect failures to look like this:

exceptions
broken requests
system crashes

But integration failures often look like perfectly valid data.

The system continues working.

Only the meaning of the data changes.

That is far more dangerous.

Investigation

The first day was spent understanding the environment.

What systems were involved?
Where did the data come from?
What filters were applied when retrieving invoices?

The portal was sending a fairly complex filtered query to the CRM API.

For a long time that query reliably returned only invoices belonging to the logged-in customer.

But something had changed.

The root cause

The CRM system had introduced internal changes to how filtering worked.

The existing query still returned results.

But the filtering logic no longer behaved exactly the same way.

The portal was unknowingly receiving a broader dataset than expected.

And because the integration trusted the CRM response, it simply displayed what it received.

No validation layer existed between the systems.

The fix

The integration logic had to be rewritten.

Instead of relying on the old CRM filtering behaviour, the portal now explicitly enforced the correct customer constraints before displaying any invoice.

The investigation and fix took roughly two days.

A third day was spent testing edge cases to ensure the leak could not happen again.

The lesson

The most dangerous integration bugs are not the ones that break systems.

They are the ones where the system continues to work — but the assumptions no longer hold.

And when integrations depend on external systems, those assumptions can change without warning.