What Should You Do When an API You Automate Against Changes?

What should you do when an API you automate against changes?

Find out what class of change it is before you touch anything. A renamed field, a new required parameter, a changed default, and a removed endpoint all look like the same broken automation and need completely different responses. Diagnose first, then decide whether to patch, pin, or rebuild.

Every automation you run is a bet that somebody else's software will keep behaving the way it did when you built it. That bet is usually safe and occasionally is not, and the day it is not tends to arrive without warning on a morning you had other plans.

I keep automations running in production for clients, including an Airtable and WhaleSync pipeline for Ajust that has handled more than twenty five thousand cases. This is the process I use when something underneath them moves.

What kinds of change actually break things?

Four, in rising order of pain. A field gets renamed. A parameter becomes required. A default value changes. An endpoint or a whole command surface is removed or replaced. The first three you can usually patch in an hour. The fourth is a rebuild.

A real example from the Webflow developer changelog shows what the fourth looks like in practice. CLI v2.0.0 raised the Node.js minimum version to 22.13.0 and renamed the webflow library commands to webflow devlink. Both are legitimate, well documented changes, and both will stop a script that assumed the old world.

The changed default is the sneakiest of the four, because nothing errors. Your automation keeps running, keeps reporting success, and quietly produces different results than it used to. This is the category that goes undetected longest and does the most damage before anyone notices.

How do you find out before your client does?

Subscribe to the changelog of every service you depend on, and treat that subscription as part of the build rather than as optional diligence. Most vendors publish changes in advance. The problem is almost never that nobody told you, it is that nobody was reading.

Keep a written list of every external service each automation touches, with a link to its changelog. When you have fifteen automations across six services, nobody can hold the dependency graph in their head, and the list is what turns a vague worry into a ten minute monthly check.

The second detection layer is your own monitoring. A change that alters behaviour without erroring will only show up as a shift in your own numbers, which is why counting outcomes matters more than watching for failures. I covered the shape of that in what to log when an automation runs.

Should you pin to a version or follow the latest?

Pin, and upgrade deliberately. An automation that follows whatever the vendor ships today is an automation that can change behaviour on a day you were not working. Pinning turns a surprise into a scheduled task, which is the whole goal.

The cost of pinning is that you accumulate debt. A version you pinned two years ago and never revisited is its own risk, because the eventual upgrade spans many changes at once and is much harder to reason about than a series of small ones. Pin, then actually do the upgrades.

My rule is to review pinned versions quarterly and upgrade whatever has moved, one service at a time, with a test run before anything touches live data. One service at a time is the part people skip, and it is the part that makes a failure diagnosable.

What should you test before you trust the fix?

Run the automation end to end against real shaped data that you do not mind corrupting, and check the destination record rather than the success message. A patch that satisfies the API and writes the wrong value is worse than a patch that fails loudly.

Test the edge cases that the change touches specifically. If a parameter became required, test what happens when your source data does not have it. If a field was renamed, test a record where the old field was empty. The failure you are looking for is almost always in the absence of data rather than in its presence.

Keep a small set of test records permanently, rather than creating them each time. Having a known input whose correct output you already know turns verification from a judgement call into a comparison, and it makes the next emergency considerably calmer.

When is the right answer to rebuild rather than patch?

When the patch requires you to work around the vendor's intention rather than with it. If the new version wants you to do something a different way and you are contorting your existing flow to avoid that, you are building the next breakage into today's fix.

The other signal is the number of patches. A workflow you have patched three times against the same service is telling you something about its design, and the fourth patch is usually more expensive than the rebuild you have been avoiding. I treat the third patch as a decision point rather than a task.

Rebuild deliberately when you do rebuild. The temptation under time pressure is to reproduce exactly what existed, which reproduces the assumptions that made it fragile. An hour spent asking whether the workflow should still work this way is the most valuable hour in the whole exercise.

How do you roll back if the fix makes things worse?

Know the answer before you deploy. For most automation platforms that means having the previous version saved somewhere outside the platform, because relying on a tool's own version history to rescue you is a plan you have not tested.

Export the working configuration before you change it, every time, and keep the export with a date. This takes two minutes and it is the difference between a bad afternoon and a bad week. I have needed it rarely and been extremely grateful each time.

Decide in advance what rollback means for data as well as configuration. Reverting the automation does not un-write the records it wrote incorrectly, and the cleanup is usually the larger job. Knowing which records were touched in the window is exactly the thing a proper run log gives you.

What do you tell the client, and when?

Tell them the same day, before they notice, with three facts: what changed, what it affected, and what you are doing about it. A client who hears about a breakage from you is dealing with a professional. A client who discovers it themselves is dealing with a risk.

Be specific about scope, including when the scope is small. Saying that the change affected eleven records over two hours and has been corrected is a much better message than saying there was an issue that is now resolved, because the first one lets them stop worrying and the second one does not.

If the automation belongs to the client rather than to you, this is also the moment the handover documentation earns its keep, because they need to know what to watch for next time. I set that up deliberately at the end of a build, which I described in how to hand an automation over to the client.

What should you do next?

List every external service your automations depend on and find the changelog for each one. If that list takes more than fifteen minutes to write, that is itself the finding, because it means nobody currently knows what you are exposed to.

Then export the current working configuration of your most important automation and put it somewhere dated. It is the cheapest insurance available and the thing you will most want to have on the morning something moves underneath you.

If you have automations you depend on and no plan for the day a vendor changes something, I am happy to look at what you are exposed to. Reach out and tell me what they connect to.