Skip to main content

Use case

Search people or companies with simple_filters or filters. Discover valid fields first, inspect top values for one field, then run the paginated search.

API Reference

See the full request/response schema and parameters in the API Reference.

Pricing

See Credits & Pricing Guide for credit costs.

Errors

For error responses (400, 403, 404, 409, 503, etc.), see Handling Errors.

Rate limits

Filter-search-specific API rate limits.

Core concepts

Simple filters

simple_filters is the primary query format for this API. It supports common exact-match, range, logical, and text-search operations with concise JSON syntax.

Top-level shape

Supported operators

The capabilities response exposes supported simple-query operators in simple_query_operators.

Nested array matching ($elemMatch)

$elemMatch queries fields inside nested arrays. Two mistakes account for nearly all failed queries:
  • Relative path — companyData.memberId instead of the full dotted path currentCompanies.companyData.memberId
  • Wrong type — passing a numeric ID as a string ("1234567") when the field’s value_type is long
A relative path or type mismatch inside $elemMatch returns zero results or a misleading 400 — not always a clear error. Check the full dotted path and value_type in GET /search/filter-capabilities before querying.
Find people currently at a specific company by LinkedIn memberId:
The common wrong form — same request shape, but relative path and string ID:
Both the relative path (companyData.memberId instead of currentCompanies.companyData.memberId) and the string ID ("1234567" instead of 1234567) cause this query to fail. $elemMatch must be keyed on the field’s nested_path from capabilities — not always the outermost array. currentCompanies.companyData.memberId has nested_path: "currentCompanies", so $elemMatch keys on currentCompanies. currentCompanies.positions.title has nested_path: "currentCompanies.positions", so $elemMatch on currentCompanies cannot reference a positions field.

Excluding results

There are two ways to exclude records:
  • Use simple_filters operators such as $ne, $nin, $not, and $nor to exclude records that match field conditions.
  • Use the top-level exclusion fields — exclude_entity_ids or exclude_list_ids — to suppress specific people or companies by ID. See Search Exclusions for identifier formats, saved lists, and limits.
Operator-based exclusions affect matching, pagination, and result counts. ID-based exclusions are applied after matching, so pages can return fewer rows than page_size. Don’t rely on total_available to count excluded records or size pagination — page until next_cursor is null.
Cursor requests must send only {"cursor": "..."}. You cannot add or change exclusions while paging through an existing cursor. Include exclusions in the first /search/query request.

Query examples

Find US-based companies:
Find US-based companies with at least 4 employees:
Exclude companies in specific industries:
Find US-based companies while excluding public companies:
Exclude records using logical negation:
Exclude records that match any disallowed condition:
Find US-based companies with at least 4 employees where a post mentions YC X25:
Find US-based companies sorted by employee count descending, capped to 8 total results:
Find Canadian companies that have raised any amount and mention technology in categories or keywords:
Full-text search across specific fields:
Find people whose headline matches “engineer”:
Find people by current job title:
Fields with a doubly nested path accept $elemMatch on the inner nested path:
Find people currently at a specific company by LinkedIn memberId — see the full example and path/type requirements in Nested array matching ($elemMatch).

DSL filters

filters accepts a constrained DSL subset for cases where simple_filters is not expressive enough. For DSL syntax and clause behavior, see the OpenSearch Query DSL docs.

Top-level shape

Supported query clauses

Query examples

Exact match:
Range filter:
Multi-field full-text search:
Nested query:
Exclude with must_not:

Filter capabilities

Returns all available fields for filter search — the complete list of fields you can query, sort, range, or aggregate against, plus the supported simple_filters operators and DSL limits.
Call this first to discover what is filterable before constructing any simple_filters or filters request. The response is the source of truth: a field that is not in fields cannot be queried.

Query parameters

Example request

Response shape

Limits

Field entry

Each item in fields describes one queryable field.

Example response

Trimmed to two representative fields — a top-level keyword and a nested numeric.

Common lookups

Filter the fields array client-side to find what is available for a given operation.

Find specific fields

To confirm that a field exists and see what operators it accepts, filter the fields array by name. The examples below check hq_country_iso2 and employees_count — the same fields used in the simple_filters examples earlier on this page.
If a field is missing from fields, it cannot be queried. If queryable is false, the field is exposed but reserved for sort or aggregation only. If nested_path is non-null, wrap the clause in a nested query when using filters. To search by partial name (e.g. every revenue-related field):
Capabilities are cached for cache_ttl_seconds (typically 600s). Pass refresh=true only when verifying schema changes — every refresh rebuilds the mapping and is slower.

Field values

Returns top values for one field, ranked by descending scoped document count. There is no batch variant.

Scoped query

  • Omit both simple_filters and filters for global scope.
  • Send either simple_filters or filters for scoped discovery.
  • filters.sort, filters.size, and mixed filters plus simple_filters requests are not allowed on this endpoint.
  • simple_filters.$sort and simple_filters.$limit are not supported on this endpoint.
Use filter-field-values with a high top_k to enumerate valid values for any enum-like field before filtering. This prevents querying with values that return zero results.
Discover all available industries:
The same pattern works for any enum-like field: ownership_status, hq_country_iso2, funding_stage, and so on. Check supports_top_values: true in the capabilities response to confirm the field supports this endpoint.

Example request

Global:
Scoped:

Nested fields

For nested fields such as funding_rounds.name, counts are document counts and each filter_snippet is wrapped in a nested clause so it can be reused directly in DSL flows.

Search query

Runs a paginated search. Fresh searches accept simple_filters, filters, parsed_query, or a search_id to re-run a previous search.

Request flow

  1. First request: send exactly one of simple_filters, filters, parsed_query, or search_id, plus optional page_size, max_results, and exclusions (exclude_entity_ids, exclude_list_ids).
  2. Next page request: send only {"cursor":"..."}.
  3. Requests that mix cursor with query or pagination fields return 400.

Effective result cap

  • page_size controls rows per page. Range 1..100. Default 10.
  • max_results controls the total row cap across all pages. Range 1..5000.
  • simple_filters.$limit and filters.size are optional query-level caps.
  • When both max_results and a query-level cap are set, the smaller value applies.
  • When no total cap is set, the backend default applies.

Example request

Fresh search:
Exclude specific people with exclude_entity_ids:
Use exclusions when re-running or refining a search and you want to avoid returning records the user has already seen. People searches also accept exclude_public_ids for backward compatibility. For full details — company identifiers, saved lists, and limits — see Search Exclusions. Re-run a previous search:
Next page:
raw_source returns the document directly. It does not use grouped objects such as identity, profile, or location.

Export search results

Export results from any search as a CSV. See Export Search Results for the full endpoint reference.

Example usage

The following examples walk through the full recommended flow: discover valid fields, inspect top values for one field, then paginate through results.