LinkedIn Search API
People search and company search as JSON endpoints, with the filters you would use in the LinkedIn UI — title, current and past company, school, industry and location — plus stable pagination.
Example response
Generated from the live API, so it is exactly the shape your code will parse.
{
"pagination": {
"totalElements": 1987,
"totalPages": 40,
"pageNumber": 1,
"previousElements": 0,
"pageSize": 3,
"totalResultCount": 1987
},
"elements": [
{
"id": "ACoAAA8BYqEBCGLg_vT_ca6mMEqkpp9nVOgr1LM",
"name": "William Gates",
"position": "Co-chair at Bill & Melinda Gates Foundation",
"photo": "https://media.licdn.com/dms/image/v2/sample/williamhgates.jpg",
"location": {
"linkedinText": "Seattle, Washington, United States"
},
"linkedinUrl": "https://www.linkedin.com/in/williamhgates",
"publicIdentifier": "williamhgates"
},
{
"id": "ACoAAAAyIB4BFmMkiYQtEHXvS7hOF71E6dVj3sQ",
"name": "Satya Nadella",
"position": "Chairman and CEO at Microsoft",
"photo": "https://media.licdn.com/dms/image/v2/sample/satyanadella.jpg",
"location": {
"linkedinText": "Redmond, Washington, United States"
},
"linkedinUrl": "https://www.linkedin.com/in/satyanadella",
"publicIdentifier": "satyanadella"
},
{
"id": "ACoAABw3l1kBqR4z9m2QkTvHb6xY0pLdRc8NfAe",
"name": "Ada Okonkwo",
"position": "Head of Data Engineering at Northwind Analytics",
"photo": "https://media.licdn.com/dms/image/v2/sample/ada-okonkwo.jpg",
"location": {
"linkedinText": "London, England, United Kingdom"
},
"linkedinUrl": "https://www.linkedin.com/in/ada-okonkwo",
"publicIdentifier": "ada-okonkwo"
}
],
"query": {
"search": "data engineer"
},
"status": "ok"
}Filters, and how they combine
People search accepts a free-text search term plus structured filters: firstName, lastName, title, currentCompany, pastCompany, school, industryId and either location as text or geoId as an identifier. Filters combine with AND, and several of them accept comma-separated lists which combine with OR inside that filter.
So title=CTO,VP Engineering with currentCompany=acme reads as (CTO OR VP Engineering) AND Acme. That is usually what you want, and it is worth checking your mental model against it before you conclude a query is broken.
Location: use geo IDs, not strings
location takes a text string and does its best. geoId takes an identifier and is exact. "Cambridge" is a real place in England and a real place in Massachusetts; the string cannot tell them apart and the geo ID can.
Resolve your locations once with the geo ID lookup endpoint, store the IDs, and pass those from then on. The lookup costs $0.0010 and you will only ever do it once per place. We also publish a free geo ID finder that runs on this same endpoint if you just need a handful.
Paging without duplicates
List responses come with a pagination object: total pages, total elements, current page and a paginationToken. Increment page for simple cases; carry the paginationToken when you want stable paging over a result set that is changing underneath you.
Search results shift as the underlying index updates. If you page a large query slowly using only page numbers, you will see occasional duplicates and occasional gaps. That is normal for any relevance-ranked search, ours included. Deduplicate on profile ID as you collect, and treat totalElements as an estimate rather than a promise.
Making searches reproducible
A search that returns different results each time it runs is hard to build on. Three habits make it predictable enough:
Pin the location. Use geoId, never the free-text location. A string is resolved differently as the index changes; an ID is not.
Bound the query. Broad searches drift most because the tail of the result set is where ranking is least stable. Narrow filters produce a smaller, more stable set.
Store what you asked for. Keep the exact parameters alongside the results. When a number moves next quarter you need to know whether the market changed or your query did — and without the stored query you cannot tell.
For anything you will re-run, treat the parameter set as code and check it into version control rather than leaving it in a scheduled job's config.
What it costs
Prices are per request, charged from a prepaid balance. Bigger top-ups lower every row — Scale takes 55% off.
| Request | Starter | Pro (42% off) | Scale (55% off) |
|---|---|---|---|
| Profile search page | $0.0400 | $0.0232 | $0.0180 |
| Company search page | $0.0400 | $0.0232 | $0.0180 |
Failed requests are never charged. See full pricing.
Frequently asked questions
How is search priced?
Per page returned, not per result. A search page is $0.0400 at Starter and $0.0180 at Scale, whether the page comes back full or nearly empty.
Why do I get different results for the same query?
Search is relevance-ranked against a live index, so ordering shifts as the index updates. Use the pagination token for stable paging and deduplicate on profile ID.
How many results can I page through?
Deep paging is capped the same way it is in the LinkedIn interface. For broad coverage, split one wide query into several narrow ones rather than paging a single query to exhaustion.
Can I search by industry?
Yes, via industryId, which accepts one or several comma-separated identifiers.