HubSpot Is Ending Support for v1 to v3 APIs. What Should GTM Teams Audit First?

What did HubSpot actually announce about legacy APIs?

On September 15, 2026, HubSpot announced on its developer changelog that v1 to v3 APIs, legacy public apps, and legacy private apps will lose support, all with a September 2027 enforcement date. HubSpot says teams using any of these have a 12-month window to migrate to date-based API versions.

The post is short, but the consequences are not. Almost every GTM stack I have touched has at least one quiet connection into HubSpot that someone built years ago and nobody has opened since. A form handler, an enrichment push, a reporting sync, a lead router. Those are the pieces this announcement is really about.

This is not a reason to panic. It is a reason to make a list. You have a year, and a year is plenty if you start with an inventory instead of a rewrite.

What does "unsupported" mean for an integration that still works today?

HubSpot defines it plainly: it "will no longer release bug fixes, reliability improvements, or security updates for these versions." Nothing in that sentence says your integration breaks on a given morning. It says that when something goes wrong after the deadline, nobody at HubSpot is obligated to fix it for you.

That distinction matters for how you prioritize. An unsupported endpoint is a slow risk, not an outage. The danger is that it fails at a bad moment, like the week of a launch, and the fix becomes an emergency migration instead of a planned one.

My view is simple. Treat September 2027 as the date the safety net disappears, not the date the floor disappears. Plan to be off legacy versions well before it, so the deadline passes as a non-event.

Which dates matter before September 2027?

Three earlier dates sit inside the window. HubSpot disables legacy private app creation on September 28, 2026 for new accounts and October 26, 2026 for existing accounts. The Pipelines API V1 is sunset on December 4, 2026. And the 2026-09 API version enforces validation rules on CRM writes.

The October 26 date is the one most teams will feel first. If your habit is to spin up a quick private app whenever you need a token for a new Zap or script, that habit stops working in existing accounts that week. HubSpot names Service Keys as "the recommended path for lightweight integrations, internal tools, and AI agent integrations."

The Pipelines API V1 sunset is narrower but sharper. If anything in your stack reads or writes deal pipelines through that version, it has a shorter runway than the rest of this list. Check it first.

The validation change is the sleeper. HubSpot says that starting with the 2026-09 API version, it "will enforce admin-configured validation rules on all CRM API write paths." That means a migration can surface bad data your old integration was quietly pushing past your own rules.

How do you find every place your stack calls a legacy HubSpot API?

Start inside HubSpot, then work outward. HubSpot's migration guide points to an in-app Migrations tool under Development that flags legacy API usage. Use that list as your first draft, then search your own code, scripts, and automation tools for legacy paths, because the tool only sees what HubSpot can see.

I build the inventory as a simple spreadsheet with one row per connection. The columns are the system, what it does, which object it touches, who owns it, whether it is custom code or a vendor connector, and whether it writes data or only reads it. That last column decides the order of work.

Search your code for strings like "/v1/", "/v2/", and "/v3/" in HubSpot URLs. Then open every automation tool you use, whether that is Zapier, Make, or n8n, and list each step that talks to HubSpot. Custom webhook and HTTP request steps are the ones to flag, since those are where hand-written legacy paths hide.

Do not forget the scripts that live outside any tool. A Python job on a cron schedule, a Google Apps Script attached to a sheet, a serverless function that a contractor wrote. These are the connections that surprise people, because they were never in anyone's system of record.

Which integrations should you migrate first?

Migrate anything that writes to the CRM before anything that only reads from it. Writes touch contacts, deals, and ownership, so a silent failure corrupts data that sales relies on. Reads usually feed reports, and a broken report is visible and recoverable. Within writes, start with lead capture and routing.

My order looks like this in prose. First, the path from your website forms into HubSpot, because every lost submission is a lost lead. Second, lead routing and owner assignment, because a mis-assigned lead is a lead nobody calls. Third, enrichment writes from tools like Clay or Apollo, because they touch many records at once.

