LinkedIn Search API

LinkedIn publishes two search APIs and neither one searches LinkedIn. People Typeahead matches names against your own Page’s followers, ten at a time, on a restricted permission. Unified Search is an iframe for applicant tracking systems on a Recruiter contract. Nothing official queries the member graph and hands back rows.

That gap is why LinkedIn search integrations run inside a LinkedIn account, and why the results look different from what people expect when they arrive. A search returns what the result card shows, and the profile behind it is a second call. That is the model gtm-api.com runs: 20,000+ LinkedIn accounts on its stack, and under 1% of them ever restricted.

How LinkedIn search works through an API

Searching LinkedIn from code takes one of two routes, and only one of them searches people. The official platform has no endpoint that runs a keyword or filter search over members. Three of its surfaces carry the word search or something close to it, and each one does something narrower: autocompleting names among a Page’s followers, showing ATS candidates next to Recruiter results, or confirming profiles a partner already holds.

The route that does search people runs inside a LinkedIn account you connect, and it behaves like the search page a person uses. A call returns one page of result cards, so a row carries what the card shows, and the full profile is a second call into enrichment. Two practical questions follow: how to describe the search, as filters or as a pasted search URL, and how far it can go, which a page ceiling and LinkedIn’s own monthly limit on search decide. The sections below take the official APIs first, then the account-based route in that order.

LinkedIn’s official search APIs

The three official surfaces are easy to mistake for each other because LinkedIn documents them in three different product areas. Laid side by side, the scope of each one is the whole story.

The People Typeahead API is the closest thing LinkedIn publishes to a people search, and it exists for one job: finding someone to @mention while composing a post as a company Page. LinkedIn’s own summary says it “facilitates the discovery of members who can be mentioned in the organization page posts”, and that Page admins “can search for Page followers by keyword or vanity URL”.

Two sentences in that document close the door on every other use. The first is about reach: “Search response contains only members that are followers of the company.” So the index is not LinkedIn, it is your own follower list. The second is about access: “The People Typeahead API endpoint is restricted. This permission is granted to select developers only.” The permission is r_organization_followers, a Community Management scope whose name tells you what the endpoint really is.

The shape of the query is narrow too. Keyword search “returns up to 10 profiles matching the first few characters of first or last name”, so it is a name-prefix autocomplete with a ten-row cap. There is no title filter, no location, no industry, and no way to widen it past the people who already follow you.

Unified Search sits in a different product and answers a different question. It lets a recruiter on a Recruiter System Connect contract run one query and see candidates from their applicant tracking system next to LinkedIn’s, with keyword, location, job title, an in-ATS toggle and an open-to-work toggle. The results arrive as “a LinkedIn iframe widget” inside the ATS, which is the detail that decides whether it can help you: it renders results for a human to read, and the data it moves travels from your ATS into LinkedIn.

Searching through a connected account

With no official route to the member graph, the working answer is to run the search inside a LinkedIn account you own and connect. GTM API takes that route, and the practical consequence is that a search reaches exactly what the person behind that account would see in their browser, subject to the same platform limits.

Five of the methods on that surface are list searches: people, companies, service providers, and the Sales Navigator people and company engines. Three are neighbourhood finders that take one entity and return related ones: similar profiles, similar companies, and a company’s employees. One returns a company’s decision makers, and typeahead lookups turn a human word like a city or an industry into the id a filter needs. An account with a Recruiter seat also gets the Recruiter people search, which pages differently: 25 rows a page, up to page 40.

Every one of them is a POST under https://app.gtm-api.com/linkedin/v4/api/linkedin-scraping/, and every one of them behaves the same way about state: a search runs now, returns one live page inside the HTTP response, and stores nothing. Nothing is cached, so two identical calls a minute apart both spend a search and both re-run against LinkedIn.

What a search result contains

This is where most integrations get their first surprise, and it is worth knowing before you design a schema around it. A search result is a discovery record. It carries what LinkedIn’s results page shows about a person, and the regular and Sales Navigator pages show different things.

The regular result card shows a headline and a location under the name, plus a degree badge when LinkedIn prints one. It shows no structured job, so position and company_name stay null there, and the job title, if it appears at all, sits inside the headline as free text. Sales Navigator works the other way round. Its rows are read from the search page’s own answer, so they carry the current position and company, the location and the degree, then lead facts after the common fields: the company’s numeric id and industry, the About text, tenure, seniority, the Open Profile flag, a pending-invitation flag and badges such as recently hired. Sales Navigator shows no headline, so that one field is null on its rows.

The degree and the invitation flag are relative to the account that ran the search, and the degree is spelled differently by engine: 3rd+ on the regular card, 3rd or out_of_network on Sales Navigator.

What no search row carries is the rest of the profile: experience, skills and contact details. Those are a second call into enrichment, keyed on the ln_id or nickname a people-search row hands you, or the sn_id from a Sales Navigator row. What enrichment returns about a member, and what you are allowed to keep, is on LinkedIn profile data API.

