Deprecating the HighLevel API V1 and migrating to V2
If your integrations currently rely on our V1 API, it is time to plan your transition to V2. Migrating is straightforward, and our team is ready to assist if you run into any challenges along the way.
What "End-of-Support" Means for Your Setup
Here is what the V1 deprecation looks like in practice:
No immediate shutoff: Active V1 integrations will continue to function for now, but they are operating without a safety net.
No updates or fixes: V1 will no longer receive security patches, bug fixes, or new features.
No technical support: Our support team is no longer able to troubleshoot V1 API issues.
No new keys: The option to generate new V1 API keys has been disabled.
The bottom line: V1 is deprecated. To prevent unexpected service disruptions, we strongly recommend planning your migration to V2 soon rather than waiting for an outage to force a rush job.
Key Upgrades in V2
V2 is built to be a more secure, robust platform. The migration introduces two primary improvements:
Scoped Authentication: Instead of using unrestricted API keys that grant access to everything, V2 relies on granular permissions (scopes). Your integration only accesses the specific data it needs to function.
Two Clear Authentication Paths: | Use Case | Authentication Method | | :--- | :--- | | Internal tools & automations (Make, n8n, Zapier, custom scripts) | Private Integration Tokens (PIT) | | Public or Marketplace apps (Multi-account installs) | OAuth 2.0 |
Choosing the right path upfront makes managing scopes, handling tokens, and testing much simpler.
Migration Checklist
Here is the recommended workflow to get your integration updated:
Step 1: Audit your current setup. Identify which V1 endpoints, credentials, and webhooks your systems currently rely on.
Step 2: Choose your authentication model. Use Private Integration Tokens (PIT) for internal, single-account tools, or OAuth 2.0 if you are building public-facing marketplace apps.
Step 3: Replace legacy keys. Generate your V2 credentials and update your application's authorization headers.
Step 4: Update endpoints by feature. Instead of migrating your entire codebase at once, update and test your endpoints feature-by-feature to keep the process manageable.
Step 5: Configure precise scopes. Assign only the specific permissions your application actually requires to minimize security risks.
Step 6: Test thoroughly. Verify your authentication flow, endpoint responses, webhooks, and core user workflows in a safe test environment.
Step 7: Deploy in phases. Test your updates in a staging environment before routing production traffic.
Common Mistakes to Avoid
Using PITs for public apps: Private Integration Tokens are strictly for internal use. If other accounts need to install and authorize your app, you must use OAuth 2.0.
Treating this as a simple URL swap: While updating endpoint URLs is easy, most migration issues stem from incorrect scope mapping, authentication handling, or webhook configurations.
Carrying over broad V1 permissions: V2 is designed around least-privilege security. Take the time to configure precise scopes from the start rather than requesting blanket access.
Need Help with Your Migration?
If you want to review your current setup or need help choosing the right migration path, our team is available to help.
AMA <> HighLevel v1 API Migration Guide
Thursday, July 9 · 8:00 – 9:00pm
Time zone: Asia/Kolkata
Google Meet joining info
Video call link: https://meet.google.com/xye-amec-uih
Or dial: (US) +1 208-715-5297 PIN: 130 028 977#
More phone numbers: https://tel.meet/xye-amec-uih?pin=8070415570607
For full technical details, read the HighLevel API Docs or ask questions in our Developer Community Slack.
