Integrations19 min readPublished October 2026

Every HubSpot integration guide starts with a button that is being taken away

HubSpot stopped letting new accounts create private apps on 28 September, and existing accounts lose the same button on 26 October. Nothing you already run stops working, but every tutorial, every runbook and every plan that begins with creating a private app has a deadline on it now.

The first step that is about to stop existing

Search for how to connect HubSpot to n8n, to a script, to anything that is not on HubSpot's marketplace, and step one is always the same sentence: create a private app in HubSpot and copy the access token.

On 28 September, that stopped being possible for new HubSpot accounts. On 26 October, it stops being possible for everyone else.

Your existing integrations are fine. This is not an outage waiting to happen, and anybody telling you that private apps are being switched off has misread the announcement. What expires is the ability to make a new one — which is a smaller change with a wider blast radius, because it invalidates every set of instructions anyone has ever written for connecting HubSpot to anything.

What HubSpot announced, and to whom

The announcement is a changelog post from 27 August, and the first line defines the scope precisely:

HubSpot is permanently removing the ability to create new legacy, non-Project based, private apps through the account UI. Users needing similar functionality should use Service Keys, available via Developer Platform Projects version 2026.09 or later, which supports system-to-system integrations. This sunset impacts customer accounts on two timelines based on their age.

The two timelines, from the same post:

AccountPrivate app creation disabled
Created on or after 28 September 202628 September 2026
Created before 28 September 202626 October 2026

If you have had HubSpot for any length of time, the date that applies to you is 26 October. That is thirty-two days of notice for the first group and sixty for the second, published in a developer changelog.

Before you go looking for the button in your own account: it has already been renamed. HubSpot's current documentation describes the path as Development, then Legacy apps, then Create legacy app, then Private. So a tutorial that says "go to Settings and click Create private app" is already wrong, weeks before the deadline that will make it permanently wrong. And that documentation page carries no deadline at all — no 28 September, no 26 October, no mention of a sunset. Its footer says it was last modified on 7 August, three weeks before the announcement. It only says that legacy apps "are still supported by HubSpot, but don't have access to the latest app features".

Nothing you already run stops working

Get this distinction right. "Creation is disabled" and "apps are disabled" are a calendar entry and a crisis respectively, and only the first one is happening. HubSpot's own words, under a bolded line that reads "What is not changing":

All existing legacy private apps continue to work as-is. This change only removes the ability to create new ones.

  • same changelog post

All and only are doing real work in that sentence, and both point the same way. No workflow stops on 26 October. No token is revoked. What you lose is the ability to issue another one.

There is a weaker version of the same promise in the lead paragraph of that post, and the difference matters: "All existing legacy private apps are not affected at this time."

How long "at this time" lasts is not a matter of speculation here, because HubSpot ran this exact play four months earlier. When it announced the same closure for legacy public apps in April, it said:

Existing legacy public apps are not affected by this change. They will continue to function as-is. Existing or new legacy private apps are also not affected at this time.

The second half of that sentence was true when it was written and stopped being true 126 days later. The dates line up almost exactly across the two announcements: 23 April to 27 August is 126 days, and each pair of rollout dates sits 125 days apart. This is a schedule, not a series of surprises.

Read "at this time" as a date you have not been told yet. Existing private apps are safe for now, and there is no announced plan to switch them off. But the same phrase, about the same objects, expired once already this year.

The replacement is in beta and cannot do webhooks

HubSpot's answer to "what do I use instead" is Service Keys, and it is worth knowing two things about them before you plan around it.

The documentation page is titled "Make API requests using a service key (BETA)", and carries the standard warning that the functionality "is still under active development and is subject to change based on testing and feedback". That beta opened on 10 February. It has been open for close to eight months.

The second limit is more consequential:

You cannot use service keys to authenticate webhooks, make calls within a UI extension, or leverage other developer platform functionality other than making REST API requests. If you want to leverage these features, you should create an app and use its static access token or OAuth access token to make API requests instead.

Now put that next to the February announcement of the same feature, which is still live and still says this:

