What Happens to Your Automations When a Vendor Changes or Retires Its API?

Detailed Explanation

Every API a business automation depends on is a promise from that vendor about what it will accept and return — and every vendor eventually changes that promise, because their own product keeps evolving, a security or compliance requirement forces a change, or a feature simply gets retired. This isn't a sign of a badly run vendor; it happens to well-run, market-leading platforms on an ongoing basis. The problem for a business relying on that API isn't that change happens — it's that the change is usually announced on the vendor's terms, in a place built for developers, with no guarantee it reaches the person actually running the automation day to day.

Xero, the default ledger for a large share of Australian small businesses, illustrates how much change moves through a single vendor's API in an ordinary year. As of September 2026, its own developer changelog documents a run of changes on a real compulsion schedule: a mandatory new field on payroll earnings-line requests that makes previously valid requests return an error if omitted; the retirement of its old revenue-share pricing model in favour of metered connection and data-egress tiers, with an add-on cost for high-volume data transfer that didn't exist under the old model; a deadline for existing integrations to migrate off an older, broader style of permission scope; and a specific older API version scheduled for full decommissioning. None of these happened because Xero did anything wrong — they're the ordinary cost of a platform maintaining and improving its own API over time. The point isn't the specific dates, which will already be different by the time this is read; it's that a mainstream, well-run vendor generates this volume of change in a single year, and almost none of it is visible from inside the business unless someone is specifically looking for it.

What Actually Breaks, and How You Find Out

An API change rarely announces itself inside the tool you're using day to day. What you actually see is one of a few patterns:

• A silent failure. The automation keeps running but stops doing what it used to — for example, a new required field means the vendor's API starts rejecting requests that used to succeed, and records that should have synced simply don't, sometimes for days before anyone notices.
• An abrupt hard stop. A retired endpoint or decommissioned API version starts returning errors on every call from the moment the vendor's deadline passes, with no in-between warning period once that date arrives.
• An unexpected cost. A pricing or tiering change (like a shift from unlimited connections to a metered, paid tier) doesn't break the automation technically, but changes what it costs to keep running it at the same volume — see how do you avoid vendor lock-in when choosing automation tools for the broader portability question this kind of change raises.
• A scheduled deadline you have time to act on, if you know about it. Deprecation notices with a future cutoff date are the best-case version of this problem — genuinely actionable, but only for someone who saw the notice with enough lead time to act on it.

The common thread: almost none of these show up as a notification inside your actual business software. They show up in a vendor's developer changelog, a status page, or an email to whoever registered the API integration — often a developer or IT contact from years earlier who may no longer be with the business.

Who Should Be Watching, and What "Watching" Actually Means

For the handful of systems a business's automations depend on most — typically the accounting platform, and whatever CRM or practice-management system holds core operational data — someone needs an actual habit of checking for vendor API changes, not just an assumption that nothing changes. In practice that means:

1. Knowing which vendors' APIs your automations actually call, directly or through a connector platform — a surprisingly common gap, since the person who originally built the integration may not still be involved.
2. Subscribing to or periodically checking each of those vendors' developer changelogs or status pages, not just their general product announcements, since API-specific changes are rarely covered in ordinary marketing emails.
3. Reading a deprecation notice for its actual deadline and required action, not just registering that a notice exists — "decommissioned 30 April 2027" is a specific date to plan around, not a vague future concern.
4. Testing the fix before the deadline, not on it. Where a vendor requires a new field or a migrated permission scope, confirming the automation still works with the new requirement a few weeks ahead of the cutoff avoids finding out the hard way on the day itself.

This is exactly the kind of ongoing, unglamorous monitoring work that's easy to skip when nobody owns it explicitly, and one of the concrete things a managed automation or IT provider does across an entire client base — watching changelogs for the handful of vendors that matter most to many clients at once is a far better use of one person's attention than each business doing it alone, from a standing start, for its own systems.

Things to Consider

• A mainstream automation platform's pre-built connector reduces this risk but doesn't remove it. Zapier, Make, and Power Automate generally update their own connectors when a vendor changes an API — but that update can lag the vendor's actual deadline, and the platform itself occasionally deprecates a connector or an older integration style on its own separate schedule.
• This is a different failure mode from a platform outage. See what happens to your automations during a Zapier, Make, or Power Automate outage for the platform-being-down scenario — an API change is a permanent shift in what's accepted, not a temporary unavailability, and it doesn't resolve itself once a status page turns green again.
• Changing an automation to handle a vendor's new requirement should go through the same discipline as any other live change. See how do you test an automation workflow before turning it on for testing a fix before it touches production data, rather than patching it live under deadline pressure.
• The businesses most exposed are the ones where nobody currently owns this. If the person who originally built an integration has left, see our IT person built all our automations and then left, what do we do now for the broader problem of nobody being positioned to notice a vendor notice arrive at all.
• A pricing or tiering change is worth budgeting for, not just reacting to. A vendor moving from unlimited to metered API usage doesn't require action the way a breaking technical change does, but it can meaningfully change the ongoing cost of a high-volume integration if nobody is tracking usage against the new tiers.

Common Mistakes

• Assuming a working integration stays working indefinitely once it's set up. Every API is maintained on the vendor's schedule, not yours, and "it's worked fine for two years" is not evidence it will keep working through the next change.
• Relying on the business software's own interface to surface a vendor API change. These notices go to developer channels — a changelog, a status page, a technical contact's inbox — almost never to the everyday business-user interface of the tool itself.
• Not knowing who inside the business (or which external provider) is actually watching for these notices. A responsibility nobody explicitly owns is a responsibility nobody is actually doing, which only becomes visible the day something breaks.
• Waiting until an automation fails to check whether a deprecation notice explained it. Most breaking changes are documented in advance somewhere; checking the relevant vendor's changelog first is usually faster than debugging the failure from scratch as if it were unexplained.
• Treating a metered-pricing change as a technical non-event because nothing broke. A cost increase from a new usage tier is just as real a consequence as a technical failure, even though it doesn't show up as an error message.