How Do You Plan for a Vendor API Deprecation in Your Automations?

How do you plan for a vendor API deprecation in your automations?

Keep an inventory of every API version your automations call, put each vendor's deprecation dates on a shared calendar, and schedule the migration months before the cutoff. Deprecations are rarely a surprise. They become emergencies only when nobody owns the list of what depends on what.

Every automation stack is built on someone else's API. HubSpot, Airtable, Clay, Apollo, Slack, and the AI model providers all change their interfaces over time, and each one retires old versions on its own schedule. When a version goes away, the workflow that relied on it does not always fail loudly. Sometimes it just stops writing data.

This article is the planning routine I use for client automations. It is not glamorous. It is a spreadsheet, a calendar, and a test habit. But it is the difference between a planned afternoon of migration work and a Monday morning where leads stopped reaching the CRM three days ago.

Why are API deprecations a bigger risk in no-code automations?

Because the API version is often hidden. In Zapier, Make, or n8n, a prebuilt connector hides which endpoint it calls. In custom HTTP steps, the version sits inside a URL that someone typed once and nobody reads again. Either way, the dependency is invisible until it breaks.

Prebuilt connectors usually get updated by the platform, which helps. But many real automations mix connectors with raw HTTP requests, because the connector did not support a field or an action the team needed. Those raw requests are exactly where old API versions survive for years. They worked on the day they were built, and nobody had a reason to touch them since.

There is also the people problem. The person who built the workflow may have left, or may have been a freelancer on a short project. Without documentation, nobody knows the workflow depends on a specific version of a specific endpoint. That is why the first step in this routine is always the same: find out what you are actually calling.

What does a real deprecation timeline look like in 2026?

HubSpot is a useful example because it publishes its timelines clearly. On September 15, 2026, HubSpot announced the end of support for its v1 to v3 APIs, legacy public apps, and legacy private apps, all with a September 2027 enforcement date and a 12-month window to migrate.

HubSpot's developer changelog also says support for its v4 APIs ends on its own separate timeline, on March 30, 2027. So a team with a mix of older and newer HubSpot integrations is looking at two different deadlines within the next year, each affecting different endpoints.

HubSpot also moved to date-based API versioning. Its changelog says breaking changes now happen only twice a year, in March and September, and that each version gets 18 months of support instead of the previous 90-day minimum deprecation notice. That is a genuinely helpful change for planning. It means HubSpot work can sit on a predictable twice-yearly calendar. For other vendors, you still have to read their own policies one by one.

How do you build an inventory of API dependencies?

List every automation, every external system it touches, and the exact version or connector it uses for each call. One row per call is ideal. It sounds tedious, and it is, but it is a one-time cost that turns every future deprecation notice into a five-minute lookup.

I build the inventory in Airtable or a Google Sheet with a few columns: workflow name, platform, step name, vendor, endpoint or connector, API version, auth method, owner, and last tested date. For connector steps where the version is not visible, I record the connector name and note that the platform manages the version. That note matters, because it tells you which steps to watch in the platform's own release notes instead of the vendor's.

The inventory pays off in more than deprecations. It shows which workflows share credentials, which ones write to the same CRM fields, and which ones have no owner at all. I wrote about the credential side of this in where to store API keys in a no-code automation stack, and the same sheet supports both.

Where should deprecation dates live?

Put them on a shared calendar that the automation owner and the business owner both see, with reminders at six months, three months, and one month before each cutoff. A date buried in a vendor email is not a plan. A date on a calendar with a named owner is.

For each deprecation, I create one calendar event on the cutoff date and link it back to the affected rows in the inventory. The reminder events are where the work actually gets scheduled. Six months out, decide whether to migrate or retire the workflow. Three months out, build and test the new version in parallel. One month out, switch over and watch.

Subscribe to the sources that actually announce changes. Most vendors with serious APIs publish a developer changelog. HubSpot does. So do most of the platforms an automation stack depends on. Assign one person to skim those changelogs monthly and add anything relevant to the calendar. That person does not need to be technical. They need to be consistent.

How do you migrate without breaking live workflows?

Build the new version alongside the old one, run both against test data, compare the outputs, and only then switch the live trigger. Never edit a production workflow in place to change API versions. That is how a migration turns into an outage with no easy rollback.

In Make or n8n, that usually means duplicating the scenario or workflow, swapping the endpoints in the copy, and pointing the copy at a test record set. In Zapier, it means duplicating the Zap and keeping the original paused but intact. Field names and response shapes often change between API versions, so the comparison step is where you catch a mapped field that now comes back empty.

Keep the old workflow paused, not deleted, for a couple of weeks after the switch. If something odd shows up downstream, you can compare behavior directly. This is the same discipline I use for any change to a production automation, and it is covered in more depth in my piece on how to version an automation so you can audit runs.

What happens if you miss a deprecation date?

Sometimes nothing, at first, which is the dangerous part. HubSpot's changelog says unsupported versions may continue to function but are not guaranteed critical updates and may not remain stable or available. A workflow can keep running on borrowed time and then fail without warning.

That uncertainty is why I treat an unsupported version as broken even when it still works. You cannot plan around something that might stop on any given day. The longer it keeps working, the more processes quietly depend on it, and the bigger the blast radius when it finally stops.

The failure mode I worry about most is the silent partial failure. A request succeeds but one field is ignored, or a write lands in the wrong place, or a search returns fewer results than before. The workflow shows green. The data is wrong. Monitoring for errors does not catch this. Checking that the expected records actually arrived does.

How much notice do vendors actually give?

It varies by vendor and by product stage. HubSpot's breaking change policy says it aims to give 90 days notice for listed breaking changes to generally available products, while its newer date-based versions carry 18 months of support. Beta and preview products typically come with much shorter guarantees.

The practical lesson is to read the policy for each vendor you depend on and to treat beta endpoints with suspicion in production. If a workflow that matters to revenue depends on a beta API, it needs a fallback plan and a closer watch. Betas are useful for prototypes. They are risky foundations for lead routing or CRM writes.

For AI model APIs, the pattern is similar. Providers retire older models on their own schedules. If an automation names a specific model version, that name belongs in the inventory like any other dependency. I treat a model name exactly like an API version: something with an end date that someone must track.

Who should own deprecation planning?

One named person should own the inventory and the calendar, even on a small team. It can be the operations lead, the RevOps person, or the outside builder on a maintenance agreement. What matters is that a deprecation notice has an obvious place to land and an obvious person to act on it.

I have automations in production for Ajust, built on Airtable and WhaleSync, and for Kismet Health, built on HubSpot via Zapier. Both depend on vendor APIs that will keep changing, which is exactly why I think ownership of the dependency list has to be explicit. My rule is that the inventory and the calendar travel with the system whenever it changes hands.

If no one owns it, the default owner is whoever is on call when it breaks. That is the most expensive way to handle a deprecation, because the work happens under pressure, with no testing window, and often at the worst moment in a sales cycle.

What should you do next?

Spend an afternoon building the dependency inventory for your most important workflows, starting with anything that writes to your CRM. Then add every known deprecation date to a shared calendar with reminders, and name one owner who checks vendor changelogs each month.

If you use HubSpot, check now for anything calling v1 to v3 endpoints or v4 endpoints, since HubSpot has published 2027 dates for both. Those are the clearest deadlines on the board right now, and they give you plenty of time if you start this quarter.

I build and maintain the automations behind lead generation for B2B teams, and I think dependency planning belongs in every handover. If you want help mapping what your stack depends on, reach out and let's chat.