Service Keys do not support webhooks. If your integration requires webhooks, you must use a project-based app created with the HubSpot CLI, or continue using a legacy private app.

The escape hatch that post offers — keep using a legacy private app — is the thing the August post closes. If you need webhooks and do not have a private app already, then after 26 October that second path is closed to you as well, and what remains is building a project-based app with HubSpot's command-line tooling. That is a different kind of job from pasting a token into a field, and it is the part of this change most likely to turn a small integration into a real project.

On the wire, though, for everything that is not webhooks, the swap is trivial. A service key is sent exactly like a private app token — as Authorization: Bearer pat-… — so the code and the platform configuration do not change. The credential value does.

What this looks like in n8n

n8n saw this coming and relabelled things back in April, four months before HubSpot's announcement. The pull request that did it says why:

HubSpot has moved UI-created private apps to legacy status and now recommends service keys as the replacement. The n8n credential label should reflect current HubSpot terminology.

The internal names were left alone, so nothing broke, and the practical consequence is that the migration in n8n is a one-field edit. n8n's own documentation spells out where to get the new value: Development, then Keys, then Service Keys. From there it says to "copy the key value using the copy button, and paste it as the App Token in your n8n credential". Same field, same node, same workflow.

Two things are worth checking while you are in there.

First, the authentication dropdown on the HubSpot node still opens on API Key. That is the method HubSpot removed on 30 November 2022, and the n8n credential for it says so in its own description. It is nobody's live setup at this point, but it is what a person adding the node today sees first, which is how a workflow ends up on a method that died years ago. The option you want is called Service Key, and it holds both kinds of token.

Second, if your HubSpot connection is OAuth2, none of this applies to you. That path is untouched by both announcements.

The door that closed in June, and who walked into it

There is a second HubSpot credential in n8n, and it belongs to the wave that already happened. The HubSpot Trigger node accepts exactly one credential type, which needs a Developer API Key and an App ID. Those come from a public app rather than a private one, and HubSpot stopped letting anyone create legacy public apps on 23 June.

Somebody hit this in August, and the thread is a clean picture of what that feels like from the inside:

the problem is when i create private legacy app, there's no app id there and in n8n when using trigger there's no other option to choose to put credentials other than this […]

Note that this person already calls the thing they made a "private legacy app", because that is what the interface calls it now. They were not looking for the missing field because of a deprecation notice. They were following a tutorial, and the tutorial described a screen that no longer exists.

A community moderator answered with the diagnosis. The App ID does not exist on private apps, and the app type that has one cannot be created any more. The way forward is to poll instead of using the trigger: a service key with read scopes, pasted into the HubSpot node's credential, driven from a Schedule Trigger.

That is a real answer and it works, and it also quietly changes the shape of the integration. A webhook that fires on change becomes a schedule that checks every few minutes. For most small businesses that is fine. For anything where the delay matters, it is a design decision that got made by a deprecation rather than by anyone in the room.

Make and Zapier are not part of this

Both connect to HubSpot with OAuth, so neither is affected by either wave.

Make's HubSpot CRM documentation does not contain the phrase "private app" at all; the connection flow is a browser authorisation that a HubSpot Super Admin has to pre-approve. The reason is not an accident of design, and a Make employee explained it in the community last year when somebody asked for private app token support:

The problem is that if our HubSpot app that didn't use OAuth, Make would not be listable in the HubSpot app marketplace - see the HubSpot listing requirements. The best workarounds are either for you to use the Make HTTP app, or to build your own Custom App in Make using a Private App connection.

Read the last clause, because it is the one that comes back. Anyone who took that advice and built a custom Make app on a private app connection is in the same position as the n8n users: what they have keeps working, and they cannot make another one after 26 October.

Zapier connects through OAuth as well, and its HubSpot help article — last updated in August 2025 — describes a browser login with no mention of private apps or tokens.

The other deadline, which has two different dates

There is a second HubSpot change on the calendar, and it is a better example of the quiet kind of break.

HubSpot is sunsetting version 1 of its Pipelines API, the endpoint that answers "what deal stages exist in this account". The changelog is unambiguous about the date:

