Skip to main content
跟踪 Pubrio 数据层的演变。

​
2026 年发布版本

v2.4.6 - 人员搜索按书写方式读取部门 (2026 年 10 月)

  • 修复： 人员搜索的 departments 和 department_functions 中，目录里不存在的值现在不返回任何人员，与 management_levels 一致。此前该筛选器会被丢弃，并以正常的 200 返回所有部门的人员。
  • API： 在人员搜索和职位搜索中，部门、职能和管理层级的值不区分大小写、空格和标点：information_technology 读作 master_information_technology。未完整对应任何一项的值，会被读作唯一包含其全部单词的那一项：engineering 读作 master_engineering_technical。
  • API： 人员搜索接受 person_locations 作为 people_locations 的另一个名称；metadata.renamed_fields 会报告该重命名。
  • API： 联系方式查询 与 联系方式查询－批量操作 在条目没有 email 或 phone 时，始终按 first_name + last_name + domain 或 company 查找。这类条目不再需要 is_enable_similarity_search；该参数现在只决定邮箱或电话未找到任何人的条目是否再按姓名查找。
  • API： domain 可以是网址，例如 https://www.stripe.com/；它会被读取为 stripe.com。
  • 修复： 未带 is_enable_similarity_search 发送的姓名 + 域名批量查询，此前返回空的 peoples 列表，仿佛无人匹配。现在，若批量请求中所有条目都不含邮箱、电话或姓名 + 域名/公司，将与单条查询一样被拒绝并返回 400。
  • 修复： 同一批量请求中发送两次的相同姓名 + 公司会被标记为 is_duplicate_input，且只计费一次，与邮箱或电话此前的处理方式一致。
  • API： 每个匹配都带有 match.input_index，即它所对应条目在 peoples 中的位置；部分条目未匹配时，也能把每个匹配对应回原来的行。
  • 修复： 按姓名查询时会搜索该域名下的所有公司记录，因此关联到同一公司另一条记录的人员也能被找到，响应速度约快一倍。
  • API： 搜索相似人员 为每位人员返回介于 0 和 1 之间的 similarity_score，并由 per_page 决定每页数量。
  • 修复： 参考人员或职位仅用于确定相似的标准。其他筛选器（如 people_locations 或 domains）都会缩小结果范围；此前返回的是参考对象本身，其他筛选器被忽略。
  • 修复： 扩张概览 无法及时完成时返回 408，而不是空的 countries 列表。
  • 修复： 职位搜索的 functions 和广告搜索的 reach_tiers 在传入不存在的值时立即返回零结果；此前请求会一直运行到超时。
  • 新增： 枚举与常量——API 接受或返回的所有固定值汇总在一页：职级层级、职能、广告来源与格式、曝光区间、投放平台、信号类型、管理层级。
  • 新增： 职位搜索、新闻搜索和广告搜索指南——筛选器表格、响应解读和可直接复制的示例。
  • API： 职位搜索新增 functions、seniority_ranks、launch_dates、location_ids、created_at 和 is_ascending_order 的文档。响应行现已声明 functions、seniority_rank、source_type、base_salary、experience_requirement、education_requirement 和 employment_type。
  • API： 广告搜索新增 active_dates、reach_tiers、exclude_source_types、created_at、advertisement_search_id 和 is_ascending_order 的文档。source_types 已修正——它会筛选结果（而不仅限于增强），并接受 tiktok 和 apple。响应行现已声明 advertisement_format_normalized、advertiser、advertisement_url、is_company_matched 和 total_impressions 三元组；metadata 记录了 applied_source_types、unsupported_source_types、coverage_notes 和 skipped_source_types。
  • API： 新闻搜索新增 published_at、news_search_id 和 is_ascending_order 的文档，并声明了包括 expansion_signals（设置 is_expansion_signal_available 时返回——这撤销了 v2.3.1 中的移除，当时该标志尚未上线）在内的所有行字段。
  • API： 人员搜索新增 exclude_people_titles、exclude_people_locations、exclude_departments、exclude_department_functions 和 company_exclude_locations 的文档。
  • API： 公司搜索新增 social_media 和 advertisement_status 的文档。
  • API： 所有搜索端点现在都记录了 metadata.ignored_fields——无法识别的请求键会被丢弃而非拒绝，并列在其中。职位、新闻和广告搜索还声明了 pagination 和类型化的 metadata 块，替代此前的自由格式对象。
  • 文档： 四个 schema（job_exclude_locations、advertisement_target_locations、advertisement_exclude_target_locations 以及扩张排名的 domain_search_ids）把描述写在了 $ref 旁边，OpenAPI 3.0 会静默丢弃。现已正常渲染。
  • API： 现已收录 扩张信号搜索（POST /expansions/signals/search）—— 可直接查询构成公司阶段判定的原始带日期信号行，而非其汇总后的公司记录。
  • API： 现已收录 扩张查询（POST /expansions/lookup）—— 扩张搜索的确定性版本，绝不会自动放宽筛选条件，适用于需要可复现结果的仪表盘与定时任务。
  • API： 侦测 expansions 的监控现已提供完整的筛选词汇表与 Webhook 负载说明。参见设置 Webhook。
  • API： 公司扩张详情、对比、摘要与排名端点均已补充 is_include_metadata 说明。API 密钥请求默认返回精简结果 —— 将其设为 true 可获得 confidence_score 及完整模型细节。
  • API： 状态码 中新增扩张相关错误码（40043、40360、40435、40436）。
  • 移除： /companies/{jobs,news,advertisements}/export 参考页面。导出接口返回的是 CSV 附件、消耗独立的 data_export_credit 额度，且不会提供对应搜索端点尚未以 JSON 返回的任何数据 —— 请改用搜索接口配合分页。
  • 移除： /people/enrichment 参考页面，该端点从未实际发布。如需增强联系人数据，请调用 People Lookup 并传入 is_enrichment_available: true。
  • 文档： 已从所有请求体中移除 profile_id。你的 API 密钥本身即可标识工作区，该参数在 API 密钥请求中会被忽略。
  • API： 相似公司与相似人物搜索现已说明其所需的参照标识符。此前 /companies/search/similar 对所有已记录的参数组合都会返回 41847 Missing parameter。
  • API： 公司数据增强 现已说明其在公司记录之外一并返回的 jobs、news、advertisements 与 similar_companies 数组，并提示该调用通常需要 30–60 秒。
  • API： 八个端点现已声明其返回的顶层 metadata，其中包括带有 credit、topup_credit 和 total_credit_cost 的 profile 区块。
  • API： 公司标识符类端点现已完整列出全部九种可接受的标识符，新增 tiktok_url、wantedly_url、tw104_url、rocketpunch_url、remember_url 与 youtrust_url。
  • 文档： API 中最常见的错误 41847 Missing parameter 已添加至状态码。
  • 文档： 认证 现已说明 User-Agent 要求。使用通用 user agent 的客户端会在边缘节点被拦截，返回 HTTP 403 与 error code: 1010，容易被误认为 API 密钥无效。
  • 文档： 请求频率限制 现已说明 Profile Usage 返回的用量与配额字段，包括 total_max_* 如何应用席位倍数。
  • API： 扩张类筛选条件（stages、signal_types、signal_strengths、freshness、momentum、polarity）现已列出允许的取值，并均提示：无法识别的取值会被静默丢弃而非报错 —— 在部分参数上会丢弃整个筛选条件，在另一些参数上则会匹配不到任何内容。
  • API： momentum 接受 advancing、steady 与 pulling_back。Expansion Reference 中 directions 的取值（retreating、new）属于 stage.direction 的响应值，从来都不是有效的筛选值。
  • API： 新闻洞察已更正 —— mentions、topics、sources 与 top_source 是位于 data.totals 内的整数/字符串字段，而非顶层数组。topics 与 sources 是去重后的计数；按项目的明细位于 category_breakdown 与 market_breakdown。
  • API： 广告洞察已更正 —— postings[] 使用缩写字段 r、m、ch、fo、n；reach_tiers[] 是不含计数的 {slug, label} 目录；creatives[] 现已完整记录全部十个字段，包括 image_url、cta 与 has_video。
  • API： 渠道模板的 parameters 字段随 channel_type_slug 而变化 —— 邮件、LinkedIn 与 Twilio 模板各自包含不同的字段集合。
  • 文档： 已移除 API 并不返回的响应字段：User 的 referral_code、相似人物搜索的 similarity_score、LinkedIn 公司查询的 funding_status 与 crunchbase_url、新闻搜索的 expansion_signals，以及扩张信号搜索的 occurs_at / occurs_until。
  • 文档： 状态码表已依据 API 的错误码表重建。此前有九个错误码是错的：40075、40076、40091、40092、40095 被标注为分页与配额错误，实际应为 HTTP 416 下的 41675、41676、41691、41692、41695 —— 而那些被写入文档的编号在系统中另有含义。40003、40602、40603 实际为 40303、40632、40633；40099 并不存在。
  • 文档： 现已收录 HTTP 416。分页与配额超限会返回 416 及 416xx 错误码，而不会静默截断结果集。
  • 文档： 新增监控相关错误码族（40020–40035），其中包括 40021 —— 监控创建后 detection_mode 不可更改。
  • API： per_page 的上限为套餐中的 max_search_per_page（多数套餐为 25）；传入 26 会返回 HTTP 416。page 的上限为 max_search_page。这些限制及其他所有套餐上限均由 Profile 返回，并已列在请求频率限制页面。
  • API： people_contact_types 仅接受 email-work、email-personal 与 phone。无法识别的取值不会被拒绝 —— 而是返回 HTTP 200、emails: null 且不消耗积分，与该联系人确实没有数据的结果无法区分。
  • API： 兑换响应在未找到结果时，emails 与 phones 返回 null 而非 []。
  • API： 渠道模板 create 的参数现已完整说明 —— channel_node_id 是取自 Channel Template Types 的 UUID，并决定 parameters 中哪些字段有效。delete 接受数字型 channel_template_id，且每次仅删除一个版本。
  • API： 监控的 Webhook 校验会执行真实的带签名投递；仅响应 GET 的 URL 仍会失败，details 会返回上游响应体。
  • 新功能： 市场扩张 API。 跟踪哪些公司正在进入哪些市场、进展到了哪一步 — 一个基于真实招聘、新闻、广告、云基础设施和活动信号构建的四阶段阶梯（Exploring → Committing → Expanding → Scaling）。可通过 froms / tos 按走廊搜索，深入单个公司的市场进入情况，并对比同类公司。从快速入门开始。
  • 新功能： 自然语言搜索。 向扩张搜索传入一句自然语言 query（如“正在向英国扩张的金融科技公司”），Pubrio 会将其解析为筛选条件 — 还可通过 is_explain_match 生成基于每家公司真实信号的 AI 匹配说明。
  • API： 结果现在默认使用相关性排序，将获得多种独立信号类型相互印证的公司排在前面；传入 sort_by: "recent" 可纯按时间排序。
  • API： 监控现在可以在职位、新闻和广告之外监测扩张信号（signal_types: ["expansions"]），并且可以通过解析监控从一句自然语言草拟监控配置。
  • API： 监控生命周期现在是单一的 status 字段（draft / active / paused / inactive），取代请求和响应中原有的 is_active / is_paused 布尔值。
  • 新功能： 监控 (Monitors)。 自动信号检测与实时交付 — 无需构建自己的轮询管道，即可跟踪数百万家公司的职位发布、公司新闻和广告活动。只需定义一次筛选条件，Pubrio 便会自动扫描、丰富数据并将匹配的信号交付到您的 Webhook、电子邮件或外展序列。
  • 新功能： 两种检测模式。 可选择 信号优先 (Signal First)（广泛市场扫描）或 公司优先 (Company First)（跟踪指定账户），以匹配您的销售拓展工作流。
  • 新功能： 自动人员丰富。 每次监控触发都可自动查找和兑换匹配公司的联系人 — 支持多层丰富，可按管理级别、部门和职称配置筛选条件。
  • API： 新增 15 个监控端点 — 完整的增删改查、统计、图表、检测日志、Webhook 验证和测试处理。查看监控 API 参考。
  • API： 请求体中不再需要 profile_id。API 密钥现已包含工作区信息。该参数仍可用于向后兼容。
  • API： 为所有 59 个 API 端点添加了 operationId、summary、description 和 tags，以改善 AI 智能体和 MCP 工具的兼容性。
  • 文档： 启用 llms.txt 以支持 AI 爬虫发现。
  • 新功能： AI 智能列表 (Beta)。 用户现在可以上传 CSV 并在电子表格界面中查看，Pubrio 会自动填充缺失的列。
  • 数据： 在 DACH 地区（德国、奥地利、瑞士）新增了 300 万个验证实体。
  • API： /enrich/company 端点的响应时间加快（延迟降低了 200 毫秒）。
  • 新功能： 广告搜索情报。 我们现在索引广告透明度中心和付费搜索库。您现在可以看到一家公司是否在投放广告，在哪里花钱，以及针对哪些关键词。
  • 改进： 增强了对拉美 (LATAM) 地区使用非标准本地化软件的公司的“技术栈”检测。

​
2025 归档：合作伙伴之年

2025 年的标志是我们主要的生态系统集成，将 Pubrio 数据带到您每天使用的平台中。
  • 集成： Ottokit。 推出了用于自主智能体 (Autonomous Agent) 工作流的原生连接器。
  • 集成： Databar。 将 Pubrio 添加为 Databar 市场中的认证提供商，用于无代码研究。
  • 集成： Stripo。 启用了“推送到序列 (Push to Sequence)”功能，允许设计团队将 HTML 模版直接同步到 Pubrio 工作流。
  • 功能： 动态变量注入。 允许模版中的通用占位符在发送时使用实时 Pubrio 数据进行解析。
  • 集成： Clay 原生集成。 成为 Clay 数据丰富菜单中的默认提供商。
  • 数据： 将“隐形的 70%”覆盖范围扩大到包括亚太地区 15 个新的本地注册机构。
最后修改于 2026年10月2日