HubSpot API deprecation: v1–v3 unsupported, private apps next

HubSpot has set a date for its largest HubSpot API deprecation in years. Every endpoint under /v1/, /v2/ and /v3/ is now unsupported, along with legacy public apps and legacy private apps, with enforcement from September 2027. That sounds distant. The nearer date is 28 September 2026, when new HubSpot accounts can no longer create a legacy private app — the way most internal integrations have been set up for years.

What the HubSpot API deprecation covers

At its Fall Spotlight on 15 September, HubSpot published a developer changelog covering three changes that share one enforcement date, September 2027:

• v1–v3 APIs. Endpoints using numbered version paths move to unsupported status. HubSpot will release no further bug fixes, reliability improvements or security updates for them.
• Legacy public apps. Public apps created before 23 June 2026 use the pre-Projects architecture and must move to the Projects-based app model.
• Legacy private apps. Private apps built before the Projects-based private app model must migrate as well — a separate requirement from the public app change.

The v4 APIs have their own, earlier timeline: support ends on 30 March 2027, announced earlier this year.

The dates that matter

• 15 September 2026 — v1–v3 and legacy apps move to unsupported status. Developer home starts flagging affected apps.
• 28 September 2026 — legacy private app creation is disabled for new accounts.
• 26 October 2026 — legacy private app creation is disabled for existing accounts.
• March 2027 — HubSpot's date-based versioning release is due to include full per-endpoint replacement documentation for every legacy API.
• 30 March 2027 — v4 support ends.
• September 2027 — enforcement for v1–v3, legacy public apps and legacy private apps.

Will my existing HubSpot integration break?

Not on 28 September. Existing legacy private apps keep working; what stops is the creation of new ones. But from 15 September the endpoints they call get no fixes of any kind, including security fixes, and after September 2027 they are unsupported outright.

The integrations we see in mid-market CRM work are exactly the kind affected: website forms posting contacts, ERP or billing systems syncing deals and companies, custom dashboards reading pipeline data, and scripts someone wrote years ago with a private app token pasted into a config file. Most of them call v3 CRM endpoints, and many have no owner who remembers how they work.

One detail makes inventory easier than usual: HubSpot says its developer home detection checks runtime API calls, not source code. If something in your stack is still calling a legacy endpoint, it will show up — even if the code in your repository has been updated and an old deployment has not.

What replaces HubSpot private apps

For new system-to-system integrations, HubSpot now recommends Service Keys, part of its Developer Platform Projects. HubSpot positions them as the path for lightweight integrations, internal tools and AI agent integrations, without requiring a full OAuth backend. Existing legacy private apps must eventually move to Projects-based private apps.

In practice, that means an internal integration team should stop creating legacy private apps now, even in existing accounts where it is still allowed until 26 October. Anything created in the next five weeks is something you will migrate within a year.

How do I migrate a HubSpot integration to date-based versioning?

HubSpot's advice is explicit: migrate directly from any legacy version to date-based versioning (DBV), and do not use v3 or v4 as an intermediate step. Its migration guide covers endpoints where the response shape changes, not just the URL. A practical plan:

1. Inventory. Use the developer home tasks card and the migrations tab to list apps calling legacy endpoints, then match each to an owner and a business process.
2. Classify. For each integration, record which API versions it calls and whether it is a public app, a legacy private app or already Projects-based. Marketplace apps must satisfy both requirements: HubSpot says apps using v1–v4 after September 2027 lose certification, and apps still on legacy architecture become eligible for delisting.
3. Move auth first where it is simple. Replacing a legacy private app token with a Service Key or Projects-based app is usually smaller than rewriting the calls, and it stops new legacy apps being created.
4. Wait for documentation where it is missing. HubSpot says not all replacement paths are finalised; the March 2027 DBV release will document every legacy endpoint. Migrate what is documented now and schedule the rest.
5. Test response shapes. Where DBV changes payloads, run old and new calls side by side and compare. Silent mapping errors in a CRM sync are worse than a failed call.

If your integrations also receive HubSpot webhooks, check how they handle retries and duplicates while you are in there; our notes on webhook retry patterns apply to HubSpot as much as to Stripe.

Why a year is less time than it looks

Twelve months is generous for one integration and tight for twenty undocumented ones. The hard part is rarely the code change. It is finding every caller, working out what each sync is supposed to do, and testing it against data nobody wants to break. Teams that treat September 2027 as the start date will discover that the March 2027 documentation release leaves them six months for the endpoints that were not documented earlier.

We have seen the same pattern with other platform deadlines, from Android's developer verification cutoff to breaking changes in the MCP specification: the teams that finish comfortably are the ones that inventory in the first month.

If you need help finding and migrating your HubSpot integrations — or replacing brittle point-to-point syncs with something maintainable — our API development and integrations team does this work, and our CRM development practice can advise on whether HubSpot is still the right hub at all.