The vendor changed something and your automation stopped

Nothing was edited. Nobody changed a setting. On Tuesday the orders stopped arriving, or the field came through empty, or the whole connection asked to be authorised again and then refused.

Somewhere else, a company you pay changed something, on a schedule published months ago, addressed to an audience that does not include you.

The warning existed, in a place you were never going to look

Platforms do not usually break integrations without notice. They publish notice — in developer documentation.

Shopify is a good example because its policy is stated precisely. Its versioning documentation says: "Shopify releases a new API version every three months at the beginning of the quarter, at 5pm UTC." Each stable version "is supported for a minimum of 12 months, with at least nine months of overlap between consecutive versions." Things marked as deprecated are "removed in a subsequent release—for example, something deprecated in 2026-10 might be removed in 2027-01."

That is a generous amount of warning. A year of support, nine months of overlap, a quarterly rhythm you could put in a calendar.

Now ask who in your business reads a developer changelog. In a company of six people running a shop, a booking system and an accounting sync, the answer is nobody, and there is no reason it should be. The notice was published. It was addressed to whoever built the integration, which may be a contractor you last spoke to eighteen months ago, or an app vendor, or nobody at all if you built it yourself from a template.

The failure is not that you were not told. It is that the telling and the consequences are aimed at different people.

That schedule is one platform's, incidentally. Other vendors give different windows, and small ones may give none at all — a feature simply behaves differently one morning. Do not assume a year of grace anywhere you have not checked.

The shapes this takes

A field disappears or is renamed. The automation keeps running and writes blanks. This is the worst version, because nothing errors: you find out from a customer, or from an invoice with a missing line, months later.

A whole version is retired. The connection stops and asks to be reauthorised. Loud, immediate, and comparatively easy — you know the day it happened.

Authentication changes. Everything works until a token expires, then it does not. The gap between the change and the symptom can be weeks, which makes the cause hard to see.

A feature moves to a higher plan. Nothing technical changed at all. The capability you built on is now sold separately, and the fix is a purchase decision rather than a technical one.

Limits tighten. The same volume that was fine last month now hits a threshold. This one has its own article; the distinction is that here the mechanism stayed the same and the allowance shrank, rather than the mechanism changing under you.

The thing to fix is not the integration

Fixing the immediate breakage is the easy part, and you will do it whether or not you read this. The useful question is what to change so the next one is less expensive, because there will be a next one — quarterly, in Shopify's case, by their own published rhythm.

Write down what depends on what. One page. Which of your workflows touch which platforms, roughly what they move, and what stops if that connection stops. Most small businesses cannot answer this in an emergency, and the hour spent building it is repaid the first time something breaks at a bad moment.

Give every integration a named human. Not a company — a person, with a current email address, who would receive a notice and understand it. If that person is a contractor you no longer work with, the integration currently has nobody, and you have just found your most likely next outage.

Subscribe to the changelogs that matter. For your two or three most important platforms, the developer changelog and status page are worth an inbox rule. You will understand perhaps a fifth of it. The fifth you understand is the part that mentions something you use.

Check the quiet ones deliberately. The failures that hurt are the silent ones — the blank field, the record that stopped syncing, the report that lost a column. A monthly look at one recent record end to end, comparing what is in the source with what arrived at the destination, catches these while they are still small.

Know what manual looks like. For each critical automation, how would the work get done for a week without it? If the answer is "we could not", that is worth knowing before the week arrives.

What to do in the first hour

Establish when it stopped, not why. The last good record tells you more than any error message: it dates the change, which usually identifies it.

Check the vendor's status page and changelog before debugging. Ten minutes that frequently ends the investigation, and saves you rebuilding something that was never broken.

Work out what has been wrong since that timestamp. This matters more than the repair. If orders have been arriving without a field for three weeks, the fix does not correct three weeks of records — someone has to go back for those.

Then repair, and write two lines about it somewhere. What changed, what you did. The next occurrence will look familiar, and the note is the difference between a twenty-minute fix and another afternoon.

When it is worth building differently

For a business with two or three integrations, the list above is the whole discipline: a dependency page, named owners, and a monthly spot check.

It changes when the chain is long enough that a change at one end is invisible at the other — a marketplace feeding an inventory tool feeding an accounting system, where a renamed field in step one becomes a wrong number in step four and nothing in between complains. At that length, surviving vendor changes is a property of how the thing was built: whether it validates what it receives, whether it stops when the shape is wrong, and whether it tells someone.

Working out which of your chains are that long, and which would fail silently, is one of the things a process audit covers: $299, three business days, and a map of what depends on whom.

Related: what happens to your automations when the plan runs out covers the neighbouring case — the mechanism stayed the same and the allowance ran out, rather than the mechanism changing under you.