LinkedIn 公开数据 API:个人资料、公司页与动态 | SandBase

想把 LinkedIn 的公开数据接进 agent,往往第一步就得跟 LinkedIn 自己的门槛较劲:登录墙、申请不下来的 OAuth 权限、每次改版就崩的爬虫。一个公开公司页或个人资料在浏览器里明明看得见,但要稳定地接进 B2B 线索补全、招聘或调研的流程里,本身就是一个不小的工程。

SandBase 的 LinkedIn 公开数据 API 把这层搭建成本去掉了。它通过普通 REST 端点读取 LinkedIn 公开的个人资料、公司页、动态和职位信息——一把 SandBase API key,不走 LinkedIn OAuth,也不用 SDK。端点参考只保证信封(id、status、model 和 outputs[0].data);下面展示的业务字段是示例结构、并非保证的 schema,请以真实响应为准核对具体字段。

这不是 LinkedIn 官方的 Marketing 或 Talent Solutions API。 如果你需要以成员身份发帖、代表成员操作账号或管理广告,请用 LinkedIn 官方 API;当你的流程需要的是公开、只读的补全、监测或调研数据时,用 SandBase。想直接试?领取 SandBase API key,再浏览 LinkedIn 端点。

先说结论

• 一个 API 读取 LinkedIn 公开的个人资料、公司页、动态、评论和职位详情。
• 本文的 Model API 端点用 POST /v1/api/linkedin/<path> 调用——只传该端点的参数,不用 SDK,一把 SANDBASE_API_KEY。
• 多数 web-v2 端点以 LinkedIn 的 url 为入参(个人、公司、动态或职位 URL);具体看每个端点的 schema。
• 它只返回公开、只读数据。不能发帖、没有 LinkedIn OAuth 登录、也拿不到私密或需连接关系才可见的数据;鉴权用 SandBase API key。

你到底需要哪个 LinkedIn API?

你的需求	选择	原因
以成员身份发帖、投放广告、操作已授权账号	LinkedIn 官方 API	Marketing 与 Talent Solutions API 面向已授权的成员和广告操作。
读取公开的个人资料、公司页、动态或职位	SandBase LinkedIn 公开数据 API	普通 REST、一把 SandBase key、面向只读流程的结构化 JSON。
访问私密/仅连接可见数据、私信或成员授权字段	都不适用于公开流程	这些数据类型不在本篇公开数据的范围内。

从 LinkedIn API 能拿到什么

web-v2 面负责按 URL 读单个资源。按用途归类:

• 个人资料 —— 按 URL 读取公开成员资料(简介、城市、动态、链接)。
• 公司 —— 按 URL 读取公开公司页(行业、规模、粉丝数、总部、专长、员工)。
• 动态与评论 —— 某个成员或公司的动态、单条动态详情、以及动态评论。
• 职位 —— 职位搜索与职位详情(标题、招聘团队、技能)。

要做更高量级的调研,查线上 LinkedIn API 列表看当前有哪些端点。并非列出的每一项能力都已开放直接调用,所以动手前请以每个端点的在线 API 参考为准。

SandBase 上的 LinkedIn API 页面——带标签的概览,加上端点列表,每个端点标有路径。

LinkedIn 提供的 vs. SandBase 补上的

公开数据来自 LinkedIn。SandBase 并不拥有或运营 LinkedIn,它只是为符合条件的公开数据流程提供一个统一的 API 层。每一项能力变成一个稳定端点,鉴权收敛成一把 key,响应都是可预期的 JSON——于是 agent 可以沿着同一套约定串起”解析一个公司页 → 读它的规模和行业 → 拉它最近的动态”,而不用为每个页面各维护一个爬虫。

快速上手:第一次调用

SandBase 有不止一个 API 面。目录里可能会展示 /apis/v1/... 下的 GET 路径;本文用的是每个端点 API 参考里带厂商前缀的 Model API 路径。不要替换 HTTP 方法或 URL——按你所选端点的参考文档来。

按 LinkedIn URL 读取一个公开公司页:

import os
import requests

resp = requests.post(
    "https://api.sandbase.ai/v1/api/linkedin/web-v2/company-profile",
    headers={
        "Authorization": f"Bearer {os.environ['SANDBASE_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={"url": "https://www.linkedin.com/company/microsoft/"},
)
resp.raise_for_status()
body = resp.json()
if body.get("status") != "completed":
    error = body.get("error", {})
    raise RuntimeError(error.get("message", "LinkedIn request did not complete"))

company = body["outputs"][0]["data"]
# 业务字段是示例结构、并非保证的 schema，请用防御式读取。
print(company.get("name"), company.get("company_size"), company.get("followers"))

curl -X POST https://api.sandbase.ai/v1/api/linkedin/web-v2/company-profile \
  -H "Authorization: Bearer $SANDBASE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://www.linkedin.com/company/microsoft/"}'

每个响应都用同一个信封:一个 id、一个 status、model 名称,以及一个 outputs 数组,其中唯一一项在 data 下携带载荷。读 outputs[0].data 之前先判 status,并查每个端点的参考了解它的运行模式。下面是 company-profile 的示例响应结构——其中业务字段是示例结构、并非保证的 schema,请把数值当作示例,以一份真实响应为准核对具体字段(载荷会变、数值也会随时间变):

