What Happens When the API You Built Your Business On Changes

A client of mine got a call from their accountant on a Monday morning asking why no invoices had synced to Xero since Thursday. Nothing had changed on their end. No one had touched the automation. The problem was that Xero had quietly retired an older version of one of their endpoints, and the tool doing the syncing kept calling it anyway, failing silently every time.

This kind of thing happens more than people expect. You build something once, it works, and you stop thinking about it. The API on the other end doesn't stay still though. It gets versioned, deprecated, rate limited, or changed in ways that only show up when something stops working.

Automation is not "set and forget"

Most business automation relies on at least one third-party service: a payment processor, an accounting package, a CRM, a shipping provider, a marketing platform. Each of these has its own API, its own release schedule, and its own reasons for changing things that have nothing to do with your business.

When you first build the integration, everything lines up. The fields match, the auth works, the response format is what you expect. Six months or two years later, one of those things shifts and nobody notices until an order doesn't ship, an invoice doesn't get raised, or a customer doesn't get their confirmation email.

Where these breakages actually happen

A few patterns come up again and again:

• Version deprecation. A provider announces an API version will be retired in six months. The announcement goes to a developer mailing list nobody's monitoring any more, and the old version just stops responding on the cut-off date.
• Silent field changes. A field that used to always be present becomes optional, or a status value gets a new option added. Code that assumed the old shape starts failing on edge cases, not on everything.
• Rate limiting. As your business grows, you make more calls. At some point you cross a threshold you never knew existed and start getting throttled, usually during your busiest period.
• Webhook drift. A webhook that used to fire reliably starts arriving late, out of order, or occasionally twice. If nothing is designed to handle duplicates, you get double-charged customers or duplicate records.
• Auth expiry. Tokens expire, refresh flows change, and an integration that authenticated fine at setup just stops working one day with no obvious error message.

None of these are exotic problems. They're just what happens when you connect two systems that are maintained by different people, on different timelines, for different reasons.

What good integration work actually looks like

The fix isn't to avoid integrations, they're usually the whole point. It's to build them assuming they will eventually break, and making sure you find out before your customers do.

A few things I build in as standard, not as extras:

• Logging every call and response. When something fails, I want to see exactly what was sent and what came back, not guess after the fact.
• Alerting on failure, not just success. If a sync job fails silently, that's worse than if it never ran at all, because everyone assumes it's working.
• Idempotency. If a webhook fires twice, the second one should be a no-op, not a duplicate invoice or a second email.
• Retry with backoff. A temporary blip shouldn't mean a lost transaction. A queue with retries handles the difference between a five-second outage and a genuine failure.
• Version pinning where possible. Pinning to a specific API version and reviewing changelogs before upgrading, rather than always calling "latest" and hoping nothing shifts underneath you.

None of this is complicated engineering. It's mostly discipline: assuming failure is normal and designing for it, rather than treating it as an edge case that won't happen to you.

The particular risk with no-code automation chains

Tools like Zapier and Make are genuinely useful, and I've got no problem recommending them for the right job. But when a business builds its core operations on a long chain of these, with one automation triggering another, the failure modes get harder to see. A single step failing halfway through a chain can leave data in an inconsistent state with no clear owner of the problem.

If that chain is handling something that matters, like billing, stock levels, or customer communication, it's worth asking: what happens if step three fails after step two has already run? Who finds out, and how quickly? If the honest answer is "we'd notice when a customer complains", that's a sign it's time for something more deliberate, even if it's just wrapping the critical bit in proper error handling and monitoring rather than rebuilding the whole thing.

When it's worth moving to a proper integration layer

Not every automation needs custom code behind it. But once an integration is handling money, stock, or anything customer-facing, it's usually worth the investment to build a thin, dedicated layer that owns the connection to that API: handles auth, retries, logging, and alerting in one place, so every part of the business that depends on it isn't exposed to the same fragile chain.

I've built these for clients as standalone services that sit between their systems and a provider like Stripe, Shopify, or a shipping API, precisely so that when the provider changes something, there's one place to fix it rather than five automations that all quietly stop working on the same day.

Where I fit in

I work on integrations like this directly, no handoffs between whoever built the original automation and whoever has to fix it later. If you've got something running that you're not confident will still be working in a year, or you've had a breakage like the one above and want it built properly this time, that's the kind of work I take on. Happy to have a look and tell you honestly whether it needs rebuilding or just tightening up.