The short version: GoHighLevel API v1 reached end-of-support on 31 December 2025, you can no longer generate new v1 API keys, and the platform now runs on API v2 with OAuth 2.0 and Private Integration Tokens. If you still have v1 code running, it may keep responding for now, but it gets no fixes, no new endpoints, and no support. This guide explains exactly what changed between v1 and v2 and how to migrate without rewriting everything in one weekend.
The single biggest change is how you authenticate. v1 handed you one permanent API key that could do anything. v2 replaces that with scoped, short-lived access: either a Private Integration Token for your own accounts or an OAuth 2.0 flow for apps other people install. Everything else follows from that shift.
What actually changed from v1 to v2
Authentication. v1 used a single static API key per account with unrestricted access. v2 uses granular scopes, so a token can be allowed to read contacts but not touch payments, for example. That's better security and it's now the only option, since the ability to create new API keys has been removed from both agency and sub-account settings.
Base URL. v1 lived on the old rest.gohighlevel.com style host. v2 calls go to https://services.leadconnectorhq.com. Every path you use will change host, and many resource paths changed shape too, so treat migration as per-endpoint work, not a find-and-replace on the domain.
The Version header. v2 requires a Version header on every request except the token exchange, for example Version: 2021-07-28. v1 had nothing like it. Forget it and calls fail with an error that doesn't clearly say why.
Webhooks. v2 has a much richer webhook and event system, plus workflow triggers for Marketplace apps. If you were polling on v1, migration is a good moment to switch to events.
Pick your authentication model first
Before touching endpoints, decide how you'll authenticate, because it changes your whole setup. v2 gives you two clear paths.
Private Integration Token if the tool only touches accounts you own or manage. You generate the token in settings, scope it, and use it as a bearer token. No OAuth server needed. This is the closest thing to the old API-key experience, minus the "one key rules everything" risk. The full comparison is in Private Integration Tokens vs Marketplace Apps.
OAuth 2.0 if you're building something other agencies install. It's more work up front (authorization flow, token storage, refresh), but it's the only way to reach accounts you don't own. Walkthrough with code is in How to Build a GoHighLevel Marketplace App with OAuth 2.0.
Migrate endpoint by endpoint, not all at once
The mistake here is trying to port the entire codebase in one pass. Don't. Migrate feature by feature so you can test each slice against real data before moving on.
- Inventory your v1 calls. List every v1 endpoint your code hits and group them by feature: contacts, opportunities, calendars, payments.
- Set up v2 auth once. Get a Private Integration Token or a working OAuth install, and confirm a single authenticated call works end to end with the
Versionheader. - Port one feature. Take contacts first, since almost everything depends on it. Map the v1 fields to their v2 equivalents (some names and structures changed), update the paths, and test.
- Run old and new side by side. Where you can, keep v1 running for untouched features while the migrated ones move to v2. That way a bug in one feature doesn't take the whole integration down.
- Cut over and delete v1 code. Once a feature is verified on v2, remove its v1 path so nobody accidentally depends on it later.
Field and response differences to watch
v2 responses are generally more structured and more consistent than v1, but that means field names and nesting often differ. Don't assume a v1 payload maps one-to-one. Two habits save you here: log a real v2 response for each endpoint before you write the parsing code, and write a small adapter layer that converts v2 responses into your app's internal shape. That adapter means if GHL tweaks a response later, you change one function, not fifty call sites.
Rate limits are different too
v2 enforces a burst limit of 100 requests per 10 seconds and a daily limit of 200,000, both per app per resource, and it returns rate-limit headers so you can pace yourself. If your v1 code fired requests without any throttling, add backoff during migration. The details are in GoHighLevel API Rate Limits Explained.
Do this now, not in December
v1 is on borrowed time. It still answers, but it's frozen, and "frozen" turns into "broken" the moment something upstream changes. Migrating now, while you can run v1 and v2 in parallel, is far calmer than migrating after a v1 endpoint quietly stops working in production. Start with your contacts endpoints this week, get one feature fully on v2, and the rest becomes routine. For the bigger picture on building against v2, see the GoHighLevel custom development guide.
Frequently asked questions
Will my old v1 API keys stop working immediately?
Not immediately. Existing v1 connections may keep responding, but v1 is end-of-support: no fixes, no new endpoints, no help if something breaks. Treat anything still on v1 as a liability to migrate, not a stable dependency.
Can I still create a new v1 API key?
No. The option to generate new API keys has been removed from both agency and sub-account settings. New integrations must use a Private Integration Token or OAuth 2.0 on v2.
Is migrating to v2 a full rewrite?
It doesn't have to be. The auth layer changes, and endpoint paths and some fields change, but you can migrate feature by feature and keep the rest running on v1 during the transition.
What's the fastest way to start?
Create a Private Integration Token, make one authenticated v2 call with the Version header, then port your contacts endpoints first. Once contacts work, the pattern repeats for everything else.