That sets the order of work: filter on what the row already carries, then enrich only the rows that survive. A search page brings back a page of people for one slot of the account’s daily scraping budget, while enrichment spends a separate daily budget one profile at a time.

# 1. one live page of a people search, composed from filters
curl -X POST https://app.gtm-api.com/linkedin/v4/api/linkedin-scraping/search-people \
  -H "Authorization: Bearer $GTM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "page": 1, "filters": { "keywords": "growth marketing", "network": ["2nd"] } }'

# 2. the row carries the card: ids, name, headline, location, degree.
#    Take a row's ln_id and read the full profile.
curl -X POST https://app.gtm-api.com/linkedin/v4/api/linkedin-enrichment/person-full-profile \
  -H "Authorization: Bearer $GTM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "profile_id": "ACoAA..." }'

Filters or a search URL

The five list searches take either a pasted LinkedIn search url or a structured filters object. Same route, same parser, same cost, because the structured half composes the same LinkedIn URL and then runs the same page. Send filters when a program or an agent builds the query, send a URL when a person built it in the LinkedIn interface or the filter vocabulary cannot express what they want.

Exactly one of the two is required, and the validation is stricter than it first looks. Sending both is rejected. Sending neither is rejected. Sending a filters object whose members are all empty is rejected, and a lone false counts as empty, so a single "hiring_on_linkedin": false fails the same way an empty object does.

Three filters mean something other than what the name suggests, and each one costs you a run while raising no error. On the Sales Navigator company search, annual_revenue is expressed in millions, so a 10 means ten million dollars and a wrong unit is off by a factor of a million without complaining. On the Sales Navigator people search, company_headquarters filters on where the person’s employer is headquartered rather than where the person is. And the account-activity codes carry fixed windows that are not yours to set: a senior-leadership change means the last three months, a funding event means the past twelve.

Filters that take numeric ids need those ids first, and the regular and Sales Navigator typeahead lookups run over separate id spaces. An id from the regular lookup never works on a Sales Navigator engine, and the reverse is equally true. One quirk is worth memorising because it fails quietly: the school lookup returns real school ids, but the people search has no school-id member, so those ids only reach LinkedIn inside a pasted search URL.

Paging and the limits that stop a search

Paging on the list searches runs from 1 to 100, and 100 is a hard ceiling. A page number above it is rejected outright. On the people and company engines there is no total to count against, since the field comes back null, so the loop has to be driven by the has_more flag, which goes false at page 100 whatever LinkedIn still holds. An empty page is terminal. The Sales Navigator people search is the exception: its total is LinkedIn’s own count, exact on a small search and an estimate on a large one, and has_more turns false on the page that reaches it, one page before the empty one.

Rows arrive in LinkedIn’s own order. There is no sort axis and no deduplication across pages, which means a naive loop that collects everything can hand you the same person twice. Past roughly five pages, or for anything on a schedule, a scheduled scrape suits the job better than a paging loop.

The ceiling is rarely what stops you first. LinkedIn meters regular people search with a monthly commercial-use limit, tightest on free accounts, and the people search reports it directly: a commercial_use_limit_hit boolean comes back true when the paywall has fired and the rows may be truncated. The Sales Navigator people search does not spend that limit. What it counts, who gets a higher one and when it resets is on LinkedIn search limits.

One useful asymmetry sits next to it. A typeahead lookup types into the account’s already open tab, so it loads no search page, spends no LinkedIn search and leaves the commercial-use limit untouched. It still costs a slot of the account’s daily budget, which the platform enforces on every action type. Those daily budgets and how an account earns a bigger one are on LinkedIn limits. The rest of the surface, from messaging to enrichment, is on LinkedIn API: the developer guide.

Frequently Asked Questions

Sources & Further Reading

• LinkedIn / Microsoft Learn, People Typeahead API (the quoted purpose, the followers-only response, the ten-profile name-prefix cap, the restricted-endpoint note and the r_organization_followers permission), last updated 15 April 2026
• LinkedIn / Microsoft Learn, Unified Search (the RSC contract requirement, the quoted iframe widget, and the five search parameters), last updated 18 June 2025
• LinkedIn / Microsoft Learn, Get API access (the quoted description of r_sales_nav_profiles as matched profile information, and SNAP listed as approval-only), last updated 26 June 2025 · Sales Solutions developer overview (SNAP closed to new partners)
• gtm-api.com, developer documentation, People and company search (the methods and their seat requirements, the row shape on each engine, the url-or-filters rule and its 422s, the silently dropped unknown filter, the three misleading filters, the two id spaces, the page-100 ceiling and has_more, and the commercial_use_limit_hit flag)
• Related: LinkedIn API: the developer guide · LinkedIn profile data API · LinkedIn search limits · Sales Navigator API · Is Sales Navigator worth it · LinkedIn scraping vs a safe API

Michael SalamatovGTM engineerRuns the gtm-api.com blog. Covers LinkedIn limits, account health and the API side of outbound.in

Last updated: October 2026 · Definitions and benchmarks verified at time of publication