{
  "id": "009e56c4-8759-44b3-938b-763043779b79",
  "status": "completed",
  "model": "linkedin/web-v2/company-profile",
  "outputs": [
    {
      "data": {
        "name": "Microsoft",
        "company_id": "1035",
        "company_size": "10,001+ employees",
        "followers": 29171590,
        "headquarters": "Redmond, Washington",
        "website": "https://news.microsoft.com/"
      }
    }
  ]
}

failed 或 timeout 的请求会带上 error 而没有 outputs,所以读 outputs[0].data 之前先判 status。不同端点的响应结构不一样——先看一份真实响应,再按端点逐一对准字段路径。

端点的 API 参考是每个参数名和响应路径的权威来源。

能力地图

能力簇	代表端点	典型用途
公司资料	linkedin/web-v2/company-profile	按公司 URL 做企业信息补全
成员资料	linkedin/web-v2/user-profile	按 URL 做公开资料补全
动态	linkedin/web-v2/company-posts、linkedin/web-v2/user-posts	内容监测、意见领袖追踪
动态评论	linkedin/web-v2/post-comments	互动与情感分析
职位	linkedin/web-v2/job-detail	就业市场与招聘调研
动态评论	linkedin/web-v2/post-comments	互动与情感分析输入

分页方式因端点而异——几个 web-v2 列表端点用 pagination_token 加 start,而 post-comments 用 page。具体看每个端点的 schema。

LinkedIn 端点列表的一部分,在 web-v2 面上。

常见用例

用 LinkedIn 公司 API 做企业信息补全

用 linkedin/web-v2/company-profile 解析一个公司 URL,再读 industry、company_size、followers、headquarters,给 CRM 或线索记录做补全。输入:公司 LinkedIn URL。输出:结构化的企业信息记录。端点:company-profile。

用 LinkedIn 个人资料 API 做人物调研

用 linkedin/web-v2/user-profile 读取公开成员资料,拿到简介、城市和动态信号。输入:资料 URL。输出:结构化的个人资料记录。端点:user-profile。

用 LinkedIn 动态 API 做意见领袖监测

按计划定时轮询某公司或成员的最近动态,持续追踪互动变化。输入:公司或资料 URL。输出:带互动数据的动态列表。端点:company-posts 和 user-posts。

在 agent 工作流里串联调用

因为每个端点共用同一套鉴权和同一个响应信封,agent 可以从一个公开资源走到下一个,而不用为每个页面单独写特例。一个常见的 B2B 模式是这样:

1. 解析公司。 用公司 URL 调 linkedin/web-v2/company-profile,读出 company_id、industry、company_size、followers、headquarters——这就是一条 CRM 记录的企业信息内核。
2. 拉取近期动态。 用同一个公司 URL 调 linkedin/web-v2/company-posts,看这家机构在发什么,再用响应返回的 token 翻页。
3. 补全决策人。 用一个公开成员 URL 调 linkedin/web-v2/user-profile,给这条客户记录附上职位和地点上下文。

每一步都是一个 POST 加一个 url 参数,每一步都返回同样的 { id, status, model, outputs } 结构。你的 agent 只需判一次 status,读 JSON 的那段代码在每一步都能复用——这种一致性正是重点。当你需要的量级超过单 URL 读取时,查线上 LinkedIn API 列表看当前有哪些端点,接入前先对照每个参考确认参数。

一个实用小技巧:把 company-profile 返回的 company_id 缓存下来。它是一个稳定标识符,可以存进你自己的记录里,这样以后重新补全时只需重读会变的字段(比如 followers),而不用从头再解析一次实体。

边界与限制

• 只读、公开数据。 不能发帖、私信、操作连接关系,也拿不到需连接关系才可见的字段。
• 速率与量级。 把响应当作尽力而为的读取;作为客户端韧性措施,遇到 HTTP 429 这类瞬时错误时用退避重试。
• 参数与结构随上游而定。 多数 web-v2 读取以 url 为入参;分页方式各异(pagination_token/start 对 page)。先看真实响应、读 schema。
• 并非所有列出的端点都已可调用。 在依赖某个具体端点之前,先对照在线 API 参考确认。
• 这不是 LinkedIn 官方合作。 SandBase 只是提供对公开数据的统一访问;请遵守 LinkedIn 的条款以及你使用场景下适用的隐私规则。

常见问题

我需要 LinkedIn 开发者应用或 OAuth 吗? 不需要。你用 SANDBASE_API_KEY 向 SandBase 鉴权。这些读取端点不需要你注册 LinkedIn 应用或管理 OAuth。

用什么来标识一个公司或个人? 多数 web-v2 端点以公开的 LinkedIn url 为入参(比如 /company/<name>/ 或 /in/<handle>/)。动态评论用 urn。

分页怎么做? 取决于端点。几个 web-v2 列表端点用 pagination_token 加 start;post-comments 用 page。具体看每个端点的 schema。

能读私密或仅连接可见的数据吗? 不能。这个 API 只返回公开数据。私密字段、私信和需连接关系才可见的数据都不在范围内。

能更高量级地搜人或搜公司吗? 查线上 LinkedIn API 列表看当前有哪些端点、各自支持什么参数,接入前先对照每个端点的参考确认可用性。

从一个公司请求开始

创建一把 SandBase API key,用 company-profile 请求一个公开公司 URL,先看清返回的 schema,再扩展到个人资料、动态或职位。准备好之后:

• 领取 SandBase API key
• 浏览 LinkedIn 端点
• 打开 company-profile 的 API 参考