> ## 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. # Personas + Filtros de empresa > Combina filtros a nivel de persona y a nivel de empresa en una sola llamada a /people/search — el mismo motor de filtros que /companies/search. `POST /people/search` acepta todos los filtros de empresa que acepta `POST /companies/search`. Ya no necesitas obtener primero las empresas, recopilar sus IDs y pasarlos a una segunda consulta de personas — una sola solicitud cubre ambas capas. ## Dos familias de parámetros, un solo cuerpo El cuerpo de una solicitud a `/people/search` se divide conceptualmente en dos familias de filtros. Viven en el mismo nivel del JSON, y las combinas libremente. Filtra por atributos de la *persona*: | Parámetro | Descripción | | ---------------------- | ---------------------------------------------------- | | `people_titles` | Cargos (texto libre o slug) | | `management_levels` | `founder`, `c_suite`, `vp`, `director`, `manager`, … | | `departments` | `master_engineering`, `master_sales`, … | | `department_functions` | Slugs de subdepartamento / función | | `people_locations` | Códigos de país de la ubicación de la persona | | `people_groups` | IDs de grupos guardados | | `peoples` | Valores específicos de `people_search_id` | | `linkedin_urls` | URLs de LinkedIn de la persona | | `social_media` | Identificadores de redes sociales por red | Filtra por atributos de la *empresa* donde trabaja la persona — los mismos nombres que `/companies/search`, con un pequeño conjunto de claves de ubicación con prefijo `company_`: | Parámetro | Descripción | | --------------------------- | ------------------------------------------------------------------------- | | `technologies` | IDs de slug de tecnología que usa la empresa | | `categories` | IDs de slug de categoría | | `verticals` | IDs de slug de vertical | | `vertical_categories` | IDs de slug de categoría de vertical | | `vertical_sub_categories` | IDs de slug de subcategoría de vertical | | `keywords` | Palabras clave de texto libre comparadas con la descripción de la empresa | | `founded_dates` | Rango de año de fundación, p. ej. `[2015, 2023]` | | `employees` | Rangos de empleados, p. ej. `[[100, 500], [501, 1000]]` | | `revenues` | Rangos de ingresos en USD | | `company_locations` | Códigos de país de la sede de la empresa | | `company_exclude_locations` | Códigos de país a excluir | | `company_places` | Nombres de ciudad / región a incluir | | `company_exclude_places` | Nombres de ciudad / región a excluir | | `companies` | Valores específicos de `domain_search_id` | | `domains` | Dominios de empresa específicos | | `company_linkedin_urls` | URLs de LinkedIn de la empresa | El prefijo `company_` existe únicamente en los filtros de ubicación/lugar porque los nombres simples `places` / `locations` ya se usan para la dirección de la *persona*. Todo lo demás usa el nombre simple de empresa (`technologies`, no `company_technologies`). *** ## Construye una consulta en cuatro pasos ¿Quién, exactamente? Cargo, seniority, departamento, país. Mantén esta capa en el **nivel superior** del cuerpo — el predicado de empresa suele encargarse del trabajo de precisión. ¿En qué empresas necesitan trabajar? Industria, tamaño, año de fundación, país de la sede, stack tecnológico. Agrupa esto bajo un objeto **`company_filters: {...}`** para que sea evidente a qué capa pertenece cada clave. Para cualquier filtro multivalor que necesite precisión (por ejemplo, "usa *todas* estas tecnologías"), agrega una entrada a `filter_conditions` *dentro* de `company_filters`. Los valores por defecto son OR. `POST /people/search`. Ambos estilos se aceptan, pero `company_filters: {...}` se lee más claro y coincide con la forma del payload de [Monitores](/es/developer-guides/introduction). ### Ejemplo completo La consulta: VPs de Ingeniería o CTOs en empresas de tamaño medio con sede en EE. UU., fundadas entre 2015 y 2023, con 100-5.000 empleados, que usan *tanto* Kubernetes *como* Docker, pero excluyendo empresas con sede en 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()); ``` *** ## Referencia de remapeo de claves Cuando `/people/search` pasa los filtros de empresa al motor compartido, las claves de ubicación/lugar se renombran a su forma simple. Los nombres simples son lo que realmente ve el motor — y `filter_conditions[].key`: | Envías (nombre de la API de personas) | El motor ve (nombre de la API de empresa) | | ------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | | `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` | se pasan sin cambios | Por eso `filter_conditions[].key` para las ubicaciones a nivel de empresa usa los nombres simples: ```json theme={null} { "company_places": ["New York", "Boston"], "filter_conditions": [ { "key": "places", "operator": "and" } ] } ``` `{ "key": "company_places", "operator": "and" }` se ignora silenciosamente — el motor no reconoce el nombre con prefijo. Siempre haz referencia al nombre del motor en `filter_conditions`. *** ## Los joins detrás de escena Agregar *cualquier* filtro a nivel de empresa cambia el join de personas a empresas de `LEFT JOIN` a `INNER JOIN`. Las personas sin una empresa reconocida en el registro se excluyen del resultado, incluso cuando coinciden con todos los filtros a nivel de persona. Si tu búsqueda cae a cero filas en el momento en que agregas `company_locations` o `technologies`, verifica si tu conjunto de datos tiene empresas vinculadas a las personas que esperas. El motor prioriza aquí la corrección sobre el recall — nunca inventa empresas para satisfacer el filtro. Verás este mismo comportamiento de join reflejado en la respuesta: cada persona devuelta incluye un objeto `company` completo siempre que se haya aplicado algún filtro de empresa. *** ## Patrones comunes Apunta a una lista fija de empresas (`companies` o `domains`), y luego agrega filtros a nivel de persona para encontrar a los compradores correctos dentro de cada una. ```json theme={null} { "people_titles": ["VP Marketing", "CMO"], "management_levels": ["vp", "c_suite"], "company_filters": { "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"] } } ``` Describe la forma de la empresa, no cuentas específicas. Usa rangos y verticales — el motor devuelve las personas que encajan. ```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" } ] } } ``` Encuentra compradores en empresas que usan un stack específico. AND en `technologies` es la anulación típica. ```json theme={null} { "people_titles": ["RevOps", "Sales Operations"], "departments": ["master_sales"], "company_filters": { "technologies": [114, 287, 452], "filter_conditions": [ { "key": "technologies", "operator": "and" } ] } } ``` Encuentra a los tomadores de decisiones en empresas que usan el producto de un competidor (una tecnología) pero no el tuyo (excluido mediante `categories` o un paso de filtrado separado). ```json theme={null} { "people_titles": ["VP Sales"], "management_levels": ["vp"], "company_filters": { "technologies": [287] } } ``` Luego vuelve a ejecutar con `technologies: [114]` (el ID de etiqueta de tu producto) y compara los resultados en el cliente. *** ## Próximos pasos Referencia completa — cada clave, cada valor por defecto, recetas AND/OR copiables. El modelo mental detrás del motor de filtros unificado. Esquema completo de solicitud/respuesta para `/people/search`. Esquema completo de solicitud/respuesta para `/companies/search`.