On 26 October 2026, HubSpot removed the option to create new legacy private apps from the settings of existing accounts. Nothing broke. That is exactly why this change is easy to ignore, and why I think it deserves an hour of attention this month.
The cutoff itself is minor, but it starts a migration with a September 2027 deadline and raises an inventory question many HubSpot accounts cannot answer today. Which systems hold a key to our CRM, what can each one change, and who is responsible for it?
Reviewed 27 October 2026. The facts below come from HubSpot’s developer changelog and documentation on that date. HubSpot can adjust dates and navigation, so check the linked pages before you schedule work.
What changed on 26 October
- A private app is a connection created inside your HubSpot account that gives another system a token, a long secret password, so it can read or write records in your CRM (the HubSpot database of contacts, companies and deals).
- A scope is one item on the list of what that token is allowed to touch, for example “read contacts” or “write deals”.
- A Service Key is HubSpot’s new account-level credential for integrations that only move data. A project-based app is an app built with HubSpot’s developer tools, needed when an integration does more than move data.
According to HubSpot’s private-app announcement, creating new legacy private apps was switched off on 28 September 2026 for new accounts and on 26 October 2026 for existing ones. Existing private apps are “not affected at this time”. For any new integration inside your account, HubSpot points to Service Keys, and to a project-based app when webhooks are needed (automatic notifications HubSpot sends to another system when a record changes).
The bigger date sits in a separate notice. HubSpot’s September announcement on legacy APIs and apps announces the end of support for legacy private apps, legacy public apps and versions 1 to 3 of HubSpot’s APIs (the interfaces other software uses to read and write HubSpot data), all with enforcement in September 2027. Unsupported means no more bug fixes, reliability or security updates; HubSpot does not say that these apps or endpoints are switched off on that date. The v4 APIs follow their own timeline: HubSpot ends support for them on 30 March 2027. Unsupported versions may keep responding for a while, but HubSpot no longer guarantees they stay stable or available. HubSpot also advises moving straight to the newer date-based API versions rather than using v3 or v4 as a stepping stone.
Dates to put in the maintenance calendar
- 26 October 2026: no new legacy private apps. Already passed.
- 8 January 2027: HubSpot’s developer command-line tool requires Node.js 22 or later. Only relevant if someone on your side uses the HubSpot CLI, for example to build project-based apps.
- 30 March 2027: end of support for the v4 APIs. HubSpot also asks that project-based apps built on platform version 2025.2 or older move to 2026.09 by March 2027.
- September 2027: enforcement for legacy private apps and v1 to v3 APIs. HubSpot names the month, not the day.
Why the quiet cutoff is the risky part
Legacy private apps could only be created by Super Admins, the users with full rights over the account, and they were often created by one person solving one problem. The token then went wherever the integration lived: an automation platform, a country team’s script, a configuration file on a server. The account knows the app exists. It rarely knows why, who asked for it, or whether anyone still uses what it produces.
That gap was manageable while a forgotten app could simply be recreated. If an undocumented integration fails in the middle of 2027, the fix is no longer “make a new private app”. It is a migration done under pressure, by someone who has to rediscover what the old connection did.
In an account used by several countries or business units, this multiplies. Each market tends to add its own connections over the years, set up by different admins with different habits. But a single-country company with one admin has the same problem in a smaller form: the only record of what the integration does is what its creator remembers.
Scopes add a second trap. What someone intended a credential to access and what it actually has saved are two different facts. When an integration starts failing with a permissions error, the tempting fix is to tick more boxes until it works. A register records the scopes actually saved, so any wider access has to be agreed deliberately.
The decision: does it move data, or does it add functionality?
HubSpot’s own guide to Service Keys draws the line in two sentences: Service Keys are for managing data. Project-based apps are for building functionality. I turn that into four questions, asked for each existing integration. The answers put it in one of three lanes, retire, re-key or rebuild, and a fourth, keep, for anything still in use and not yet scheduled.
| Question | If the answer is yes | Lane |
|---|---|---|
| Has it lost both its users and its business owner? | Plan to switch it off after checking with the teams that might depend on it. If someone still uses it, continue to the next questions. | Retire |
| Does it only read or write CRM records through HubSpot’s standard APIs? | Move it to a Service Key with only the scopes it needs. | Re-key |
| Does it need webhooks, a card inside the CRM record, an app page, or installation in other accounts? | It needs a project-based app, which means developer time. | Rebuild |
| Must it act as a specific user, seeing only what that user may see? | HubSpot’s user-level apps, made generally available in the Fall 2026 Spotlight, are designed for this. | Rebuild |
The fourth lane is keep until its lane date, and it always comes with a named owner. Keeping an integration is acceptable only if someone owns it.
Two practical notes. Many data-only integrations do not need a developer to re-key: an admin can create the Service Key and the system owner swaps the credential. And HubSpot still lists Service Keys as a public beta in its Fall 2026 Spotlight, so check their current status before planning a large move.
Build the integration credential register
The register is a simple table, kept wherever your team keeps operating documentation. It complements a register of installed Marketplace apps, which I described in assigning owners to connected apps. This one covers the credentials your own team created.
- Integration name and the business process it supports.
- Business owner, who decides whether it should exist, and technical contact, who can fix it.
- What it reads and what it writes, by object and key fields. The field ownership guide explains how to describe this.
- Credential type today: legacy private app, Service Key, project-based app or Marketplace app (a vendor-built integration installed from HubSpot’s App Marketplace).
- API versions called: v1 to v3, v4 or a date-based version. Your developer or the vendor can answer this.
- Scopes actually saved, copied from HubSpot rather than from memory.
- Teams or countries that depend on it.
- Lane and target date.
- Last rotation date and where the secret is stored: the name of the password manager or vault, never the value itself.
Where to find the evidence
HubSpot’s private apps documentation places legacy apps under Development, then Legacy apps. The Service Keys documentation places keys under Development, then Keys, then Service keys, while the private-app announcement and the Fall 2026 Spotlight both say Settings, then Integrations, then Service Keys. Look in both. Each Service Key has a “View logs” option, which helps confirm whether a connection is still used and what it calls.
Access rules to decide once
- Who may create keys. Super Admins and users with the “Developer tools access” permission can. Decide who should hold that permission, rather than inheriting it from older role settings. HubSpot’s user permissions guide lists the other developer features that come with that permission, so granting it for keys grants more than keys.
- Who approves a wider scope. Name one person per integration, usually the business owner, with the technical contact explaining why.
- How often to rotate. HubSpot recommends rotating Service Keys every six months and offers a seven-day window in which the old key keeps working.
- The account limit. HubSpot documents a combined limit of 100 project-based apps, Service Keys and MCP connectors (connections that let AI assistants work with HubSpot data) per account. A large multi-country account can approach it if every team creates its own.
An illustrative example: one account, three teams, four integrations
This example is illustrative, a common pattern rather than a specific company. A company runs one HubSpot account for its headquarters and two country teams. An afternoon of review finds four legacy private apps.
| Integration | What it does | Owner | Lane | Next step |
|---|---|---|---|---|
| Finance system sync | Reads and writes companies and deals. | Finance lead | Re-key | Create a Service Key with company and deal scopes only, switch, check the logs, delete the old app. |
| Quoting tool | Needs to know when a deal changes stage. | Sales operations | Rebuild | Needs webhooks, so a project-based app. Book developer time well before September 2027, earlier if it calls any v4 API. |
| Marketing bridge for one country | Created by a marketer who has left; token in an unknown automation; scopes wider than needed. | None, then the country marketing lead | Keep, then re-key | Assign the owner first, then re-key with reduced scopes and remove the old app. |
| Owner export script | Exports users to a file through an old numbered API version. Nobody reads the file. | None found | Retire | Confirm with the three teams, switch off, record the decision. |
In the third row, the first action is to assign an owner. Until somebody owns that integration, any scope change is guesswork.
Six-month checks that keep the register alive
A register that nobody reopens soon goes out of date. I would review it twice a year, and whenever an admin leaves.
- Any legacy private app still without a named owner or lane.
- Any key not rotated in the last six months.
- Any saved scope wider than the register says.
- Any integration still calling version 1 to 3 APIs, with its target date.
- Departing users: since the Fall 2026 release, deactivating a user warns when that person owns, installed or authenticated a connected app, and lets an admin reassign ownership first. Treat that warning as a prompt to update the register.
- The count against the 100-item account limit.
Before switching a re-keyed integration in production, test it the way you would test any release. The sandbox release testing checklist covers that step.
Start with the inventory, not the code
The 26 October change asks very little of you today. The September 2027 deadline asks for a decision about every connection to your CRM, and most of that work is organisational: finding owners, confirming purpose and agreeing who may grant access. If you do it while every integration still works, the technical changes can be scheduled instead of handled as emergencies.
Know who holds a key to your CRM.
The HubSpot & RevOps audit maps your integrations, their credentials and their owners, and gives each one a lane and a date.
Explore the HubSpot & RevOps audit →