The warning is about token-management endpoints, not ordinary CRM URLs
HubSpot announced in May 2026 that the legacy OAuth v1 API will be fully deprecated on February 16, 2027. The affected family includes token exchange and token metadata routes. HubSpot’s reason is security: legacy patterns can expose sensitive values in URL paths or query parameters.
A June 2026 n8n Community thread shows users receiving the HubSpot notice and asking whether n8n’s supplied HubSpot credential would be updated. That is the right question because a workflow can call only modern CRM endpoints while its credential layer still uses an older OAuth token endpoint behind the scenes.
The first diagnostic task is attribution. Determine which app ID HubSpot named in the notice and which authentication component owns that app.
Classify the caller before you change anything
There are four common n8n situations. First, the built-in HubSpot credential manages OAuth for you. Second, you created a generic OAuth2 credential and supplied HubSpot authorization and token URLs yourself. Third, HTTP Request or Code nodes call HubSpot OAuth endpoints directly. Fourth, an external service or helper library shares the same HubSpot app and is the actual legacy caller.
Search exported workflow JSON, environment variables, helper repositories, and integration documentation for `/oauth/v1/`. Also check any custom credential definitions. If nothing in your n8n-controlled configuration contains the route, the call may be inside a built-in integration or external component.
Do not change the HubSpot app secret during this inventory. Secret rotation creates a separate outage risk and does not tell you which code path is using the deprecated endpoint.
- Built-in n8n HubSpot credential: upgrade/test when n8n ships the migration.
- Generic OAuth2 credential: you control the token URL and can migrate it.
- Direct HTTP or Code node: replace the legacy endpoint in your own workflow.
- External service using the same app: fix that service, not n8n.
As of August 2026, n8n’s HubSpot Developer API credential still points to the v1 token URL
I checked the current n8n master branch while preparing this guide. In `packages/nodes-base/credentials/HubspotDeveloperApi.credentials.ts`, the credential named `HubSpot Developer API` still defines `https://api.hubapi.com/oauth/v1/token` as its hidden `accessTokenUrl`.
That finding makes the HubSpot warning directly relevant to users whose workflow depends on this specific Developer API credential, including HubSpot Trigger setups that use it. It does not prove that every n8n HubSpot authentication path is legacy. The ordinary HubSpot app-token path and any generic OAuth2 credential you configured yourself are separate implementations and must be inspected on their own.
Because this is authentication code, the safest response is to track the n8n release that changes the credential, test authorization and token refresh in staging, and then upgrade production. Editing packaged credential code on a live instance is a poor default because an n8n upgrade can overwrite the patch and OAuth changes can fail only when refresh occurs later.
HubSpot’s replacement is the OAuth 2026-03 API
HubSpot’s migration guide replaces `POST /oauth/v1/token` with `POST /oauth/2026-03/token` for both authorization-code exchange and refresh-token flows. Token metadata calls move from GET routes containing the token to `POST /oauth/2026-03/token/introspect`.
The legacy refresh-token deletion route is replaced by `POST /oauth/2026-03/token/revoke`. HubSpot also emphasizes sending sensitive fields in the request body rather than the URL.
The install URL and user consent flow are not the main change. The migration is focused on backend token issuance, introspection, refresh, and revocation.
Legacy token exchange:
POST https://api.hubapi.com/oauth/v1/token
Current replacement:
POST https://api.hubapi.com/oauth/2026-03/token
Content-Type: application/x-www-form-urlencoded
Token metadata replacement:
POST https://api.hubapi.com/oauth/2026-03/token/introspectIf you own the generic OAuth2 credential, migrate in a clone first
Do not edit the only production credential in place. Duplicate the credential or create a temporary test integration, point its token URL at the current HubSpot endpoint, and reconnect a test HubSpot account. The goal is to prove initial authorization and refresh behavior.
A credential that connects once but cannot refresh is not migrated. Shorten the test cycle where possible, or inspect the refreshed token behavior after the original access token would have expired. Also verify the new error payload fields used by HubSpot.
After the test credential survives both initial exchange and refresh, move one non-critical workflow to it before changing high-value automations.
If the caller is n8n’s built-in HubSpot credential, do not fork it casually
The June 2026 community discussion ended with a report that n8n had begun looking into changes for the HubSpot integration. The current-code check above shows why you should verify the exact n8n release you run rather than assume the migration is already complete: the `HubspotDeveloperApi` credential on master still referenced the v1 token URL when this article was reviewed.
Track n8n release notes and this credential implementation. When a release changes the HubSpot Developer API token endpoint, upgrade in staging or a cloned instance, reconnect one credential, and verify both initial connection and refresh before moving production triggers.
Self-hosted teams should avoid patching packaged node code directly unless they are prepared to maintain the fork. A local hotfix can be overwritten on the next n8n upgrade and can create a security-sensitive divergence in OAuth handling.
Do not migrate OAuth if the workflow is actually using a Service Key or private token
Some n8n HubSpot workflows authenticate with a Service Key or app token rather than OAuth. Those credentials use bearer-token access to CRM APIs and do not perform the OAuth authorization-code or refresh-token flow described in this deprecation.
If HubSpot’s notice names an app that is unrelated to the token used by the workflow you are inspecting, keep looking. Changing a working Service Key will not remove OAuth v1 traffic generated by another application.
Map app IDs to workflows and credentials before taking action. This is especially important in agencies and internal automation teams where several n8n instances may connect to the same HubSpot portal.
Build a cutover checklist long before February 2027
The sunset date is February 16, 2027, but waiting until February creates unnecessary risk. Inventory in 2026, test the supported path, and set an internal deadline well before HubSpot begins returning errors.
For each OAuth-based HubSpot integration, record the HubSpot app ID, n8n credential name, n8n version, authentication type, token endpoint owner, and the workflows that depend on it. That list turns a vague vendor warning into a finite migration project.
After cutover, monitor 4xx responses from OAuth endpoints and verify that refresh continues without human reauthorization.
The migration test must include refresh and revocation behavior
Initial authorization is only one part of OAuth. A production integration depends on refresh after token expiry, and some operational workflows depend on introspection or revocation. Test the functions your integration actually uses.
Inspect logs to confirm tokens and client secrets are not appearing in URLs. HubSpot’s migration specifically addresses the security risk of secrets in paths and query parameters.
Keep the legacy credential available for rollback only until the new path is proven. Then remove unused secrets and document the final supported configuration.
Sources checked for this guide
The warning scenario comes from a June 2026 n8n Community discussion. The sunset date, affected endpoints, replacement OAuth 2026-03 endpoints, and security rationale are verified against HubSpot’s official changelog and migration guide. I also checked n8n’s current `HubspotDeveloperApi` credential source to verify the token URL used by that specific credential as of August 26, 2026.