HubSpot will sunset the Pipelines API V1 on December 4, 2026. After this date, the API will no longer be supported.

The API reference pages for those same endpoints say something else:

Please note: the v1 Pipelines API will be sunset on November 2nd, 2026. After that date, the API will no longer be supported.

Thirty-two days apart, both official, both live. The same warning appears on more than one reference page, so it is not a typo on one of them. Plan for the earlier date, because that is the only version of this you control.

Neither date appears on HubSpot's own page of sunsetted and deprecated APIs, which was last modified on 2 September — nineteen days after the announcement — and lists neither this nor the private app change. The changelog is the only place either one exists.

What breaks is narrower than "HubSpot deals stop working", and worth understanding. In n8n, three of the four places the HubSpot node loads pipeline data go through /crm-pipelines/v1/, and those calls are what fill the dropdowns you pick a deal stage or ticket stage from. A saved workflow stores the stage id and keeps running. What stops is editing: open the node after the sunset and the list will not populate. Since the node's own field help says the deal stage is required when creating a deal, building a new one after that date means supplying the id by hand or by expression.

That is the failure mode nobody schedules around, because it does not show up in a run history. It shows up the day somebody tries to add a step, six weeks later, and finds an empty dropdown with no explanation attached — the same silence you get when a credential has quietly stopped being valid.

42 views, no replies

Both announcements were posted to HubSpot's community by a HubSpot employee. Eleven days after the private app post, it had 42 views and no replies. The Pipelines post, after twenty-four days, had 59 views and no replies. A search of the community in early September turned up nothing but the announcements themselves.

Meanwhile HubSpot's own community managers — the same role that posted the announcement — were still handing out the old recipe weeks after it. On 7 September, in a thread about restricting pipeline stage movement, the advice was to "verify that the private app or OAuth access token includes the required scope" — eleven days after the announcement, which is entirely reasonable advice for somebody who already has one, and exactly how the instruction stays in circulation.

The n8n forum has the same lag in the other direction. Four weeks before HubSpot's announcement, somebody recommending an approach there described a HubSpot private app as "the stable long-term path". It was, right up until it was not.

None of this is anyone behaving badly. It is what a quiet deprecation looks like from the outside: the vendor publishes once, in the place developers read, and everyone else keeps repeating the previous correct answer until something forces an update.

What to do before 26 October

  1. Check whether you need one more private app, ever. A second environment, a contractor's sandbox, a spare token for a project starting in November. If the answer is a maybe, create it before 26 October. It keeps working afterwards; you just cannot make it later.
  2. Look at what your integrations actually authenticate with. In n8n, open the HubSpot credential: Service Key means a token starting pat-, which covers both private app tokens and service keys. API Key means something that stopped working in 2022. OAuth2 means you are unaffected.
  3. Try a service key on one non-critical workflow now. Development, then Keys, then Service Keys, with only the scopes that workflow needs. Paste it into the same field the old token was in. If it works, you have your migration path and you can stop worrying about the deadline.
  4. Check whether anything you own needs webhooks. Service keys cannot do them. If a webhook-driven HubSpot integration is on your roadmap and you have no private app to build it on, that project changes shape after 26 October.
  5. Update your own runbook. Whatever document tells your team how to connect HubSpot, the first step in it is now wrong, and the menu path has changed even before the deadline.
  6. Separately, before 2 November, pin your deal stages. Open every n8n node that picks a deal stage or ticket stage, note the ids, and make sure a workflow can be rebuilt without the dropdown. This one is invisible until you try to edit something.
  7. Do not migrate existing private apps in a hurry. They are explicitly unaffected. The urgency is entirely about creating new ones and about the pipelines endpoint.

When this is a job to hand over

If you can name every place a HubSpot token lives in your business, close this tab, go and create one spare private app, and you are finished. Nobody needs to be paid for that.

The people who cannot answer that question are the ones this becomes a job for. An agency that set up HubSpot for clients has private app tokens sitting in credential fields across a dozen accounts and no list of which ones. A business whose HubSpot connection was built by a contractor in 2024 cannot tell from the outside whether it is a private app, an OAuth connection, or a script with a token in an environment variable. Webhooks are the third case, and the only one that is really engineering rather than inventory: the replacement does not do them, so the alternative is a project-based app built through a command-line tool.

