> ## 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. # Filtres personnes + entreprise > Combinez des filtres au niveau personne et au niveau entreprise dans un seul appel /people/search — le même moteur de filtres que /companies/search. `POST /people/search` accepte tous les filtres entreprise que `POST /companies/search` accepte. Vous n'avez plus besoin de pré-récupérer les entreprises, de collecter leurs identifiants, puis de les injecter dans une seconde requête personnes — une seule requête couvre les deux couches. ## Deux familles de paramètres, un seul corps Un corps de requête `/people/search` se divise conceptuellement en deux familles de filtres. Elles se trouvent au même niveau dans le JSON, et vous pouvez les mélanger librement. Filtrer sur les attributs de la *personne* : | Paramètre | Description | | ---------------------- | ---------------------------------------------------- | | `people_titles` | Intitulés de poste (texte libre ou slug) | | `management_levels` | `founder`, `c_suite`, `vp`, `director`, `manager`, … | | `departments` | `master_engineering`, `master_sales`, … | | `department_functions` | Slugs de sous-département / fonction | | `people_locations` | Codes pays du lieu de résidence de la personne | | `people_groups` | Identifiants de groupes enregistrés | | `peoples` | Valeurs spécifiques de `people_search_id` | | `linkedin_urls` | URL LinkedIn de la personne | | `social_media` | Identifiants de réseaux sociaux par plateforme | Filtrer sur les attributs de l'*entreprise* dans laquelle travaille la personne — mêmes noms que `/companies/search`, avec un petit ensemble de clés de lieu préfixées par `company_` : | Paramètre | Description | | --------------------------- | ------------------------------------------------------------------ | | `technologies` | Identifiants slug des technologies utilisées par l'entreprise | | `categories` | Identifiants slug de catégorie | | `verticals` | Identifiants slug de verticale | | `vertical_categories` | Identifiants slug de catégorie verticale | | `vertical_sub_categories` | Identifiants slug de sous-catégorie verticale | | `keywords` | Mots-clés en texte libre comparés à la description de l'entreprise | | `founded_dates` | Plage d'années de fondation, ex. `[2015, 2023]` | | `employees` | Tranches d'effectifs, ex. `[[100, 500], [501, 1000]]` | | `revenues` | Tranches de chiffre d'affaires en USD | | `company_locations` | Codes pays du siège de l'entreprise | | `company_exclude_locations` | Codes pays à exclure | | `company_places` | Noms de villes / régions à inclure | | `company_exclude_places` | Noms de villes / régions à exclure | | `companies` | Valeurs spécifiques de `domain_search_id` | | `domains` | Domaines d'entreprise spécifiques | | `company_linkedin_urls` | URL LinkedIn de l'entreprise | Le préfixe `company_` n'existe que sur les filtres de lieu/emplacement, car les noms bruts `places` / `locations` sont déjà utilisés pour l'adresse de la *personne*. Tout le reste utilise le nom brut de l'entreprise (`technologies`, et non `company_technologies`). *** ## Construire une requête en quatre étapes Qui, exactement ? Intitulé, ancienneté, département, pays. Gardez cette couche au **premier niveau** du corps de la requête — le prédicat entreprise fait généralement le travail de précision. Dans quelles entreprises doivent-elles travailler ? Secteur, taille, année de fondation, pays du siège, stack technologique. Regroupez ces éléments dans un objet **`company_filters: {...}`** pour qu'il soit évident à quelle couche appartient chaque clé. Pour tout filtre à valeurs multiples nécessitant de la précision (ex. « utilise *toutes* ces technologies »), ajoutez une entrée à `filter_conditions` *à l'intérieur* de `company_filters`. Les valeurs par défaut sont OR. `POST /people/search`. Les deux styles sont acceptés, mais `company_filters: {...}` se lit plus clairement et correspond à la structure des payloads [Monitors](/fr/developer-guides/introduction). ### Exemple complet La requête : des VP Engineering ou CTO dans des entreprises de taille moyenne basées aux États-Unis, fondées entre 2015 et 2023, employant de 100 à 5 000 personnes, utilisant *à la fois* Kubernetes et Docker, mais excluant les entreprises dont le siège est à 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()); ``` *** ## Référence du remappage des clés Lorsque `/people/search` transmet les filtres entreprise au moteur partagé, les clés de lieu/emplacement sont renommées vers leur forme brute. Ce sont les noms bruts que le moteur — et `filter_conditions[].key` — voient réellement : | Vous envoyez (nom côté API personnes) | Le moteur voit (nom côté API entreprise) | | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | | `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` | transmis sans changement | C'est pourquoi `filter_conditions[].key` pour les lieux au niveau entreprise utilise les noms bruts : ```json theme={null} { "company_places": ["New York", "Boston"], "filter_conditions": [ { "key": "places", "operator": "and" } ] } ``` `{ "key": "company_places", "operator": "and" }` est silencieusement ignoré — le moteur ne reconnaît pas le nom préfixé. Référencez toujours le nom du moteur dans `filter_conditions`. *** ## Les jointures en coulisses Ajouter *n'importe quel* filtre au niveau entreprise fait basculer la jointure personne-entreprise de `LEFT JOIN` à `INNER JOIN`. Les personnes sans entreprise reconnue enregistrée sont exclues du résultat, même lorsqu'elles correspondent à tous les filtres au niveau personne. Si votre recherche tombe à zéro ligne dès que vous ajoutez `company_locations` ou `technologies`, vérifiez si votre jeu de données comporte des entreprises liées aux personnes que vous attendez. Le moteur privilégie ici l'exactitude au rappel — il n'invente jamais d'entreprises pour satisfaire le filtre. Vous retrouverez ce même comportement de jointure reflété dans la réponse : chaque personne renvoyée inclut un objet `company` renseigné dès qu'un filtre entreprise a été appliqué. *** ## Modèles courants Ciblez une liste fixe d'entreprises (`companies` ou `domains`), puis superposez des filtres au niveau personne pour trouver les bons acheteurs au sein de chacune d'elles. ```json theme={null} { "people_titles": ["VP Marketing", "CMO"], "management_levels": ["vp", "c_suite"], "company_filters": { "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"] } } ``` Décrivez le profil de l'entreprise, pas des comptes spécifiques. Utilisez des plages et des verticales — le moteur renvoie les personnes correspondantes. ```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" } ] } } ``` Trouvez des acheteurs dans des entreprises utilisant une stack spécifique. AND sur `technologies` est le remplacement typique. ```json theme={null} { "people_titles": ["RevOps", "Sales Operations"], "departments": ["master_sales"], "company_filters": { "technologies": [114, 287, 452], "filter_conditions": [ { "key": "technologies", "operator": "and" } ] } } ``` Trouvez des décideurs dans des entreprises utilisant le produit d'un concurrent (une technologie) mais pas le vôtre (exclu via `categories` ou une passe de filtrage distincte). ```json theme={null} { "people_titles": ["VP Sales"], "management_levels": ["vp"], "company_filters": { "technologies": [287] } } ``` Relancez ensuite avec `technologies: [114]` (l'identifiant de tag de votre produit) et comparez les résultats côté client. *** ## Étapes suivantes Référence complète — chaque clé, chaque valeur par défaut, des exemples AND/OR prêts à copier. Le modèle mental derrière le moteur de filtres unifié. Schéma complet de requête/réponse pour `/people/search`. Schéma complet de requête/réponse pour `/companies/search`.