HubSpot Private App Creation Ends Today: What Should RevOps Do?

Can you still create a HubSpot private app after October 26, 2026?

No, not the legacy kind. HubSpot's developer changelog says legacy private app creation is disabled for existing accounts on October 26, 2026. Accounts created on or after September 28, 2026 lost the option on that earlier date. Apps you already have keep running. Only the ability to create new ones goes away.

HubSpot announced this in its developer changelog on August 27, 2026. If you run revenue operations, this is the kind of change that does not break anything today and still catches teams out a month later. The break comes when someone needs a new integration in a hurry and the button they used last year is gone.

I build and maintain CRM automations for B2B teams, including the HubSpot setup I run for Kismet Health through Zapier. So I read this change the way an operator would. What stops working, what still works, and what should you set up before the next request lands on your desk.

What exactly did HubSpot change?

HubSpot removed the option to create new legacy private apps from the account interface. The changelog states that all existing legacy private apps continue to work as they are. For any new integration that talks to the API inside one account, HubSpot now points you to Service Keys instead of a private app token.

A legacy private app was the quick way to give a script, a middleware tool, or a custom integration access to your HubSpot data. You picked scopes, copied a token, and pasted it into the tool. That speed is why so many portals have a long tail of private apps that nobody remembers creating.

The change fits a pattern. Earlier this year, HubSpot's changelog set June 23, 2026 as the date legacy public app creation ended for accounts opened before May 26, 2026. Private apps were always the next obvious step. HubSpot's own legacy apps documentation already said these apps are still supported but do not get the latest app features.

What are Service Keys and how do they differ from private app tokens?

Service Keys are HubSpot's replacement for in-account API access. According to the changelog, you create them under Settings, then Integrations, then Service Keys. HubSpot describes them as offering scoped access, built-in activity logging, and a seven-day grace period when you rotate a key. Key values are restricted to admins by default.

The practical difference is governance. A private app token was easy to create and easy to forget. Activity logging means you can see what a key is doing. A rotation grace period means you can swap a key without a hard cutover where every connected tool fails at the same second.

The admin restriction matters more than it looks. In many portals, anyone with the right permission could generate a token and paste it into a personal tool. Putting key values behind admin access by default pushes credential handling back to the people who should own it.

Does this break any of your current integrations?

No. HubSpot's changelog is explicit that existing legacy private apps continue to work as they are. Your current syncs, scripts, and middleware connections keep running. The risk is not a sudden outage. The risk is that your next integration request will follow a different setup path, and your team may not know it yet.

That is why I treat this as a process change rather than a technical emergency. Nothing in your stack is on fire. What changed is the default answer to "how does this new tool connect to HubSpot", and that answer now lives in a different settings menu with different rules about who can see a key.

The quiet danger is a rushed workaround. When a sales leader needs a new enrichment tool connected by Friday and the old route is gone, someone will look for the fastest path. I would rather you decide that path now, while there is no deadline pressing on you.

Why should a RevOps team care about a developer changelog entry?

Because RevOps owns the systems that run the go-to-market motion, and integrations are where those systems connect. Lead routing, enrichment, scoring, and reporting often depend on a private app token somewhere in the chain. A change to how those tokens are created is a change to how your revenue stack grows.

My guess is that most RevOps teams never open the HubSpot developer changelog. They read product release notes and the occasional announcement email. Changes like this one land in the developer feed first, which is why they surprise operators who are not engineers.

My view is simple. If your pipeline depends on HubSpot, someone on the revenue team should skim the developer changelog once a month. It takes ten minutes. It is the cheapest early warning system you will ever set up for your go-to-market engineering stack.

What should you audit in your HubSpot portal this week?

Start with an inventory of every legacy private app in your portal. For each one, record what it connects to, which scopes it holds, who created it, and who owns it today. Any app with no clear owner or no known purpose goes on a review list before anything else happens.

This audit is overdue in most portals regardless of the HubSpot change. Private apps pile up. A contractor builds one for a migration, a former employee builds one for a reporting script, and an old enrichment vendor still holds a token with write access to contacts. I wrote about the hidden cost of this in my piece on the cost of an automation nobody owns, and private apps are a textbook example.

Next, check scopes. A token that only needs to read deals should not be able to write contacts. Then check where each token is stored. If the answer is a spreadsheet, a chat message, or a personal password manager, that is the first thing to fix, whether or not you ever migrate the app.

Should you migrate existing private apps now or wait?

Wait on stable apps, act on risky ones. HubSpot says existing legacy private apps keep working, so there is no forced deadline for migration in this change. I would migrate first any app with broad scopes, no clear owner, or a token stored somewhere insecure. Leave well-documented, narrowly scoped apps for a planned window.

HubSpot does recommend moving existing legacy private apps to its newer Developer Platform Projects framework over time. I take that as a clear signal of direction. Legacy tools that are "still supported" tend to fall further behind each year, and the gap shows up as missing features rather than outages.

The worst migration is a panicked one. Pick a quiet week, migrate one low-risk integration end to end, and write down every step. That first run becomes the playbook for the rest. If you cannot describe the steps clearly after one migration, you are not ready to do ten.

What about integrations that need webhooks?

HubSpot's changelog points integrations that need webhooks to its "Create an app" guide rather than to Service Keys. If an integration listens for HubSpot events, such as a deal stage change or a new contact, plan for the newer app setup path rather than assuming a Service Key covers it.

This split matters for lead routing and reporting automations. Many of the workflows that run a sales motion react to events. A deal moves to closed won, and a handoff starts. A contact hits a lifecycle stage, and an owner is assigned. Those event-driven pieces are exactly the ones that need the webhook path.

So when you inventory your private apps, add one more column. Does this integration only call the API, or does it also listen for events? The first group maps to Service Keys. The second group needs the app guide and probably a developer's time.

How should you document new integrations from here on?

Write a one-page record for every new Service Key or app at the moment it is created. Include its purpose, owner, scopes, the tool that uses it, where the key is stored, and the date it should be reviewed. Treat that record as part of the integration, not paperwork you add later if someone asks.

The activity logging that HubSpot describes for Service Keys helps, but logs do not tell you why a key exists. Only a human record does that. The record is what lets the next person decide whether to keep, rotate, or retire a key without guessing.

I use the same habit for automations in Zapier and Make, and I explained the naming side of it in how to name and document Zaps so someone else can fix them. The principle carries over. If a stranger cannot understand an integration from its record, the record is not finished.

What should you do next?

Do three things this week. Inventory every legacy private app and its owner. Decide who on your team is allowed to create Service Keys. Write a short internal note that tells anyone requesting a new HubSpot integration which path to use and who approves it. Then schedule migrations for your riskiest apps first.

This change is small on its own. Taken with HubSpot's earlier changes to legacy public apps and APIs, it says something clear about where the platform is going. If you have not reviewed your wider HubSpot stack for older dependencies, my earlier note on what GTM teams should audit as legacy HubSpot APIs reach end of support is a good companion to this one.

The teams that handle platform changes well are not the ones with the most engineers. They are the ones who know what they have, who owns it, and what each piece does. If you want help mapping your HubSpot integrations or planning a clean move to Service Keys, reach out. I am happy to take a look with you.