6 Silent Integration Issues That Don't Show Up Until After Go-Live

One thing I’ve noticed across CRM and ERP integrations is that the initial sync isn’t usually the hard part.

The difficult problems tend to appear days or weeks after a project is marked complete.

Some examples:

1. Duplicate records after retries

A failed webhook is retried without proper idempotency, creating duplicate invoices or contacts.

2. Currency rounding differences

Small rounding discrepancies accumulate until finance starts questioning invoice totals.

3. Partial refunds

Native integrations often handle full refunds well but break down when only part of an order or invoice is refunded.

4. Deleted or merged CRM records

A contact or company is merged or deleted in HubSpot, but downstream systems continue referencing the old ID.

5. API rate limits

Everything works during testing, but production traffic triggers rate limiting and intermittent failures.

6. Expired authentication

Access tokens expire silently, and the first indication is a failed sync discovered days later.

None of these are particularly difficult to solve individually.

The challenge is that they’re edge cases that rarely appear in demos or initial testing, yet they consume a disproportionate amount of delivery time once a project is live.

I’m curious:

Which post-launch integration issue has consumed the most time on your projects?

Hey @SamuelOliver,

Great discussion starter! For anyone navigating similar challenges, a few resources worth bookmarking:

Looking forward to seeing other folk’s thoughts on this!

Happy HubSpotting!

Sam, Community Manager

Merged and deleted CRM records have cost us the most time because the failure often looks like a normal successful sync. The fix that held up was to stop treating a HubSpot object ID as the business identity. We keep a canonical external ID, a merge tombstone that maps old IDs to the surviving record, and an event ledger with the source timestamp and correlation ID. Every downstream write resolves that map first; stale events are rejected instead of recreating the retired record. I’m Ege, co-founder of Atlantic, based in SF. We also alert on state divergence, not just HTTP errors, because a 200 response can still leave the CRM and downstream system disagreeing.

Thank you, Ege. In particular, the concept of keeping a merge tombstone and validating writes against that is a better solution than thinking of HubSpot object IDs as business keys.

Your point on state divergence was also interesting—there’s no doubt that an HTTP success can actually mask business state inconsistency. Wondering whether you keep those mappings forever or they expire at some point?