Nobody quotes an unknown, and anybody can quote a list of accounts. That is why the first hour of this job is making the list, and why the work after it can carry a price agreed in advance. The n8n work we take on frequently starts exactly here, with somebody asking what a credential in a workflow actually is.

The pattern underneath is the one to carry away, because HubSpot is not unusual in it. The vendor closes the door for new arrivals, promises that everyone already inside is safe, and repeats the exercise on a schedule. It has now done this twice in five months, with the same wording, and the second announcement quietly falsified a sentence in the first. Zendesk is retiring its API tokens on a comparable timetable, and it is closing the same door in the same order.

Sources

  • Legacy private app creation sunset - HubSpot changelog, announced 27 August 2026, read 7 September 2026. The scope of the change, both rollout dates by account age, the statement that existing apps continue to work as-is, the weaker "not affected at this time" phrasing in the lead, and the recommendation to use Service Keys.
  • Legacy public app creation sunset - HubSpot changelog, announced 23 April 2026, read 7 September 2026. The earlier closure of legacy public app creation on 26 May and 23 June 2026, and the sentence saying legacy private apps were not affected at that time.
  • Service Keys enter public beta - HubSpot changelog, announced 10 February 2026, read 7 September 2026. Service keys as the replacement for legacy private apps, and the advice to continue using a legacy private app for webhook integrations.
  • Make API requests using a service key (BETA) - HubSpot developer documentation, read 7 September 2026. The beta status, the bearer token format, the inability to authenticate webhooks, and who is allowed to create a key.
  • Private apps overview - HubSpot developer documentation, read 7 September 2026. The current menu path through Development and Legacy apps, and the absence of any date or sunset language on the page.
  • Pipelines API V1 sunset - HubSpot changelog, announced 14 August 2026, read 7 September 2026. The 4 December 2026 date and the recommended migration target.
  • Get pipelines, v1 API reference - HubSpot API reference, read 7 September 2026. The 2 November 2026 sunset warning on the endpoint pages, and the endpoint path itself.
  • Sunsetted and deprecated APIs - HubSpot developer documentation, last modified 2 September 2026, read 7 September 2026. Neither the Pipelines V1 sunset nor the private app change appears in either table.
  • n8n pull request #28479 - n8n on GitHub, merged 17 April 2026, read 7 September 2026 through the GitHub API. The credential rename from App Token to Service Key, its stated reason, and the note that internal names were left unchanged.
  • n8n HubSpot credentials documentation - read 7 September 2026. The supported authentication methods, the note that UI-based private apps are now legacy, the path to a service key in HubSpot, and the instruction to paste it into the App Token field.
  • n8n source, HubSpot node - read 7 September 2026 at release tag 2.38.4. The pipeline-loading calls to /crm-pipelines/v1/, the authentication options with API Key as the default, the single credential type accepted by the HubSpot Trigger node, and the field help stating that a deal stage is required when creating a deal.
  • How to fix this code challenge parameter when connecting HubSpot to n8n - n8n community, 2 August 2026, read 7 September 2026. A user unable to fill the trigger credential after legacy public app creation closed, and the moderator's answer recommending a service key with polling.
  • Update HubSpot connector to use HubSpot private app tokens - Make community, 12 August 2025, read 7 September 2026. A Make employee explaining why the connector uses OAuth, and suggesting a custom Make app on a private app connection as a workaround.
  • HubSpot CRM app documentation - Make apps documentation, read 7 September 2026. The OAuth connection flow requiring Super Admin pre-approval, and the absence of any private app option.
  • How to get started with HubSpot on Zapier - Zapier Help Center, updated 22 August 2025, read 7 September 2026. The browser-based connection flow, with no reference to private apps.
  • Legacy private app creation being disabled and Pipelines API V1 sunset - HubSpot community, 27 August and 14 August 2026, read 7 September 2026. Both announcements posted by a HubSpot employee, with view counts and no replies at the time of reading.

Integration dropping data between systems? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.