メインコンテンツへスキップ
POST /people/search は POST /companies/search がサポートするすべての企業フィルターを受け付けます。先に企業を取得して ID を集め、それを 2 度目の人物クエリに渡す必要はもうありません — 1 回のリクエストで両レイヤーが完結します。

​
1 つのボディに 2 つのパラメーターファミリー

/people/search のリクエストボディは概念的に 2 つのフィルターファミリーに分かれます。JSON 上は同じ階層に並び、自由に組み合わせられます。
人物 の属性を絞り込みます:
パラメーター説明
people_titles役職名(自由テキストまたは slug)
management_levelsfounder、c_suite、vp、director、manager など
departmentsmaster_engineering、master_sales など
department_functionsサブ部門 / ファンクション slug
people_locations人物所在の国コード
people_groups保存済みグループ ID
peoples特定の people_search_id
linkedin_urls人物の LinkedIn URL
social_mediaネットワークごとの SNS ハンドル
company_ プレフィックスはロケーション/プレース系フィルターにのみ存在します。places / locations の bare 名は既に 人物 の住所に使われているためです。それ以外はすべて bare の企業名(technologies であって company_technologies ではありません)。

​
4 ステップでクエリを組み立てる

1

人物条件を決める

具体的に誰? 役職、シニオリティ、部門、国。このレイヤーはボディの トップレベル に置きます — 精度の役割は通常、企業条件が担います。
2

企業条件を決める

どんな企業に勤めている必要があるか? 業界、規模、設立年、本社国、テックスタック。これらは company_filters: {...} オブジェクトにまとめると、どのキーがどのレイヤーに属するかが一目で分かります。
3

filter_conditions でフィルターごとに AND/OR を選ぶ

精度が必要な複数値フィルター(例: 「これらの技術を すべて 使う」)には、company_filters の 中 の filter_conditions にエントリを追加。デフォルトは OR。
4

リクエストを送る

POST /people/search。どちらのスタイルも受け付けますが、company_filters: {...} は読みやすく、Monitor のペイロード形状とも一致します。

​
完全な例

クエリ: 米国を本社に置き、設立 2015〜2023 年、従業員 100〜5,000 人、Kubernetes と Docker を 両方 使い、サンフランシスコは除外する中堅企業の VP of Engineering または CTO。 
curl -X POST https://api.pubrio.com/people/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "people_titles": ["VP of Engineering", "CTO"],

    "company_filters": {
      "company_locations": ["US"],
      "company_exclude_places": ["San Francisco"],
      "founded_dates": [2010, 2024],
      "employees": [[100, 500], [501, 1000], [1001, 5000]],
      "technologies": ["Kubernetes", "Docker"],
      "is_enable_similarity_search": true
    },

    "per_page": 25,
    "page": 1
  }'

​
キー再マッピングのリファレンス

/people/search が共有エンジンに企業フィルターを引き渡すとき、ロケーション/プレース系のキーは bare 名にリネームされます。エンジンと filter_conditions[].key が実際に見るのはこの bare 名です:
送信時(人物 API 名)エンジンが見る名前(企業 API 名)
company_locationslocations
company_exclude_locationsexclude_locations
company_placesplaces
company_exclude_placesexclude_places
technologies、verticals、vertical_categories、vertical_sub_categories、categories、keywords、founded_dates、employees、revenuesそのまま
このため、企業レベルのロケーションに対する filter_conditions[].key には bare 名を使います: 
{
  "company_places": ["New York", "Boston"],
  "filter_conditions": [
    { "key": "places", "operator": "and" }
  ]
}
{ "key": "company_places", "operator": "and" } は黙って無視されます — エンジンはプレフィックス付きの名前を認識しません。filter_conditions では常にエンジン名を参照してください。

​
内部の JOIN

いずれかの 企業レベルフィルターを追加すると、人物 → 企業の JOIN が LEFT JOIN から INNER JOIN に切り替わります。人物レベルのフィルターをすべて満たしていても、紐づく企業が確認できない人物は結果から除外されます。
company_locations や technologies を加えた途端に結果が 0 になる場合は、期待する人物に紐づく企業がデータセットに存在するか確認してください。エンジンはここで再現より正確性を優先します — フィルター充足のために企業を捏造することはありません。
レスポンスにも同じ JOIN 挙動が反映されます: 企業フィルターを 1 つでも適用すると、返される各人物は必ず company オブジェクトを含みます。

​
よくあるパターン

固定の企業リスト(companies または domains)をターゲットにし、人物レベルのフィルターを重ねて各社内の適切なバイヤーを見つけます。
{
  "people_titles": ["VP Marketing", "CMO"],
  "management_levels": ["vp", "c_suite"],
  "company_filters": {
    "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"]
  }
}
具体的なアカウントではなく、企業の「形」を記述します。レンジとバーティカルを使い、エンジンが該当する人物を返します。
{
  "people_titles": ["Head of Engineering"],
  "company_filters": {
    "verticals": [12, 47],
    "company_locations": ["US", "CA"],
    "founded_dates": [2015, 2023],
    "employees": [[51, 200], [201, 500]],
    "filter_conditions": [
      { "key": "verticals", "operator": "and" }
    ]
  }
}
特定のスタックを使う企業のバイヤーを探します。technologies への AND が典型的なオーバーライドです。
{
  "people_titles": ["RevOps", "Sales Operations"],
  "departments": ["master_sales"],
  "company_filters": {
    "technologies": [114, 287, 452],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ]
  }
}
競合の製品(あるテクノロジー)を使っているが、自社製品は使っていない(categories で除外、または別フィルターパス)企業の意思決定者を見つけます。
{
  "people_titles": ["VP Sales"],
  "management_levels": ["vp"],
  "company_filters": {
    "technologies": [287]
  }
}
その後 technologies: [114](自社製品のタグ ID)で再実行し、クライアント側で差分を取ります。

​
次のステップ

filter_conditions

完全リファレンス — 全キー、全デフォルト、コピー可能な AND/OR レシピ。

フィルター概要

統一フィルターエンジンの背後にあるメンタルモデル。

人物検索リファレンス

/people/search の完全なリクエスト/レスポンススキーマ。

企業検索リファレンス

/companies/search の完全なリクエスト/レスポンススキーマ。