API Deprecations Break Automations Two Ways

When a vendor changes an API, your automation fails in one of two shapes. It drifts, meaning the platform quietly moves you onto a newer version of the integration and the output changes underneath a workflow that still reports success. Or it cliffs, meaning nothing changes for two years and then every run returns an error on a date the vendor published well in advance. Which shape you get is decided by how the step was built, not by the vendor. The two need different controls, and most teams have only built the one that catches the loud failure.

Drift and cliff are not the same failure

A cliff is the failure everyone pictures, and it is the cheap one. Salesforce retired platform API versions 21.0 through 30.0 as of the Summer '25 release, three years after deprecating them. After that release, a REST call to one of those versions returns 410 GONE, a SOAP call returns UNSUPPORTED_API_VERSION, and Bulk returns InvalidVersion. Every affected workflow fails at once, with a status code that names the problem. If you have any alerting at all you know within the hour, and the fix is a version string.

Drift is the one that costs money. The integration keeps working. The workflow keeps returning green. But a field that used to be a string is now an object, an enum picked up a seventh value your router does not branch on, or a timestamp that used to arrive in the account's local time now arrives in UTC. Nothing errors, because from the runner's point of view nothing is broken. It just writes slightly wrong records into your CRM for eleven weeks, until somebody in accounting notices that renewals in one region are dated a day early.

The asymmetry decides where your attention should go. A cliff has a date, a status code, and a blast radius you can see. Drift has none of those, and it backfills bad data the entire time it goes unnoticed. Operators tend to worry about the cliff and get hurt by the drift.

Why the auto-upgrade stops exactly where you need it

Here is the part that inverts the usual mental model of a managed connector.

Zapier's platform migrates existing users onto newer app versions, but only within a limit it states plainly: you can migrate between versions that share the same semantic major number, so 1.0.0 to 1.2.0 is allowed and 1.9.0 to 2.0.0 is not. Its help documentation goes further and says that sometimes a new version's breaking changes prevent Zapier from updating your Zaps, and that once the end-of-life date arrives, affected Zaps pause automatically.

Read that twice. The automatic migration covers every change that is defined as unable to break you, and it withdraws for the one change that can. That is the correct engineering decision. Silently migrating a workflow across a breaking change would corrupt data instead of stopping it, which is strictly worse. But it means the belief that "the platform keeps my integrations current" is false in the only case where being current matters. The platform carries you through a hundred minor bumps you never see, any one of which can reshape a field you read, and then hands you the breaking one to do by hand.

n8n takes the opposite position, and its node versioning reference is explicit: if a user builds and saves a workflow using version 1, n8n keeps using version 1 in that workflow even after version 2 of the node is published. New workflows always load the latest node. Old workflows stay frozen at the typeVersion they were saved with. Zero drift, guaranteed cliff, and no email when the underlying vendor API dies out from under the pinned node.

Make sits between the two and is honest about it. Its documentation says that when services release a new API version, the Make app eventually becomes deprecated and shuts down, leaving a legacy module in your scenario, and that keeping scenarios running means updating those legacy modules to the latest versions, manually or with the Module Migrator.

The choice was made for you when you picked the tool. It is not a setting you forgot to turn on.

Which shape does each integration give you?

Sort every external call your automations make into one of these rows. The last column tells you which control it needs.

How the step is built	Non-breaking vendor change	Breaking change or retirement	Shape
Zapier app step	Migrated for you, usually with no notice	Zapier cannot migrate it, you get an email, the Zap pauses at EOL	Drift, then cliff
Make app module	New module version ships, your scenario keeps the old one	Module goes legacy and stops, you swap it or run Module Migrator	Cliff
n8n built-in node	Nothing changes, the workflow keeps its saved typeVersion	The node keeps calling a dead endpoint and the step errors	Cliff, no notice
HTTP Request with the version in the URL	Nothing changes	Hard error on the vendor's published sunset date	Cliff, known date
HTTP Request with no version pinned	Response shape can change any day	Nothing to retire, you just get the new behavior	Pure drift
Vendor pins a version to your account	Nothing changes until you opt in	You choose the upgrade date	Drift you control

