By Greg Nowak. Updated September 29, 2026.
HubSpot’s OAuth v1 endpoints remain available until February 16, 2027. After that, calls to them will begin returning errors. For a business, the visible symptom may be a CRM sync that stops updating, a customer who cannot connect an app, or a disconnection that fails quietly.
The code may be older than the team running it. It could live in an agency-built connector, a background worker, a reporting service or a script maintained by a former supplier. Treat the deadline as a small migration project: establish where the calls happen, update the token lifecycle, and prove that existing connections still work.
Find the calls before estimating the work
Search every repository and deployment that touches HubSpot authentication. This command catches the documented legacy paths when they appear as complete strings:
rg -n '/oauth/v1/(token|access-tokens|refresh-tokens)' .Also inspect SDK wrappers, environment configuration, serverless functions, scheduled jobs and API traffic. Code that builds a URL from separate strings will escape that search. If HubSpot sent a notice naming affected app IDs, use it to prioritise the audit; it reflects recent traffic and may miss dormant paths.
For each caller, record its owner, environment, purpose and connected accounts. A refresh worker deserves early attention because it can affect many established connections. A rarely used revoke call still needs a test: you do not want to discover a broken disconnect process during an incident.
| Path found | What to test | Priority |
|---|---|---|
| Authorization-code exchange | Complete a new installation | High if new customers connect regularly |
| Access-token refresh | Refresh an existing connection and complete a CRM request | High for every active integration |
| Token metadata lookup | Check both access and refresh tokens | Based on the workflow that uses it |
| Refresh-token revocation | Disconnect and confirm the token can no longer be used | Required before release |
Update the full token lifecycle
As of September 2026, HubSpot’s current OAuth reference uses the 2026-09 API version. Use POST /oauth/2026-09/token for authorization-code exchange and refresh, POST /oauth/2026-09/token/introspect for token metadata, and POST /oauth/2026-09/token/revoke to revoke a refresh token. HubSpot’s older v1 migration guide shows the equivalent 2026-03 paths, so check which supported version your application is deliberately using rather than mixing examples.
Send credentials and tokens as application/x-www-form-urlencoded body fields, never in a token URL or query string. For example, a refresh request against the current version has this shape:
curl --request POST \
--url https://api.hubapi.com/oauth/2026-09/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=refresh_token' \
--data-urlencode 'refresh_token=REFRESH_TOKEN' \
--data-urlencode 'client_id=CLIENT_ID' \
--data-urlencode 'client_secret=CLIENT_SECRET'Use placeholders only in a shared example; keep real secrets out of shell history, logs and support tickets. Read the returned access_token and calculate its expiry from expires_in. HubSpot currently describes access tokens as lasting 30 minutes, but the response is the value your code should use. Check token storage too: HubSpot defines no maximum access-token size, so a short database field can turn a successful refresh into a failed integration.
Introspection replaces the two v1 metadata GET calls with one POST. Include token_type_hint as access_token or refresh_token, then update code that reads the response: the newer model includes fields such as active and token_use. For explicit revocation, send the refresh token in the body of the revoke request. Update error handling to use the standard error and error_description fields. HubSpot retains status and message for compatibility.
Prove existing connections survive the release
A successful new installation covers only one route through the code. Test a representative existing account through a refresh and a real, low-risk CRM read. Include accounts with different scopes or older stored token records where relevant. Test an expired authorization code, an invalid client secret, a revoked refresh token, introspection of both token types and the disconnect flow. The install URL, consent page and requested scopes do not change for this migration.
Release in stages if your architecture allows it. Watch OAuth 4xx responses, refresh failures and unexpected requests for customers to reconnect. Keep the previous release available for a short rollback window, but check what its OAuth code calls: a version that still relies on v1 cannot be the recovery plan after the deadline. Preserve stored credentials during deployment and rollback.
Ask for evidence, not just a completion message
Before signing off, ask the technical owner for a list of affected systems, the version chosen, test results for new and established connections, and a monitored release date comfortably ahead of February 16, 2027. Repeat the code search and check production traffic after deployment. If ownership or access is unclear, resolve that early; finding the right repository can take longer than changing the endpoint.
If an inherited HubSpot integration has no clear owner, Greg can help scope the audit and turn the findings into a manageable migration plan.
Related on GrN.dk
- Cloudflare Service Keys Stop in September: Find Every Caller
- MCP 2026-07-28: Treat It as an Auth Migration, Not a Version Bump
- Locked Out of Your Apple Developer Account? Fix Access Before October 1
Need help with this kind of work?
Plan the HubSpot migration with Greg Get in touch with Greg.
