Search

We index 50M+ companies and 500M+ professional profiles, and expose them through structured filters: Series B fintechs in Berlin under 200 people, or the VPs of Engineering who joined them in the last six months.

Counting matches costs one credit per count; after that you pay only for the results you pull.

The four search surfaces

Every one has a *Count sibling that costs a single credit. Use it first. If you already hold LinkedIn URLs or domains, skip search entirely and resolve them directly.

Filtering companies

Company filters, by group:

Most filters take anyOf / allOf / noneOf, so include and exclude logic lives in the same request. Ranges name their own bounds (lowerBoundExclusive, upperBoundInclusive), so inclusivity is stated on the filter rather than buried in a reference table.

fortuneRankings filters to the Fortune 500 or Forbes Global 2000 by list and year (see Fortune & Forbes lists).

Filtering people

Each jobs entry carries its own company and its own tenure status, so allOf expresses career paths a flat filter can't: worked at Stripe in the past and is a VP somewhere now. Naming a company in both anyOf and noneOf excludes anyone who ever held that role there.

People search also carries stealth status as a filter; see Stealth tracking.

Resolving identifiers you already have

When you already hold identifiers, skip the filters. Pass up to 100 per request and get back the same records search returns:

Both allow 1,500 requests/minute, and you're charged only for the identifiers that resolve — misses are free.

For lookups by other identifiers, such as an email or a name plus a domain, use Kitchen Sink instead. The full guide, with standardization and domain lookup, is Resolving identifiers.

Count before you spend

A count costs 1 credit, however many matches it finds. A search costs 1 credit per result, so count first.

• includeCount: true on a search returns the estimate alongside the page. This charges one extra count credit, so it's for when you want both, not for iterating on filters.

Iterate on filters against the count endpoint until the number looks right, then run the search once.

Ordering results

Pass sort when result order matters: clauses apply in the order you give them.

Each profile in the response also carries last_updated_at (snake case, as returned), so you can see how recent a record is. To sort, use the dataUpdatedAt field descending to get the most recently refreshed profiles first.

Both directions are supported, and records missing the sort value always land last regardless of direction — so a desc sort on totalFunding never buries funded companies behind unfunded ones.

Pagination

Pages are cursor-based: pass the returned nextCursor to get the next page.

• Keep paging until a page comes back empty. The cursor points past the last row you received, so a page shorter than pageSize doesn't mean you're done; only an empty page (with nextCursor: null) does. Very broad queries in particular can return a short page mid-run.

• Credits are held for the full page up front. A request for 1,000 rows holds 1,000 credits, and anything not returned is refunded on the same call. If your balance can't cover the hold you get 402, even if fewer results would have come back, so lower pageSize when your balance is low.

• includeCount never fails the search. If the count can't be computed, you still get the page, estimatedCount comes back null, and the count credit is refunded.

• A cursor belongs to one query. Changing filters, sort, or exclusion lists mid-run invalidates it — start a fresh pagination run instead.

• Combined-search cursors validate their parameters and return an error on mismatch. Company and people cursors do not, so a reused cursor there quietly gives you results for the query you started with. Don't recycle cursors.

Combined search

When you want companies and the people who work at them together, combined search runs both in one pass and keeps them linked — so you skip the fan-out of searching companies, then querying people company by company.

Independent cursors mean you page companies and people separately, at whatever rate each side needs.

Exclusion lists

Pass companyExclusionListIDs (and, on people search, prospectExclusionListIDs) and matching companies or people are filtered out before results come back — your existing customers, your do-not-contact list, whatever you've already worked. Exclusions apply to results; the estimated count does not account for them. Building and managing the lists themselves: Exclusion lists.

Large pulls and slow pages

Big pages with every option turned on are the slowest calls in search. To pull large sets quickly:

• Use smaller pages. Each page returns faster, and the total cost is the same because you pay per row.
• Ask only for what you need. Detailed education and work history add work to every row; leave them off unless you use them.
• Narrow keyword fields. Keyword search across every profile field is the slowest filter; scope it to the fields you mean.
• Expect exclusion lists to add time. Excluded rows are filtered out and replaced, so heavily excluded searches take longer per page.
• Split and parallelize. Partition one huge query by country, company size, or another filter, and page each slice in parallel within your rate limit.
• Hand bulk jobs to the background. For tens of thousands of rows, build an audience and export it instead of paging by hand.

Recommended client timeouts for every endpoint are in Performance & timeouts.

Using it effectively

• Before a large pull or a comparison with another provider, read getting accurate results from search — the filter patterns and common mistakes, with worked examples.
• Tune filters against the count endpoints before running the search; each count is one credit, while a careless pull is one credit per result.
• Set pageSize deliberately and stop paginating when you have enough — nothing caps how far you page.
• Any run that pulls a fraction of the matches needs an explicit sort to be reproducible.
• Use allOf on jobs for career-path criteria rather than keyword matching.
• Company and people search allow 180 requests/minute; job posting search allows 120. Exceeding either returns HTTP 429, so back off and retry.

Use cases

• Outbound sales: find companies matching your ICP, then pull the buying committee at each in a single combined search.
• Recruiting: filter for people who held a specific role at a specific company and have been in their current job long enough to be open to a move.
• Venture sourcing: companies founded in the last 18 months, seed stage, sorted by last funding date.
• Competitive intel: companies running a competitor's technology, sliced by headcount and region.
• Market sizing: count endpoints alone answer "how many X are there" for a single credit.

Cost

Company and people search bill 1 credit per result returned, so a search that matches nothing costs nothing. Job posting search bills per job posting found. Count endpoints cost 1 credit per request (combined count: 1 per side); includeCount adds one count credit per request.

The chargeInfo on every response is what you were actually charged; trust it over any published rate. See Billing & credits.

Credit amounts are defaults — custom pricing is available for bulk use cases.

Related

• Agentic search — the same filters from a plain English prompt.
• Typeaheads — resolve company names, locations, titles, and skills into the exact values these filters expect.
• Google Maps search — local businesses that don't have a LinkedIn footprint.
• Contact Reveal — turn search results into verified emails and phone numbers.