Deprecated GoHighLevel API Endpoints and What Replaced Them

Five. Across the 576 endpoints in our index that come from GoHighLevel's official specification, five carry a deprecation notice in their own documentation, each naming a replacement:

All five still respond, and that is the whole problem. A deprecated endpoint returning 200 gives your integration no reason to complain, so the work surfaces on the day it is withdrawn rather than on a day you chose. Twelve further endpoints are current but contain individual fields marked deprecated, covered below.

This is the deprecation that matters, because GET /contacts/ is what most integrations reach for first. GoHighLevel's documentation directs you to Search Contacts instead.

The replacement is a POST to /contacts/search taking filters in a JSON body, rather than a GET with query parameters. It is a rewrite of how you express a query, not a change of address:

# Deprecated — still responds, and nothing in the response says so
curl -s "https://services.leadconnectorhq.com/contacts/?locationId=LOC" \
  -H "Authorization: Bearer pit-your-token" \
  -H "Version: 2021-07-28"

# Current — filters and sorting move into a JSON body
curl -s -X POST "https://services.leadconnectorhq.com/contacts/search" \
  -H "Authorization: Bearer pit-your-token" \
  -H "Version: 2021-07-28" \
  -H "Content-Type: application/json" \
  -d '{"locationId":"LOC","pageLimit":20}'

Search Contacts is also the more capable endpoint — filtering, sorting, and pagination beyond the basics live there — so this is one of the rare migrations worth doing on its merits rather than only to stay ahead of a removal. The deprecated endpoint's full schema is on its reference page, which flags the replacement inline.

GET /users/, documented as Get User by Location, is deprecated in favour of GET /users/search. The migration has a detail that is easy to miss and produces a confusing error when you do.

On the replacement, locationId becomes a query parameter that filters results, and companyId is required alongside it. Swap the path but keep passing only locationId and the rejection reads like a permissions problem rather than a missing parameter.

A second trap sits in the same neighbourhood, unrelated to the deprecation but likely to surface during the same piece of work: users is one of the categories that mixes token levels. Six of its seven endpoints want an agency token and only one takes a sub-account token, so a migration attempted with a sub-account Private Integration Token can fail for a reason that has nothing to do with the endpoint change. The authentication guide lists which categories mix levels.

Three Agent Studio endpoints are deprecated together, and they are the simplest migrations here — GoHighLevel dropped the /agent-studio/public-api/ prefix for a plain /agent path:

• POST /agent-studio/public-api/agents/:agentId/execute → POST /agent/:agentId/execute
• GET /agent-studio/public-api/agents/:agentId → GET /agent/:agentId
• GET /agent-studio/public-api/agents → GET /agent

Request and response shapes carry over, so these are search-and-replace changes. Two behaviours documented on the deprecated execute endpoint are worth carrying across with you: omit executionId on the first message of a session, then pass the executionId you were returned on every subsequent request to stay in that session; and locationId belongs in the request body, not the path.

Endpoint-level deprecation is the visible kind. The quieter kind is a field marked deprecated inside an endpoint that is otherwise current — twelve endpoints in our index contain at least one. These break nothing today; they mean you are writing to a property on its way out, or reading one that may stop being populated.

Check the calendars group first, because those fields appear across create-calendar, update-calendar, get-calendar, and get-calendars — so code that reads a calendar and writes it back touches them twice. Meeting-location handling in particular moved from two flat fields into a nested locationConfigurations object, which is a structural change rather than a rename.

The users entry deserves separate attention because it is not a migration at all: email on update-user is marked deprecated with the note that email updates are no longer supported, for security reasons. There is nothing to move to. Code that changes a user's email through the API needs a different approach entirely.

Deprecated endpoints return 200. No header marks them, no field in the response body flags them, and the only signal is prose in that endpoint's documentation. Detection has to be deliberate.

• Audit by path, once. Grep your codebase for the five paths in the table at the top of this page. It takes minutes and it is the entire endpoint-level exposure.
• Re-check on upgrade. The list changes. Treat “is anything I call now deprecated?” as part of dependency review rather than a question you answer once.
• Make the tooling say so. An AI assistant writing your GoHighLevel code will reproduce GET /contacts/ happily — that endpoint is heavily represented in public examples and nothing about it looks wrong. The fix is for the schema source the assistant reads to carry the deprecation.

That last point is why we track deprecations as data rather than prose: each endpoint in Hylo's index carries a deprecated flag and a replacement pointer, so an assistant looking up contacts/get-contacts is told to use contacts/search-contacts-advanced before it writes the call. The same flags appear on the public reference pages, no account needed.