HubSpot used its September 15, 2026 Fall Spotlight to set a single enforcement date, September 2027, for retiring three things at once: every API endpoint still on a numbered /v1/, /v2/, or /v3/ path, every legacy public app in the Marketplace built before the current Projects-based architecture, and every legacy private app built the same older way. This is not the same event as the private app creation cutoff that already took effect on September 28 and October 26, 2026, which only blocked creating new legacy private apps and left existing ones running. The 2027 deadline is broader: it requires migrating the apps and API calls you already have, not just avoiding new legacy creation, and it adds Marketplace certification risk for any public app that does not move to the current architecture in time.
The Quick Answer
- What is retiring: numbered /v1/, /v2/, /v3/ API paths, legacy public apps, and legacy private apps
- When: September 2027 enforcement for all three, with v4 on its own earlier date of March 30, 2027
- Not the same as: the September and October 2026 cutoff, which only stopped new legacy private app creation
- What changed for existing apps: they now need to migrate architecture, not just stop creating new ones
- Highest stakes: a public app in the Marketplace that misses the deadline risks losing certification and listing
Two separate migrations, one shared deadline. Treat them as two checklists, not one.
The 2026 Cutoff vs the 2027 Sunset
| Factor | 2026 Private App Cutoff | 2027 Legacy Sunset |
|---|---|---|
| What is affected | Endpoints on /v1/, /v2/, /v3/ paths, plus pre-Projects public and private apps | Date-based versioning for APIs, Projects-based architecture for every app |
| Enforcement date | Support quietly thins out as HubSpot stops patching legacy versions | September 2027 for v1 through v3 and legacy apps, March 30, 2027 for v4 |
| Who is exposed | Any custom integration, agency-built app, or Marketplace listing still on the old model | Nobody, once API calls and app architecture are both current |
| Consequence of missing it | Silent breakage in custom integrations, possible Marketplace delisting for public apps | Continued support, security patches, and Marketplace eligibility |
| Relationship to the 2026 private app cutoff | That cutoff only blocked creating new legacy private apps | This deadline also requires migrating the private apps you already have |
Why it matters: a business that handled the 2026 cutoff correctly, by simply leaving its existing private apps alone, can still walk straight into the 2027 deadline unprepared, because this one requires action on apps that were previously safe to ignore.
1. What HubSpot Announced at Fall Spotlight
HubSpot's Fall 2026 Spotlight went live on September 15 during UNBOUND in Boston, alongside the Breeze Assistant relaunch covered in our Fall Spotlight guide. Buried in the same announcement, and easy to miss under the AI headlines, was a developer-facing change with a longer fuse: HubSpot set September 2027 as the date it stops supporting three separate categories of legacy infrastructure, all inherited from the platform's older architecture.
The three categories are endpoints on numbered API paths, public apps listed in the Marketplace before the current app model existed, and private apps built the same older way. HubSpot frames the two migration requirements, fixing API calls and modernizing app architecture, as independent of each other, which is the detail most coverage of the announcement glossed over.
Why it matters: a twelve-month runway feels comfortable until you remember that most Canadian SMBs and agencies only discover a HubSpot deprecation when something breaks, not when the changelog post goes live.
2. The API Track: Retiring v1 Through v3
Any endpoint still called through a /v1/, /v2/, or /v3/ path moves to unsupported status. HubSpot stops shipping bug fixes, reliability improvements, and security updates for those paths, and after September 2027 they stop working as a supported part of the platform. HubSpot's migration guidance is specific: move directly to date-based versioning, its current model where an endpoint's behaviour is tied to a release date rather than a static version number.
The trap here is treating v3 or v4 as a safe intermediate stop. v4 carries its own separate sunset of March 30, 2027, announced earlier in 2026, which is before the September 2027 date for the older versions. A team that migrates from v2 to v4 today is scheduling a second migration for early 2027 instead of doing the work once.
Why it matters: the fastest way to turn a twelve-month runway into a rushed rebuild is to land on a version that has its own earlier expiry date.
3. The App Track: Legacy Public and Private Apps
Since June 23, 2026, HubSpot has not allowed new public apps to be built on its older, pre-Projects architecture. Public apps built before that date keep running and keep their Marketplace listing for now, but they do not get current app features, and to remain certified and listed past September 2027 they need to migrate to the current Projects-based model.
Private apps face a parallel requirement, and this is the part that catches businesses who already dealt with the 2026 private app creation cutoff. That earlier change only stopped creating new legacy private apps, and existing ones were explicitly fine to leave alone. This September 2027 deadline goes further: private apps built before the Projects-based model existed need to migrate to it regardless of whether you ever plan to create another one.
Why it matters: the advice that was correct in 2026, leave your existing private apps alone, stops being sufficient advice for 2027. The two announcements sound similar and are not, and the second one asks for more work than the first.
4. Which AtlanticWorks Guide Actually Answers Your Problem
HubSpot has announced several overlapping changes to APIs, apps, and integrations in 2026. Use this table to land on the right one before you scope any migration work.
| If your problem is | Read |
|---|---|
| New legacy private app creation was disabled in September and October 2026 | HubSpot Private Apps Sunset |
| Existing private apps, public apps, and old API versions all need to migrate by September 2027 | This article |
| Building custom AI automation on HubSpot's current API and agent tooling | Custom AI Automation Inside HubSpot |
| Authenticating AI agents and MCP connectors against HubSpot | HubSpot MCP and AI Connectors |
| Where native HubSpot sync ends and a custom integration begins | HubSpot Operations Hub and Data Hub |
Why it matters: most Canadian HubSpot portals will end up needing more than one of these guides, since the creation cutoff, the architecture migration, and the API version migration are three separate pieces of work with three different deadlines.
The Two-Track Audit to Run Now
Five steps, run as two parallel tracks rather than one sequential list.
Grep every codebase for numbered API paths.
Search integrations, scripts, and middleware for calls to /v1/, /v2/, /v3/, or /v4/ HubSpot endpoints. This is a text search any developer can run in an afternoon, and it tells you the true size of the API migration before you touch any app architecture.
Inventory every app in the portal, public and private.
List each private app and each public app your business built or lists in the Marketplace, then check whether it was created before or after the Projects-based model existed. HubSpot's own developer changelog and app settings show which architecture each app runs on.
Treat the two migrations as separate projects.
Fixing API calls does not fix app architecture, and migrating architecture does not fix API calls. Track them as two checklists so a team does not close out one and assume the deadline is handled.
Migrate straight to date-based versioning.
Skip v3 and v4 as a landing spot. HubSpot's guidance is to jump directly from a legacy numbered version to DBV, since v4 has its own earlier sunset of March 30, 2027.
Prioritize any app listed in the Marketplace.
A Marketplace listing that misses the architecture migration risks delisting, which is a revenue and reputation event, not just a technical one. If your business distributes a HubSpot app, this is the piece to move first.
Why it matters: because the two tracks are independent, closing out only one of them leaves a business exposed to the part it did not touch, whether that is a silently failing API call or a delisted Marketplace app.
5. Why Marketplace Apps Should Move First
A private, internal integration that quietly stops working is a technical problem you fix on your own timeline. A public app that loses Marketplace certification is a business problem: it disappears from the channel customers use to find and install it, with a direct hit to revenue and reputation for any Canadian software vendor or agency distributing an app that way.
If your business has both a Marketplace listing and internal integrations to migrate, sequence the Marketplace app first. It carries the harder external deadline, and the discipline it forces, auditing architecture and API calls together, transfers directly to the internal work that follows.
Why it matters: not every legacy dependency carries the same cost of delay, and sequencing the highest-stakes one first is how a twelve-month runway actually gets used well.
How AtlanticWorks Helps
As a certified HubSpot partner, AtlanticWorks audits Canadian HubSpot portals for exactly this kind of layered deprecation: which API calls still hit a numbered version path, which public and private apps still run on the pre-Projects architecture, and which of those carries a Marketplace certification risk versus a purely internal one. We sequence the migration so the highest-stakes piece, typically a public app, moves first, and we build the replacement using HubSpot's current tooling, the same modern foundation behind our custom AI automation and MCP and AI connector work. The free assessment is the fastest way to find out how exposed your portal actually is before September 2027.
Key Takeaways
- HubSpot's September 15, 2026 Fall Spotlight set September 2027 as the enforcement date for retiring /v1/, /v2/, and /v3/ API paths, legacy public apps, and legacy private apps, all at once but on independent tracks.
- This is broader and later than the September and October 2026 private app creation cutoff, which only blocked creating new legacy private apps and left existing ones untouched.
- This deadline requires migrating the private and public apps you already have, not just avoiding new legacy creation.
- v4 has its own earlier sunset, March 30, 2027, so migrate directly to date-based versioning rather than treating v3 or v4 as a stopover.
- A legacy public app that misses the architecture migration risks losing HubSpot Marketplace certification and listing.
- Fixing API calls and migrating app architecture are independent requirements. Passing one does not satisfy the other.
Frequently Asked Questions
What did HubSpot actually announce on September 15, 2026?
At its Fall 2026 Spotlight during UNBOUND in Boston, HubSpot announced the end of support for three separate things at once: every API endpoint still using the numbered /v1/, /v2/, or /v3/ path, every legacy public app built on HubSpot's pre-Projects architecture, and every legacy private app built the same older way. All three carry the same enforcement date, September 2027, but they are independent tracks that fail independently, not one bundled change.
What happens to APIs using the /v1/, /v2/, or /v3/ paths?
Those endpoints move to unsupported status. HubSpot stops shipping bug fixes, reliability improvements, and security patches for them, and after September 2027 they are unsupported outright. The recommended path is to migrate directly to date-based versioning rather than treating v3 or v4 as a stepping stone, since v4 has its own separate sunset date of March 30, 2027 and is not a safe place to land.
Is this the same as the private app creation cutoff from September and October 2026?
No, and conflating the two is the most common mistake we see. The September 28 and October 26, 2026 dates only removed the ability to create a brand new legacy private app through the account UI. Existing private apps kept running untouched. This September 2027 announcement is broader and later: it requires every legacy private app you already have, not just new ones, to migrate to the Projects-based architecture, and it adds legacy public apps and the old numbered API versions to the same deadline.
What is a legacy public app, and why does it matter for Marketplace certification?
A legacy public app is any app listed in the HubSpot App Marketplace that was built before June 23, 2026 on HubSpot's older, pre-Projects app architecture. As of that date, no new apps can be built that way. Existing legacy public apps keep working for now but do not get current app features, and to remain listed in the Marketplace and keep certification past September 2027, they need to migrate to the current Projects-based model. Missing that window risks delisting, which is a direct hit to any Canadian agency or software vendor that distributes an app through HubSpot.
Does my existing private app need to be rebuilt even if I am not creating new ones?
Yes, and this is the detail the 2026 creation cutoff did not require. Private apps built before the Projects-based private app model existed need to migrate to that model by the September 2027 enforcement date, regardless of whether you plan to create any new ones. Simply leaving an old private app alone, which was the safe move during the 2026 creation cutoff, is no longer enough on its own for this broader deadline.
What is date-based versioning, and why not just move to v3 or v4 first?
Date-based versioning, or DBV, is HubSpot's current API versioning model, where an endpoint's behaviour is tied to a release date rather than a static version number like v1, v2, or v3. HubSpot's own migration guidance is to move directly from a legacy numbered version to DBV. Routing the migration through v3 or v4 first adds a rebuild step you will have to redo almost immediately, since v4 support ends March 30, 2027, well before the September 2027 date for the older versions.
What should a Canadian HubSpot partner or SMB do before September 2027?
Run two separate audits, because the two migration requirements are independent and neither one covers the other. First, search every integration's codebase for calls to /v1/, /v2/, /v3/, or /v4/ endpoints and plan the move straight to date-based versioning. Second, inventory every public and private app in the portal and confirm whether each was built on the current Projects-based architecture or the older model, since an app that only fixes its API calls but stays on the legacy architecture can still lose Marketplace certification, and an app that migrates architecture but keeps calling unsupported API versions can still break.
Related Resources
The 2026 cutoff on creating new legacy private apps
Breeze Assistant, Deal Progression, and everything else announced September 15
Modern authentication for AI-driven integrations
Where native sync ends and a custom integration begins
Not sure how exposed your HubSpot portal is?
AtlanticWorks audits your API calls and your public and private apps against the September 2027 deadline, then sequences the migration so your highest-stakes dependency, usually a Marketplace listing, moves first. The free assessment is the place to start.
Start the Assessment