functions、seniority_rank 和 location_id。
适用场景
- 单个客户的招聘信号——传入公司,查看他们在招什么岗位、在哪里、什么级别。
- 按角色找潜在客户——在某个国家搜索正在开放资深工程或销售岗位的公司,再用每行的
domain_search_id跳转到人员搜索。 - 增量同步——把
created_at设为你已存储的最新抓取时间进行轮询。
signal_types: ["jobs"] 的监控器。
限定到公司
最快的搜索是指定公司。三种标识符都解析到同一条记录,可以混用:
不指定公司的搜索也是允许的——
{"locations": ["SG"], "seniority_ranks": [5]} 可以正常工作——但会针对整个索引计数。此时 total_entries 是估算值,在非常宽泛的筛选下 is_timeout 可能为 true。
筛选器
文本
分类
日期
两个窗口都是闭区间。
launch_dates 只传一个元素时匹配当天。
地点
分页与排序
一行数据的样子
- 职位名称无法分类时,
functions为null、seniority_rank为0。照常用它们筛选即可——未分类的行只是不会匹配。 posting_date是发布方的日期;created_at是 Pubrio 首次看到该职位的时间,也是默认排序键。job_id和job_search_id是同一个值;任一都可传给职位查询。
相信结果前先读 metadata
ignored_fields 列出端点无法识别的所有请求键。像 "seniorty_ranks" 这样的拼写错误不会让请求失败——它会静默扩大搜索范围。在任何自动化流程中都要检查该数组为空。
示例
- 最近 30 天的资深工程招聘
- 谁在新加坡招销售负责人
- 增量同步
相关
职位搜索参考
所有参数和响应字段。
职位洞察
单家公司按职能、职级、国家和周的统计。
枚举与常量
职级层级和完整的职能词表。
用监控器跟踪职位发布
用 webhook 代替轮询。

