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

{
  "filter_conditions": [
    { "key": "technologies", "operator": "and" },
    { "key": "verticals",    "operator": "or"  }
  ]
}
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.
Under the hood, the engine compiles your operator choice to a native Postgres array operator: && (overlap) for OR, @> (contains) for AND. Both are index-friendly, so the cost difference is in result size, not query latency.

​
Supported keys

The exact key set depends on the endpoint you’re calling:
Key/companies/search/people/search/companies/advertisements/searchDefaultWhat and means
technologiesyesyes—ORHas every tech in the list
categoriesyesyes—ORTagged with every category
verticalsyesyes—ORBelongs to every vertical
vertical_categoriesyesyes—ORIn every vertical category
vertical_sub_categoriesyesyes—ORIn every vertical sub-category
keywordsyesyes—ORDescription contains every keyword
placesyesyes—ORListed in every place
exclude_placesyesyes—ORExcluded from every place
advertisement_target_locationsyes——ORAd targets every country (company endpoint)
advertisement_exclude_target_locationsyes——ORAd excludes every country
advertisement_search_termsyes——ORAd copy contains every term
job_exclude_locationsyes——ORJob posting excludes every location
social_media—yes—ORPerson has all listed social-media accounts
target_locations——yesORAd targets every country (ads endpoint)
exclude_target_locations——yesORAd excludes every country
The keys above mirror the enum arrays in the OpenAPI spec (company_filter_conditions, people_filter_conditions, ads_filter_conditions). Sending an unsupported key for an endpoint is silently ignored.

​
Recipes

Goal: companies that use all of Python, PostgreSQL, and Kubernetes — not just one.
curl -X POST https://api.pubrio.com/companies/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "technologies": [37, 152, 408],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ],
    "per_page": 25,
    "page": 1
  }'
Drop the filter_conditions entry to widen the search to any of the three.

​
Common mistakes

There is no global “default operator” toggle. Every entry must name a specific filter:
// Ignored — no key
{ "filter_conditions": [{ "operator": "and" }] }

// Correct — overrides only the technologies filter
{ "filter_conditions": [{ "key": "technologies", "operator": "and" }] }
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 is column @> ARRAY[…] — every value must 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.
On /people/search, the people-API name is company_places / company_locations. But inside filter_conditions[].key you must use the engine name — places, locations. The remap happens internally before filter_conditions is consulted.
// Won't override — engine doesn't see "company_places" as a filter key
{ "filter_conditions": [{ "key": "company_places", "operator": "and" }] }

// Correct
{ "filter_conditions": [{ "key": "places", "operator": "and" }] }
Full remap table on the People + Company Filters page.
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).