What to do when your SaaS integration breaks

The short answer

When a SaaS integration breaks: stop the damage first (pause the sync if it’s writing bad data), establish when it actually broke (usually earlier than you noticed), check the boring causes (expired credentials, changed API, renamed field) before the exotic ones, and capture what you learn so the next failure is a ten-minute fix instead of a mystery.

Then fix the real problem — which is rarely the specific failure, and almost always that the integration could fail silently.

First: how integrations actually announce themselves

Broken integrations rarely say they’re broken. They announce themselves as business symptoms, days or weeks later:

• “The CRM is missing all of last week’s leads”
• “Inventory numbers don’t match again”
• “The customer says they paid but the accounting tool disagrees”
• “Why did nobody follow up with this customer?” — because the record never arrived

By the time a human notices, there’s usually a backlog of missed or duplicated data. That gap between broke and noticed is where the real damage lives — and shrinking it is the actual fix, more than any individual repair.

The triage sequence

1. Contain

If the integration is still running and producing wrong data — duplicating records, overwriting good values with stale ones — pause it. A stopped sync is a known problem; a corrupting sync is a growing one. If pausing isn’t possible, note the exact time so you know where the bad-data window ends.

2. Establish the timeline

Find when the last successful sync happened. Check the integration platform’s run history (Zapier/Make logs), the destination system’s record timestamps, or the source system’s webhook delivery logs. The window between last-success and now defines your cleanup scope later — and the break date is itself a clue. Did something change that day?

3. Check the boring causes first

In rough order of real-world frequency:

• Expired or revoked credentials. API keys rotate, OAuth tokens expire, the employee whose account authorized the connection left the company. (This one is the classic: the integration ran under a personal login for years.)
• Somebody changed a field. A renamed column, a deleted custom field, a new required field on a form, a picklist value that no longer exists. Integrations are brittle against upstream “harmless” edits.
• The vendor changed the API. Deprecated versions, new rate limits, changed response formats. Check the vendor’s changelog and status page — you may find your break scheduled in an email nobody read.
• Plan or billing changes. API access downgraded with a plan change, trial features that lapsed, an unpaid invoice on the middleware platform.
• Volume. You grew; the rate limit didn’t. Integrations built at 50 records/day fall over at 500 in ways that look random.

Genuinely exotic failures — vendor outages, data corruption, timezone edge cases — exist, but check the list above first. It resolves most incidents.

4. Fix, then reconcile

Repairing the connection is usually the quick part once the cause is known. The frequently-skipped step is reconciling the gap: the records that didn’t sync during the outage don’t sync themselves retroactively. Re-run, backfill, or manually import the window from step 2 — and de-duplicate if the fix caused a replay. Skipping this is how “the integration is fixed” and “the data is wrong” stay true simultaneously.

After the fire: make the next failure loud

An integration that can fail silently will fail silently again. The durable fix costs a fraction of the incident that prompted it:

• Failure alerts — when a sync run fails, a human is notified. Every serious integration platform supports this; almost nobody turns it on.
• A heartbeat check — silence is also a failure mode. “No records synced in 24 hours” should page someone, because a sync going quiet usually means it’s broken.
• A reconciliation report — a periodic automated comparison between systems (“Shopify says 214 orders this week, the sheet says 214”) catches the partial failures that alerts miss. This was the quiet hero in this Shopify inventory sync project.
• Logging that answers questions — what ran, what data moved, what failed, and why. When something breaks, this converts hours of guessing into minutes of reading.
• An owner — one named person or partner who gets the alerts and owns the fix. Integrations without owners decay; it’s their nature.

Notice that none of this is sophisticated. It’s the operational plumbing that demo-day integrations skip — the same gap that sinks AI automations, because an AI workflow is just an integration with a model in the middle.

When it keeps breaking

If the same integration fails every few months, stop treating incidents as bad luck. Chronic breakage usually means one of:

• Wrong architecture for the volume — polling where webhooks are needed, with no retry logic and no queue between fast and slow systems.
• Too many hops — form → automation platform → spreadsheet → script → CRM. Every hop is a failure point; middle links can often be removed entirely.
• Nobody owns the middle — each vendor supports their own end, and the connection between them is officially nobody’s job. This is precisely the gap a system integration engagement exists to own.

A rebuild of a chronically failing integration — with retries, alerts, and reconciliation designed in — typically costs less than the annual staff time spent hand-patching the old one. That math is worth actually doing; it’s the same hidden-cost pattern as legacy software maintenance.

FAQ

Our integration runs through Zapier/Make — does this advice change?

No, it maps directly: check the run history for the timeline, task failures for the cause, and turn on failure notifications (most accounts have them off). The chronic-breakage section applies doubly — no-code chains accumulate hops fast.

How do I know if data was lost or just delayed?

Compare record counts between systems for the outage window (that’s a manual reconciliation report). Delayed data appears after the fix; lost data needs a backfill. Assume lost until counted.

Who should we call — the vendor or a developer?

Vendors support their own product’s end and are genuinely useful for API/status questions. For anything spanning two systems — which is where integrations live — you need someone accountable for the connection itself. That’s an integration developer.

Can you fix an integration someone else built?

Yes — that’s the normal case, including no-code chains and inherited scripts. It usually pairs with a Business Systems Audit to find what else is one silent failure away. I work remotely with businesses across North America from Oshawa, Ontario.

Broken right now?

If you’re mid-incident, the triage sequence above will get you contained and diagnosed. If you’d rather hand it off — or you’re on your third incident this year and want it to stop — tell me what’s broken or start with a Business Systems Audit.