# Search (/docs/api/search)



One search surface, four facets. Every result carries the same
provenance stamp as the underlying record — so a search is an ICP
query, not a scrape. Search is **flat per request**: a query that
returns 50 hits costs the same as one that returns 5.

<EndpointList topic="search" />

## Search people [#search-people]

<EndpointDemo id="search-people" />

Keyword + filters across LinkedIn's people graph. The response shape
mirrors a stripped-down [`/v1/profiles`](/docs/api/profiles) record —
enough for triage; call profiles for the full résumé.

For tighter ICP filters (current company, school, geography), pass
the canonical IDs from
[`/v1/companies/by-id`](/docs/api/companies) and
[`/v1/locations`](/docs/api/locations).

## Search companies [#search-companies]

<EndpointDemo id="search-companies" />

Filter by industry, headcount band, HQ region. Ideal for ICP
company-list building — combine with
[`/v1/companies/:slug/employees`](/docs/api/companies) to expand each
hit into named people.

## Search groups [#search-groups]

<EndpointDemo id="search-groups" />

Find LinkedIn groups by keyword and topic — a niche-community
discovery primitive. Pair with
[`/v1/groups/:id/members`](/docs/api/groups) to enumerate.

## Search posts [#search-posts]

<EndpointDemo id="search-posts" />

Find posts by keyword. Useful for thought-leadership monitoring,
launch-tracking, and topic timelines. Each hit is an activity ID —
feed it into [`/v1/posts/:id`](/docs/api/posts) for the full record.

## Notes [#notes]

* People search caps at LinkedIn's \~1,000-result ceiling, regardless
  of your `limit`/`offset`. Use tighter filters to surface different
  pages rather than trying to paginate past it.
* Search results cache for 15 minutes per (filters, page) tuple to
  protect against pathological agent loops.
* Empty result sets are never charged.