Personas + Filtros de empresa

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.

Nivel de persona
Nivel de empresa

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

Decide el predicado de personas

¿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.

Decide el predicado de empresa

¿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.

Elige AND/OR por filtro mediante filter_conditions

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.

Envía la solicitud

POST /people/search. Ambos estilos se aceptan, pero company_filters: {...} se lee más claro y coincide con la forma del payload de Monitores.

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.

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
  }'

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())

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:

{
  "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

Account-Based Marketing (ABM)

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.

{
  "people_titles": ["VP Marketing", "CMO"],
  "management_levels": ["vp", "c_suite"],
  "company_filters": {
    "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"]
  }
}

Descubrimiento del perfil de cliente ideal (ICP)

Describe la forma de la empresa, no cuentas específicas. Usa rangos y verticales — el motor devuelve las personas que encajan.

{
  "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" }
    ]
  }
}

Prospección impulsada por tecnología

Encuentra compradores en empresas que usan un stack específico. AND en technologies es la anulación típica.

{
  "people_titles": ["RevOps", "Sales Operations"],
  "departments": ["master_sales"],
  "company_filters": {
    "technologies": [114, 287, 452],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ]
  }
}

Desplazamiento de competidores

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).

{
  "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

filter_conditions

Referencia completa — cada clave, cada valor por defecto, recetas AND/OR copiables.

Resumen de filtros

El modelo mental detrás del motor de filtros unificado.

Referencia de People Search

Esquema completo de solicitud/respuesta para /people/search.

Referencia de Company Search

Esquema completo de solicitud/respuesta para /companies/search.

Monitor

Búsqueda

Filtros

Personas

Expansión

Dos familias de parámetros, un solo cuerpo

Construye una consulta en cuatro pasos

Ejemplo completo

Referencia de remapeo de claves

Los joins detrás de escena

Patrones comunes

Próximos pasos

filter_conditions

Resumen de filtros

Referencia de People Search

Referencia de Company Search

​Dos familias de parámetros, un solo cuerpo

​Construye una consulta en cuatro pasos

​Ejemplo completo

​Referencia de remapeo de claves

​Los joins detrás de escena

​Patrones comunes

​Próximos pasos

filter_conditions

Resumen de filtros

Referencia de People Search

Referencia de Company Search

Dos familias de parámetros, un solo cuerpo

Construye una consulta en cuatro pasos

Ejemplo completo

Referencia de remapeo de claves

Los joins detrás de escena

Patrones comunes

Próximos pasos