> ## Documentation Index > Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt > Use this file to discover all available pages before exploring further. # People + Company Filters > Kombinieren Sie Filter auf Personen- und Unternehmensebene in einem einzigen /people/search-Aufruf — dieselbe Filter-Engine wie /companies/search. `POST /people/search` akzeptiert jeden Unternehmensfilter, den auch `POST /companies/search` akzeptiert. Sie müssen Unternehmen nicht mehr vorab abrufen, deren IDs sammeln und in eine zweite Personenabfrage einspeisen — eine Anfrage deckt beide Ebenen ab. ## Zwei Parameterfamilien, ein Body Ein `/people/search`-Anfrage-Body gliedert sich konzeptionell in zwei Filterfamilien. Sie liegen auf derselben Ebene im JSON, und Sie können sie beliebig mischen. Filtern nach Attributen der *Person*: | Parameter | Beschreibung | | ---------------------- | ---------------------------------------------------- | | `people_titles` | Jobtitel (Freitext oder Slug) | | `management_levels` | `founder`, `c_suite`, `vp`, `director`, `manager`, … | | `departments` | `master_engineering`, `master_sales`, … | | `department_functions` | Unterabteilungs-/Funktions-Slugs | | `people_locations` | Ländercodes für den Standort der Person | | `people_groups` | Gespeicherte Gruppen-IDs | | `peoples` | Bestimmte `people_search_id`-Werte | | `linkedin_urls` | LinkedIn-URLs der Person | | `social_media` | Social-Media-Handles je Netzwerk | Filtern nach Attributen des Unternehmens, bei dem die Person arbeitet — dieselben Namen wie bei `/companies/search`, mit einer kleinen Menge `company_`-präfixierter Standortschlüssel: | Parameter | Beschreibung | | --------------------------- | ---------------------------------------------------------------------- | | `technologies` | Vom Unternehmen genutzte Technologie-Slug-IDs | | `categories` | Kategorie-Slug-IDs | | `verticals` | Vertical-Slug-IDs | | `vertical_categories` | Vertical-Kategorie-Slug-IDs | | `vertical_sub_categories` | Vertical-Unterkategorie-Slug-IDs | | `keywords` | Freitext-Schlüsselwörter, abgeglichen mit der Unternehmensbeschreibung | | `founded_dates` | Gründungsjahr-Bereich, z. B. `[2015, 2023]` | | `employees` | Mitarbeiter-Buckets, z. B. `[[100, 500], [501, 1000]]` | | `revenues` | Umsatz-Buckets in USD | | `company_locations` | Ländercodes für den Unternehmenssitz | | `company_exclude_locations` | Auszuschließende Ländercodes | | `company_places` | Einzuschließende Stadt-/Regionsnamen | | `company_exclude_places` | Auszuschließende Stadt-/Regionsnamen | | `companies` | Bestimmte `domain_search_id`-Werte | | `domains` | Bestimmte Unternehmensdomains | | `company_linkedin_urls` | LinkedIn-URLs des Unternehmens | Das `company_`-Präfix existiert nur bei den Standort-/Ortsfiltern, da die bloßen Namen `places` / `locations` bereits für die Adresse der *Person* verwendet werden. Alles andere verwendet den bloßen Unternehmensnamen (`technologies`, nicht `company_technologies`). *** ## Eine Abfrage in vier Schritten aufbauen Wer, genau? Titel, Senioritätsstufe, Abteilung, Land. Halten Sie diese Ebene auf der **obersten Ebene** des Bodys — das Unternehmensprädikat übernimmt üblicherweise die Präzisionsarbeit. Bei welchen Unternehmen müssen sie arbeiten? Branche, Größe, Gründungsjahr, Sitzland, Technologie-Stack. Gruppieren Sie diese unter einem **`company_filters: {...}`**-Objekt, damit klar ist, zu welcher Ebene jeder Schlüssel gehört. Für jeden Mehrwert-Filter, der Präzision erfordert (z. B. „nutzt *alle* dieser Technologien"), fügen Sie einen Eintrag zu `filter_conditions` *innerhalb* von `company_filters` hinzu. Standardwerte sind OR. `POST /people/search`. Beide Stile werden akzeptiert, aber `company_filters: {...}` liest sich klarer und entspricht der [Monitore](/de/developer-guides/introduction)-Payload-Form. ### Vollständiges Beispiel Die Abfrage: VPs of Engineering oder CTOs bei US-amerikanischen Mid-Market-Unternehmen, gegründet zwischen 2015 und 2023, mit 100–5.000 Mitarbeitenden, die *sowohl* Kubernetes als auch Docker nutzen, aber ohne Unternehmen mit Sitz in San Francisco. ```bash cURL theme={null} 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 }' ``` ```python Python theme={null} import requests response = requests.post( "https://api.pubrio.com/people/search", headers={ "Content-Type": "application/json", "pubrio-api-key": "YOUR_API_KEY", }, json={ "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, }, ) print(response.json()) ``` ```javascript Node.js theme={null} const response = await fetch("https://api.pubrio.com/people/search", { method: "POST", headers: { "Content-Type": "application/json", "pubrio-api-key": "YOUR_API_KEY", }, body: JSON.stringify({ 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, }), }); console.log(await response.json()); ``` *** ## Referenz zur Schlüssel-Umbenennung Wenn `/people/search` Unternehmensfilter an die gemeinsame Engine übergibt, werden die Standort-/Ortsschlüssel in ihre bloßen Formen umbenannt. Die bloßen Namen sind das, was die Engine — und `filter_conditions[].key` — tatsächlich sieht: | Sie senden (People-API-Name) | Die Engine sieht (Unternehmens-API-Name) | | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | | `company_locations` | `locations` | | `company_exclude_locations` | `exclude_locations` | | `company_places` | `places` | | `company_exclude_places` | `exclude_places` | | `technologies`, `verticals`, `vertical_categories`, `vertical_sub_categories`, `categories`, `keywords`, `founded_dates`, `employees`, `revenues` | unverändert durchgereicht | Deshalb verwendet `filter_conditions[].key` für Unternehmensstandorte die bloßen Namen: ```json theme={null} { "company_places": ["New York", "Boston"], "filter_conditions": [ { "key": "places", "operator": "and" } ] } ``` `{ "key": "company_places", "operator": "and" }` wird stillschweigend ignoriert — die Engine erkennt den präfixierten Namen nicht. Verweisen Sie in `filter_conditions` immer auf den Engine-Namen. *** ## Joins hinter den Kulissen Das Hinzufügen *jedes* Unternehmensfilters wechselt den Join zwischen Personen und Unternehmen von `LEFT JOIN` zu `INNER JOIN`. Personen ohne erkanntes hinterlegtes Unternehmen werden aus dem Ergebnis ausgeschlossen, selbst wenn sie jeden Personenfilter erfüllen. Wenn Ihre Suche auf null Zeilen fällt, sobald Sie `company_locations` oder `technologies` hinzufügen, prüfen Sie, ob Ihr Datensatz Unternehmen mit den erwarteten Personen verknüpft hat. Die Engine bevorzugt hier Korrektheit gegenüber Recall — sie erfindet nie Unternehmen, um den Filter zu erfüllen. Dasselbe Join-Verhalten spiegelt sich in der Antwort wider: Jede zurückgegebene Person enthält ein befülltes `company`-Objekt, sobald ein Unternehmensfilter angewendet wurde. *** ## Gängige Muster Zielen Sie auf eine feste Unternehmensliste (`companies` oder `domains`) ab und fügen Sie dann Personenfilter hinzu, um die richtigen Käufer in jedem einzelnen zu finden. ```json theme={null} { "people_titles": ["VP Marketing", "CMO"], "management_levels": ["vp", "c_suite"], "company_filters": { "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"] } } ``` Beschreiben Sie die Unternehmensform, nicht konkrete Accounts. Verwenden Sie Bereiche und Verticals — die Engine liefert die passenden Personen. ```json theme={null} { "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" } ] } } ``` Finden Sie Käufer bei Unternehmen mit einem bestimmten Stack. AND auf `technologies` ist die typische Überschreibung. ```json theme={null} { "people_titles": ["RevOps", "Sales Operations"], "departments": ["master_sales"], "company_filters": { "technologies": [114, 287, 452], "filter_conditions": [ { "key": "technologies", "operator": "and" } ] } } ``` Finden Sie Entscheidungsträger bei Unternehmen, die das Produkt eines Wettbewerbers nutzen (eine Technologie), aber nicht Ihres (ausgeschlossen über `categories` oder einen separaten Filterdurchlauf). ```json theme={null} { "people_titles": ["VP Sales"], "management_levels": ["vp"], "company_filters": { "technologies": [287] } } ``` Führen Sie den Aufruf dann erneut mit `technologies: [114]` (der Tag-ID Ihres Produkts) aus und vergleichen Sie clientseitig. *** ## Nächste Schritte Vollständige Referenz — jeder Schlüssel, jeder Standard, kopierbare AND-/OR-Rezepte. Das mentale Modell hinter der einheitlichen Filter-Engine. Vollständiges Anfrage-/Antwortschema für `/people/search`. Vollständiges Anfrage-/Antwortschema für `/companies/search`.