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 every serious LinkedIn search integration runs inside a LinkedIn account, and why the results look different from what people expect when they arrive. A search returns identities, not profiles. On the account-based side of it, gtm-api.com reports 20,000+ accounts at under a 1% ban rate.

What answers to the name, and what each one searches

Three official surfaces carry the word search or something close to it, and they 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 one that does search people, and its two sentences

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 under 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.

Eleven methods sit on that surface. Five 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. The last two are typeahead lookups that turn a human word like a city or an industry into the id a filter needs.

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 row contains, and the five fields that are always null

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. The row carries an identity and almost nothing else.

Those last five are null by construction. LinkedIn’s search results page does not carry them on either engine, so no amount of filtering brings them back. Getting a headline or a current employer is 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.

The design point underneath this is that search and enrichment are priced and paced separately for a reason. A thousand-row search followed by a thousand enrichment calls is a thousand-and-one operations against the account, and the pacing engine counts every one of them.

# 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 gave you an id and a name. Everything else is a second call.

Two ways to describe a search, and the one that fails silently

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 two 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, the ceiling, and the limit that binds first

Paging on the list searches runs from 1 to 100, and 100 is a hard ceiling. A page number above it is rejected outright. There is no total to count against, since the field comes back null on the people and company engines, 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.

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 enforces a monthly commercial-use limit on search for every account, 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. What that limit 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 eleven methods and their seat requirements, the row shape and the five null fields, 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: September 2026 · Official search surfaces, their permissions and page dates re-read on learn.microsoft.com, and every request field, filter rule and response field checked against the published API contract, on 4 September 2026 and re-read on 5 September 2026