HubSpot Private Apps: No New Ones Starting October 26. What It Means for Make and n8n

If your connection to HubSpot runs on the access token of a private app created in the HubSpot UI, you'll need to migrate. HubSpot published the timeline on August 27 and September 15. For existing accounts, the first deadline is October 26, 2026.

What exactly changes on October 26?

On October 26, only the creation of new legacy private apps ends. According to HubSpot, everything that's already running keeps working as is. The dates that matter:

According to HubSpot, unsupported means no more bug fixes, reliability improvements, or security updates. HubSpot hasn't named a shutdown date. Per HubSpot, unsupported versions may continue to function, but they aren't guaranteed to stay stable or available. For v4, HubSpot explicitly warns of degraded performance and outages. Our take: processes your leads or revenue depend on shouldn't run on APIs without a guarantee. Migrate whatever you can now, and move off /v4/ by March 30, 2027 at the latest. Migrate the rest as soon as HubSpot has documented all replacement paths in March 2027.

Are your Make and n8n connections affected?

It depends on the connection. According to Make's documentation, Make's built-in HubSpot app connects via OAuth, so there's no private app involved. It doesn't accept a private app token; for that, the Make team points to the HTTP module or custom apps (Make Community).

Still open: how Make and n8n will adapt their webhook setups. As of October 5, both still describe an app in a developer account with a developer API key, and n8n explicitly calls for a public app.

What can service keys do, and what can't they?

Service keys are HubSpot's successor for plain API access: one key with exactly the permissions (scopes) you give it. You create one under Development > Keys > Service keys. According to the HubSpot docs and the beta announcement:

• The key is passed as a bearer token, just like the old token. In Make and n8n, you only swap the value.
• It isn't tied to the person who created it: the connection keeps working if that person leaves the HubSpot account.
• When you rotate a key, the old one can stay valid for 7 more days, so you can update every place it's used without downtime.
• Under View logs, you can see its most recent requests.
• Limits: no webhooks, no UI extensions, REST calls only. In its Fall 2026 Spotlight on September 15, HubSpot also still lists service keys as a public beta.

Our take: create a separate key for each connection, each with only the scopes it needs. Then the log shows which process does what, and you can replace one key without touching the others.

What should you do, and by when?

Take stock before October 26, then handle the migration ahead of the 2027 deadlines:

1. Inventory before October 26: A super admin opens Development > Legacy apps (HubSpot docs) and writes down every app with its scopes. For each app, the Logs tab shows the calls from the last 30 days, and searching by request URL turns up paths with /v1/ to /v4/. Under Development > Migrations, the APIs tab lists which legacy APIs were used recently, detected from actual calls, not from your code (guide, changelog). Then track down where the tokens live: HTTP modules in Make, credentials in n8n, form scripts on your website, reporting tools.
2. Check your webhook needs: If you'll soon need a new connection with webhooks and nobody can build a project-based app in time, existing accounts can still create a legacy private app before October 26. Our take: that buys you time until September 2027 at most.
3. Only service keys for new connections: HubSpot explicitly recommends them for every new private integration.
4. Update your API paths: /crm/v3/objects/contacts, for example, becomes /crm/objects/2026-09/contacts (migration guide). Target 2026-09: every version is supported for at least 18 months, so 2026-03 is only safe until the end of September 2027, while 2026-09 is safe until at least March 2028. Not every old endpoint has a successor yet, including some from v1 and v2. HubSpot has announced the complete mapping for its March 2027 release. Some endpoints change fields in the request or response, and then the mappings in your downstream Make modules come up empty. So test the whole scenario, not just the path. One thing to test: since its launch on September 8, 2026-09 validates writes more strictly. If a write is missing a field that a rule in your account makes required, such as the close date on deals in the Closed won stage, the API rejects it (changelog). The same applies to anything set as required in your record creation settings.

What does this mean for your business?

Not an emergency, but a job with a deadline:

• Only Make's standard HubSpot app: Check the paths in your own "Make an API Call" modules. The rest is Make's job as the app's provider.
• Tokens in custom builds: This is where the risk lies. Our take: these connections have often grown over years and are rarely documented. The inventory shows what exists before it runs without updates or guarantees from fall 2027.
• New projects after October 26: Plan for service keys or a project-based app from the start. Build on legacy now and you'll build twice. The stopgap from step 2 is only meant for webhook connections with a fixed launch date.

Connecting HubSpot through Make is part of our process automation work, for example for the German insurance platform VersicherungsEngel, where leads from the web form land in the CRM automatically qualified. Not sure where all your tokens are hiding? Get in touch.