fixmation.Get my quote
Integrations8 min readPublished August 2026

It worked for months, you changed nothing, and today it fails

When an automation breaks without anyone touching it, the change usually happened at a third company whose release notes are addressed to developers. Even the schedule that governs it can contradict itself on the vendor's own page.

Who changed it, if you did not?

Somebody in the chain you never signed up to watch. Every automation has at least three owners: the service holding your data, the connector your platform wrote for that service, and the platform itself. All three ship changes on their own schedules, and only one of them - you - is absent from that process entirely.

So "I changed nothing" is an accurate technical report, not an excuse. The useful question is not what you did differently, but which of the other two shipped something.

What does that look like when it happens?

Like a step that worked yesterday returning an error that reads as if you misconfigured it. From Make's forum at the end of July:

The scenario has been working without any problems until now. I have not intentionally changed the request structure, but since today I suddenly receive the following error: [400] Empty Payload. JSON content expected.

Read that error cold and it sounds like the person forgot to fill in a field. The phrase "until now" is the actual diagnostic content: a configuration that was correct on Thursday is not usually incorrect on Friday.

Why does the connector break when the service changes?

Because the connector is a translation, and translations go stale. Your platform wrote code against a particular version of the service's interface. When the service retires that version, the connector keeps speaking it until somebody at the platform updates it - and you are downstream of a decision made at two companies.

That gap is visible in public. In August an advertiser reported it on n8n's forum:

Google sunset v21 support for the Google Ads API. This was telegraphed multiple times by Google, and unfortunately n8n has not updated the native node to account for that.

Notice what this person did right and how little it protected them. They knew the deprecation was coming - Google had said so repeatedly - and the fix they wanted still had to come from the automation platform, because the native node is the platform's code:

Requesting that this node be updated ASAP, as it is breaking a number of our ad reporting workflows, and we would rather not replace everything with HTTP requests.

  • the same user, same thread, 13 August 2026

Being informed early is worth something, but it does not put the repair in your hands.

Can you not just read the vendor's deprecation schedule?

You can, and you should - but read the body of the page, not the summary sitting on top of it, because on the page I checked those two disagree. Google's Google Ads API sunset page states its policy in the body like this:

We strive to keep at most five major versions available at any one time.

while the automatically generated "Page Summary" block at the top of the same page says:

Google aims to keep at most four major versions available at any time, with major versions lasting around 12 months and minor versions around 10 months.

Four in the summary, five in the body. The summary also promises at least a twenty-week overlap between client library releases and sunsets, a sentence I could not find in the body at all. If you are planning around how much runway a version has, those are different plans.

The body is also honest about how firm the dates are:

tentative date means that the sunset could happen any time in that month, and the dates could change.

A month-wide window that can move is a perfectly reasonable engineering position. It is also not something a small business can schedule staff around, which is why "watch the vendor calendar" is weaker advice than it sounds.

Should you replace the broken connector with a raw HTTP call?

It is the standard community answer, and it is a trade with a price tag. Within minutes of the Google Ads report:

If that node's not working, a HTTPS request node should help!

That does work, and it moves the maintenance to you. The connector was handling authentication, token refresh, pagination, error shapes and version differences; a hand-built request handles what you wrote into it. You have swapped a dependency you cannot control for a dependency you must maintain - sometimes correct, especially as a bridge for a few weeks, but worth choosing knowingly instead of because it was the first reply.

The person in that thread named the objection precisely: they would rather not replace everything with HTTP requests. That instinct is sound. Replace the one step that is blocked, keep the rest native, and put a note in the workflow saying why - otherwise in six months someone inherits raw API calls with no explanation.

How do you tell whose release broke it?

Work outward from the failing step, and use timing as your main instrument:

  1. Fix the moment it started. Open the run history and find the last successful run and the first failed one. Everything else depends on this timestamp, and it takes two minutes.
  2. Ask whether anything of yours moved in that window. A change to the automation, a new plugin, a rotated credential, someone editing a spreadsheet column. If not, you are looking outward.
  3. Check whether the same connector fails everywhere. One broken step in one workflow suggests configuration; the same service failing across several workflows suggests a version change.
  4. Read the error for what it says about the shape, not the content. "Empty payload", "unsupported version" and "unknown field" describe a conversation going wrong, not data going wrong.
  5. Search the platform's community for the service name plus the month. For this class of failure, someone else is always a day or two ahead of you, and the thread will say whether a fix is coming.
  6. Check the service's own developer changelog. This is where the change was announced, in the place written for the people who build connectors rather than the people who use them.

Why did nobody tell you?

Because deprecation notices are published where developers look - changelogs, developer blogs, the pages a vendor writes for whoever builds against its API. Google's sunset page, quoted above, tells readers to subscribe to its blog. None of that reaches the business whose automation is about to stop, and there is no equivalent channel that does.

The practical consequence is that you cannot subscribe your way out of this class of failure. What you can do is notice it faster. A step that has failed every hour since Tuesday is only expensive because nobody saw it until Friday, which is the same reason silence is the failure mode worth building a check for.

What can you do in advance, realistically?

Less than vendors imply, more than nothing. Three things pay for themselves and none of them requires watching release notes:

  • Keep a list of which services each automation touches. When a service has a bad week, you want to know in one minute which of your processes are exposed, not spend an afternoon opening workflows.
  • Make failures visible on a schedule you control. A weekly look at run history catches the connector that started failing quietly on Tuesday.
  • Know which steps have no substitute. If one connector is load-bearing for invoicing, that is worth knowing before the week it breaks, not during it.

None of this prevents somebody else's release. It converts a week of confusion into a morning of diagnosis, which is the whole available win.

When is this worth handing over?

If one step broke, the error names a version, and the platform's forum already has a thread with an answer, wait for the update or bridge that single step yourself.

It becomes a job when the automation is load-bearing and the fix has no published date, when several workflows use the same broken connector and each needs its own bridge, or when the temporary replacement has to handle authentication and paging that the connector used to handle for you. Building that bridge so it can be removed cleanly when the vendor ships, instead of letting it become permanent by accident, is scoped work with a defined end state, and it is what a fixed-price Fix S or M is for.

Sources

Integration dropping data between systems? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.