After that come the pipeline and deal integrations, with anything on the Pipelines API V1 pulled to the front because of its December date. Reporting syncs into a warehouse or a Google Sheet come last. They matter, but when they break you notice quickly and nothing downstream is overwritten.

One honest caveat. If a connection is built on a vendor's native connector rather than your own code, the migration is mostly the vendor's job. Your job is to confirm with that vendor's own documentation that they have moved, and to know who to ask if they have not.

What does the move to date-based versions look like in practice?

HubSpot is replacing v1, v2, and v3 style paths with versions tied to release dates, using a prefix formatted as YYYY-MM. Its migration guide shows a contacts path moving from /crm/v3/objects/contacts to /crm/objects/2026-09/contacts. For many endpoints the change is the path, but some request and response shapes also differ.

That last point is where migrations go wrong. A path swap that returns a 200 status can still break your automation if a field moved or a response is shaped differently. HubSpot's guide says as much, and recommends comparing each legacy endpoint with its 2026-09 counterpart before changing anything.

The guide also recommends testing every migrated path, ideally in a test account so production data is not touched. I would go one step further and run the old and new versions side by side on the same input for a week. If the outputs match, switch. If they do not, you just found the bug before your sales team did.

How does the validation change affect lead routing and enrichment?

Once your integration calls the 2026-09 version, HubSpot enforces the validation rules your admins configured on every CRM write. Records your old integration created without complaint may now be rejected. That is good for data quality, but only if your automation notices the rejection instead of dropping the record.

Think about an enrichment step that writes a phone number in a format your admin rules forbid, or a routing step that sets a required property to an empty value. Under the old behavior those writes may have slipped through. Under the new one they can fail, and a lead without an owner is a lead that sits.

The fix is not to loosen your rules. It is to give every write an error path. When HubSpot rejects a record, the automation should log the reason, keep the original data, and alert a person. I have written before about what to do when an API you automate against changes, and this is a textbook case.

What should you change about how you create HubSpot credentials?

Stop treating private apps as the default way to get a token. With legacy private app creation disabled in existing accounts from October 26, 2026, new integrations need a different path, and HubSpot recommends Service Keys for lightweight integrations, internal tools, and AI agent integrations. Plan new builds around that now.

This is also a good moment to clean up the credentials you already have. Most portals I audit carry tokens nobody can explain. Before you migrate anything, list every active token, match it to a row in your inventory, and retire the ones with no owner. My guide on rotating API keys without breaking your Zaps covers the sequence I use so nothing goes dark mid-swap.

If you sell or maintain an app on the HubSpot Marketplace, the stakes are higher. HubSpot says apps on unsupported API versions after September 2027 lose certification status, and apps still on legacy architecture become eligible for delisting. That is a revenue problem, not just a technical one.

Is this the same as HubSpot's earlier legacy public app change?

No. Earlier in 2026 I wrote about a narrower HubSpot change that affected how legacy public apps get created. This September 2026 announcement is broader in scope. It sets an end of support for v1 to v3 APIs and both kinds of legacy apps, and it puts a single enforcement date on all of them.

If you read my notes on the earlier legacy public apps change, think of this as the second half of the same direction. HubSpot is moving every integration toward Projects, date-based versions, and new credential types. The earlier change closed a door for new builds. This one sets a date for existing ones.

That pattern is worth noticing as a GTM operator. Platforms you build revenue systems on will keep doing this. The teams that handle it calmly are the ones who already know what they have connected and who owns each piece.

What should you do this month?

Build the inventory before you change any code. List every connection into HubSpot, mark which ones write data, flag anything on the Pipelines API V1, and note which credentials were created as legacy private apps. Then set an internal migration deadline months ahead of September 2027, not on it.

For most teams I work with, the real work is not the migration itself. It is finding the connections. I have one client, Kismet Health, whose HubSpot runs through Zapier, and even a clean setup like that deserves a fresh look when the platform underneath changes its rules.

If you want a second pair of eyes on your HubSpot integrations, or help planning the migration so it lands well before the deadline, reach out. Let's chat about what your stack looks like and where the risk actually sits.