HubSpot API Migration: v1-v4 and Legacy Apps End in September 2027

HubSpot is retiring its numbered APIs and legacy apps. Creating a new legacy private app stops on 26 October 2026, Pipelines v1 stops on 4 December, and everything on v1 to v4 is unsupported from September 2027. Here are the dates, how to find what you use, and how to plan the work.

Hugo Matthaey

Hugo Matthaey

Oct 23, 2026

An old stone bridge crumbling at one end next to a new bridge being completed by a crane, both linking a building of contact cards to business tools, with a calendar marking the deadline

HubSpot is ending support for its numbered APIs (v1 to v4) and its legacy public and private apps in September 2027, replacing them with date-based API versions and Developer Platform projects (HubSpot changelog, migration guide). Two dates come first: from 26 October 2026, existing accounts can no longer create a new legacy private app, and on 4 December 2026 the Pipelines v1 API stops. If your website forms, ERP sync, billing tool or internal scripts talk to HubSpot through code someone wrote years ago, that code is on the clock. Below: the dates, how to find what you use, and how to plan the migration.

The dates

DateWhat changes
30 March 2026HubSpot REST APIs move to date-based versions (/2026-09/, and so on)
28 September 2026Accounts created from this date cannot create legacy private apps
14 October 2026HubSpot-hosted domains require TLS 1.2
26 October 2026Existing accounts can no longer create new legacy private apps (existing ones keep working)
4 December 2026Pipelines API v1 is no longer supported
September 2027v1 to v4 APIs, legacy public apps and legacy private apps lose support

Reports differ on v4: one third-party guide gives 30 March 2027, while HubSpot's own migration guide lists v4 under September 2027. If you depend on v4 endpoints, check HubSpot's changelog for them specifically.

Date-based versions also change the rhythm after the migration. HubSpot ships breaking changes in March and September, and each dated version is supported for 18 months. An integration that is never touched again will fall off support again. Plan for a small upgrade every year or so, not one big migration per decade.

What actually breaks

  • Integrations built on v1 and v2 endpoints. HubSpot says some of them have no exact date-based equivalent yet. These are the risky ones, because they may need a redesign rather than a new URL.
  • Custom code using a legacy private app token. It keeps working for now, but you cannot create a new legacy app after 26 October, and the app type itself loses support in 2027. The replacement for in-account integrations is Service Keys (Settings, then Integrations, then Service Keys), which bring scoped permissions, activity logging and key rotation with a 7-day grace period.
  • Anything that reads or writes pipelines through v1, from 4 December 2026.
  • Writes that used to slip through. From the 2026-09 version, HubSpot enforces the validation rules your admins configured on every CRM API write. An integration that used to push records your users could not save by hand will start getting errors once it moves to 2026-09.

Marketplace apps you installed are the vendor's problem, not yours. Code written for you, by an agency, a freelancer or your own team, is yours.

How to find what you use

  1. Ask HubSpot. In your account, go to Development, then Migrations, then APIs. It lists the legacy API calls HubSpot has seen recently.
  2. List your private apps. Settings, then Integrations, then Private Apps. Each one is an integration someone built. Note who owns it and what it feeds.
  3. Search the code. Look for /v1/, /v2/, /v3/ and /v4/ in HubSpot URLs, in every repository, serverless function, script and middleware that touches HubSpot.
  4. Do not forget the no-code layer. Zapier, Make or n8n steps that call HubSpot's API through a raw HTTP request are custom integrations too.

At the end you should have one table: integration, owner, endpoints used, and whether a 2026-09 equivalent exists.

How to migrate

HubSpot's guide is straightforward:

  • Same contract: change the path. /crm/v3/objects/contacts becomes /crm/objects/2026-09/contacts. Copy the full new URL, because the structure is not always the old one with a date swapped in.
  • Changed contract: map each request field, query parameter and response field to its 2026-09 counterpart.
  • No equivalent: redesign the flow around the endpoints that exist, or wait for HubSpot to fill the gap, with the risk that brings.
  • Test on a test account, not production, edge cases included: errors are similar to the old ones but not guaranteed to be identical.

Order the work by risk: v1 and v2 first, then anything with no equivalent, then the simple path changes.

Where we fit, and where we do not

We build and maintain API integrations between business systems: CRMs, accounting, ERPs and messaging. Our published prices: a half-day scoping workshop at $2,300 to $4,700, credited against the work, then $5,000 to $18,000 for a first integration flow in production, and from about $470 a month to keep it running. Examples of how we work are in our posts on the QuickBooks Web Connector and a WhatsApp-to-Salesforce reference architecture.

To be clear about what we do not have: we are not a HubSpot partner, and this migration is new for everyone, us included. What we bring is the method above, done carefully, on your code, with tests, before the deadline rather than the week it lands.

Related: build your own CRM, or keep HubSpot?, why sales reps don't use the CRM, and QuickBooks API integration.