Is there a way to switch v1 off on our HubSpot account in order to force only v3 API connections? If not, what would be a good method to test v3 exclusively to make sure any v1 in our back end has been updated?
Hi @howardmarxb
Thanks for the great question —
Looping in a few community members who’ve dealt with API version management and migration strategies —
Hello there @RubenBurdin @GRajput @evaldas Have any of you found effective ways to validate that an account or integration is fully off v1 and operating only on v3? Any insights would be really helpful here.
Victor
@Victor_Becerra ,
Thanks for looping in @RubenBurdin @GRajput @evaldas
Looking forward to reading their insights!
Best,
H
Hey @howardmarxb I’m glad I can help!
Best, Victor
Hi @howardmarxb
HubSpot does not provide a direct way to disable v1 API on your account. To ensure all integrations use v3, you should review your backend code and server-side implementations to identify any v1 API calls. Once identified, update these calls to use the corresponding v3 endpoints. Additionally, you can test your integrations in a staging environment using only v3 calls to confirm that all functionality works correctly before deploying to production.
I hope this will help you out. Please mark it as Solution Accepted and upvote to help another Community member.
Thanks!
Hi @howardmarxb , you’re not missing a hidden toggle. HubSpot doesn’t offer an “account-level switch” to disable v1 endpoints globally, so you can’t force all callers onto v3 from inside the portal.What I’ve seen work well is treating this like an observability problem. First, identify which credentials are being used (API key, private app token, OAuth app). If you’re using private apps, HubSpot gives you request logs per app, which is the fastest way to spot lingering /v1/ calls without grepping every repo. You can find the “view request logs” flow in the private app docs here: https://developers.hubspot.com/docs/apps/legacy-apps/private-apps/build-with-projects/create-private-apps-with-projects. If you’re on OAuth/public app, you can do the same via your app’s monitoring logs.
For testing “v3 only”, a practical pattern is to put a proxy/API gateway in front of HubSpot in staging and hard-block any outbound request whose path matches /v1/ (and maybe /v2/ too). That gives you immediate, deterministic failures and a clean inventory of what still needs migration. One gotcha: some HubSpot surfaces are still legacy for certain use cases, so you may discover a few endpoints you can’t replace yet (the Lists API is a good example of HubSpot explicitly publishing a v1 sunset and migration path). V1 List API migration guide - HubSpot docs
Hope this helps