Skip to main content
filter_conditions is a single optional array on the request body. Each entry promotes one multi-value filter from the default OR (“match any”) behaviour to AND (“match all”), or vice versa. Filters you don’t list keep their defaults.

Schema

key and operator are both required on every entry. An entry with only operator is silently ignored — there is no global override.

Why it matters

The default operator is OR because most prospecting workflows want broad reach: “people in any of these countries”, “companies tagged with any of these verticals”. For high-precision targeting — “uses all of Salesforce + HubSpot + Marketo” — you need AND. The cost of being wrong:
  • Wanted AND, got OR: the response over-recalls — you see companies that match only one tag, not the full stack. Easy to spot, costs result-quality.
  • Wanted OR, got AND: the response under-recalls — usually returns near-zero rows on multi-value AND filters because real-world arrays rarely contain every requested value. Easy to spot, looks like a broken query.

Supported keys

The exact key set depends on the endpoint you’re calling: Place filters (places, exclude_places), the other exclude_* filters and advertisement_search_terms always match any listed value. Job Search and News Search do not take filter_conditions; their list filters always match any listed value.
The keys above mirror the enum arrays in the OpenAPI spec (company_filter_conditions, people_filter_conditions, ads_filter_conditions, cloud_footprint_filter_conditions). Sending an unsupported key for an endpoint is silently ignored.

Recipes

Goal: companies that use both Salesforce and HubSpot — not just one.
Drop the filter_conditions entry to widen the search to either of the two.

Common mistakes

There is no global “default operator” toggle. Every entry must name a specific filter:
Entries are independent per-key overrides — they do not chain. Listing both technologies and verticals does not create a Boolean expression between them; each one just sets its own array’s operator.The combination across filter keys is always AND (every filter must match). You cannot OR-combine two distinct filter dimensions through filter_conditions. If you need a true OR-of-different-filters search, run two requests and merge results client-side.
AND requires every listed value to be present. With 8+ values you almost always get zero rows because real-world tagging is sparse. Keep AND-overridden arrays at 2-4 values; use OR for exploratory or category-level filtering.
Location and place filters (locations, places, and their company_ and exclude_ forms) always match any listed value. A filter_conditions entry for them is ignored.
When in doubt, omit filter_conditions first and check your result count against expectations. Add overrides only for filters where the default doesn’t match your intent — this keeps the request payload smaller and easier to debug.

See also

Filters Overview

The mental model — start here if filter_conditions is your first stop.

People + Company Filters

How to layer company filters into /people/search, including the key-remap.

Company Search reference

Full request schema for /companies/search (includes company_filter_conditions).

People Search reference

Full request schema for /people/search (includes people_filter_conditions).
Last modified on September 28, 2026