That last row deserves its own warning. Some vendors set an API version at the account level rather than per request, and the version attached to a webhook endpoint is set separately, when the endpoint is created. Stripe works this way: the account has a default version you upgrade from the dashboard, and each webhook endpoint keeps whatever version it was created with unless you change it. One account can therefore be sending your automation event payloads shaped by a version you moved off years ago, while your outbound calls use the current one. Nothing about that is broken, and nothing about it is visible from inside the workflow.

The deprecation notice goes to someone who left

Every one of these systems has a notification path, and every one of them routes to a person rather than to a team. Vendors mail the technical contact on the developer account. Zapier mails the owner of the Zap. Make surfaces the legacy flag inside the scenario to whoever opens it next. The connection was created by whoever clicked Connect, which was frequently one operations hire, two years ago, on a Thursday.

When that person leaves and IT deactivates the mailbox, the deprecation notice does not bounce to anyone useful. It bounces to nothing. This is the same structural problem behind automations that suddenly ask you to reconnect: the credential and the notice both belong to a human identity instead of to the business.

Two fixes, both boring. Connect integrations with a shared service identity on a distribution alias wherever the vendor allows it, so the credential and the mail both survive turnover. Where a vendor only supports a personal connection, write down whose it is, because that name is also the answer to "who is going to get the warning."

Build a deprecation register

This is the artifact worth making. One row per external system your automations touch, six columns, kept wherever your team already looks.

System	Workflow that calls it	How the step is built	Version in force	Notice lands with	End date published
Google Ads	Weekly spend report	HTTP node, version in URL	v24	Ads account technical contact	Yes, on Google's schedule
HubSpot	New lead to CRM	Zapier app step	App version 3.4.1	dana@, deactivated in March	No
Internal billing API	Invoice chase	Make custom app module	v2	Nobody	No

Filling the "version in force" column takes an afternoon and is the part that earns the exercise. In n8n you read typeVersion out of the exported workflow JSON. In Zapier it is on the step. In Make, legacy modules are flagged in the editor. For raw HTTP calls it is in the URL, a header, or the vendor dashboard. Until that column is filled in, you do not know what your automations are calling, only what you meant them to call.

The last column splits the work in two. Rows with a published date are a calendar problem. Put the date in a shared calendar, minus thirty days, assigned to a named person. That is the entire control, and it converts a future outage into a scheduled task.

Rows with no published date are drift rows, and a calendar does nothing for them. Those need a contract test: one scheduled workflow per integration that calls the endpoint with a known input, asserts that the three or four fields your automation actually reads are present, non-null, and the expected type, then alerts on any mismatch. It runs daily, costs one API call, and catches the exact class of change that never raises an error. It is the same discipline as alerting when an automation stops running, pointed at output shape rather than execution count, and it closes the gap that makes silent breakage so expensive to find after the fact. If you already pin your AI model versions for the same reason, this is that habit applied to the rest of your stack.

What to do this week

Take your three most revenue-touching automations and fill in one register row for each. Do not attempt the whole estate. For each row, answer two questions: which version is this actually calling, and whose inbox gets the warning. Most teams find at least one row where the answer to the second question is a deactivated mailbox, and that single discovery pays for the afternoon.

Then decide, per row, which failure you would rather have. A workflow that writes invoices should be pinned and calendared, because a loud stop beats eleven weeks of quietly wrong records. A workflow that enriches a lead with a nice-to-have field can float on the vendor's latest, because a shape change there costs you a blank field instead of a bad number. Making that call deliberately, one integration at a time, is the whole job.

If you want the register built and contract tests wired against an existing stack, that is where our workflow automation systems work usually starts. Or tell us what broke last time and we will tell you which of the two shapes it was.