LinkedIn API 发布教程:使用 Posts API 发布内容

LinkedIn API 发布教程:使用 Posts API 发布内容

如何通过 Posts API 向 LinkedIn 发布内容:图片和文档上传、x-restli-id 响应头,以及为什么个人主页和公司主页需要两个应用。

发布到 LinkedIn 只需要一次 POST https://api.linkedin.com/rest/posts 调用,创建后的帖子 URN 会出现在响应头 x-restli-id 中,而不是响应体里。媒体内容的处理方式是先注册一次上传,再上传文件字节,然后引用返回的 URN。真正复杂的地方在于权限模型,以及 LinkedIn 按月更新的 API 版本机制。

Posts API 能发布什么,不能发布什么?

对于自然(非付费推广)帖子,LinkedIn 的内容类型表列得很清楚。

内容类型是否支持自然发布
纯文本支持
图片支持
视频支持
文档(PDF、DOC、DOCX、PPT、PPTX)支持
文章支持
多图(MultiImage)支持
投票支持
轮播(Carousel)不支持,仅限付费推广

文档类帖子是一个令人惊喜的发现:PDF 轮播这种在 LinkedIn 上表现出色的格式,通过 Documents API 得到了完整支持。限制是文件不超过 100 MB,且不超过 300 页。LinkedIn 广告语境中的“自然轮播帖”并不受支持;自然发布对应的等价形式是多图(MultiImage)。文章类帖子不会帮你自动抓取链接内容,你需要自己提供标题、描述和一个缩略图的 URN。

结构性的差异在于权限拆分。以个人身份发帖需要 w_member_social 权限。以公司主页身份发帖需要 w_organization_social 权限,读取内容则需要 r_organization_social,而且经过认证的用户必须在该主页上拥有 ADMINISTRATOR、CONTENT_ADMIN 或 DIRECT_SPONSORED_CONTENT_POSTER 角色之一。实际操作中,这是两个独立的 API 产品,分别有各自的访问申请流程,这也是为什么一个既能发个人主页又能发公司主页的工具,最终要维护两个独立的 LinkedIn 应用。我们自己的集成就是这样做的。

注意: 以上数据截至 2026 年 9 月,已对照 Microsoft Learn 上的 LinkedIn Posts API、Images API 和 Documents API 文档核实。平台随时可能在不另行通知的情况下更改这些机制。

认证是如何工作的?审核需要多长时间?

先通过三方 OAuth 获取用户令牌,之后每个请求都要携带三个请求头:Authorization: BearerX-Restli-Protocol-Version: 2.0.0,以及格式为 YYYYMMLinkedIn-Version。最后这个请求头不是可选项,也不是一成不变的。LinkedIn 每月发布新版本并淘汰旧版本,目前页面上就有一条弃用通知,称 Marketing Version 202508 将于 2026 年 8 月 17 日停止支持。去年固定下来的版本号,到今天可能就会导致服务中断。

社区管理相关产品的访问权限需要按应用申请。LinkedIn 在其开发者文档中并未公布审核所需的时间,因此应将其视为未知。另外要注意,r_member_social 是一项受限权限,“仅对获批用户开放”,所以读取用户自己的帖子和写入帖子是两个需要分别申请的权限。

我们无法从 Posts、Images 或 Documents API 页面中核实 LinkedIn 访问令牌的有效期,这些页面都没有说明。请以 LinkedIn 自己的认证文档中的当前数据为准,而不是任何一篇博客文章(包括本文)里的数字。

发布调用的顺序是怎样的?

纯文本帖子只需要一次调用。带媒体内容的帖子需要三步:

  1. 调用 POST /rest/images?action=initializeUpload(或 /rest/documents?action=initializeUpload),并将 initializeUploadRequest.owner 设置为个人或组织的 URN。
  2. 从响应的 value 对象中读取 uploadUrl 以及资源的 URN(imagedocument)。
  3. 将文件字节上传到 uploadUrl。文档上传成功会返回 201。
  4. 调用 POST /rest/posts,设置 authorcommentaryvisibilitydistributionlifecycleState: "PUBLISHED",并将 content.media.id 设置为该资源的 URN。
  5. 从 201 响应的 x-restli-id 响应头中读取新创建帖子的 URN。它不在响应体里。
# 1. register the upload
curl -X POST 'https://api.linkedin.com/rest/documents?action=initializeUpload' \
  -H "Authorization: Bearer $TOKEN" \
  -H 'X-Restli-Protocol-Version: 2.0.0' -H 'LinkedIn-Version: 202608' \
  -d '{"initializeUploadRequest":{"owner":"urn:li:organization:5515715"}}'
# -> value.uploadUrl, value.document = urn:li:document:...

# 2. upload the bytes
curl -i --upload-file ./deck.pdf -H "Authorization: Bearer $TOKEN" "$UPLOAD_URL"

# 3. create the post, then read x-restli-id from the 201
curl -i -X POST 'https://api.linkedin.com/rest/posts' \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -H 'X-Restli-Protocol-Version: 2.0.0' -H 'LinkedIn-Version: 202608' \
  -d '{
    "author": "urn:li:organization:5515715",
    "commentary": "Our Q3 teardown, 12 pages.",
    "visibility": "PUBLIC",
    "distribution": {"feedDistribution":"MAIN_FEED","targetEntities":[],
                     "thirdPartyDistributionChannels":[]},
    "content": {"media": {"title":"deck.pdf","id":"urn:li:document:..."}},
    "lifecycleState": "PUBLISHED",
    "isReshareDisabledByAuthor": false
  }'

资源本身有自己的状态字段:WAITING_UPLOADPROCESSINGPROCESSING_FAILEDAVAILABLE。引用一个还没到达 AVAILABLE 状态的资源,是导致帖子发出去却没带媒体内容的常见原因。

速率限制是怎样的?

LinkedIn 的 Posts API 错误表记录了 429 TOO_MANY_REQUESTS,并建议降低请求频率、延迟后重试,但页面并未说明具体的每应用或每用户请求数上限。我们无法从 Posts、Images 或 Documents API 页面中核实具体的限流数字。LinkedIn 会在开发者后台为你自己的应用公布应用级和用户级的每日限流数据,这才是关于你的配额唯一准确的来源,应以那里的数据为准,而不是假设存在某个通用数字。

有两个限制是明确写出来的,值得在设计时考虑进去:文档上限为 100 MB 和 300 页;图片必须小于 36,152,320 像素,格式为 JPG、GIF 或 PNG,GIF 上限为 250 帧。

注意: 以上数据截至 2026 年 9 月,已对照 Microsoft Learn 上的 LinkedIn Posts API、Images API 和 Documents API 文档核实。平台随时可能在不另行通知的情况下更改这些机制。

真正会让你多花三周时间的地方

两个应用,两次审核。 个人主页发布和公司主页发布是两个独立的产品,各有各的审批流程。如果你的产品两者都要支持,就意味着要跑两套 OAuth 流程、两套凭证,以及两次审核,而且完全可能出现一个通过、另一个没通过的情况。

按月版本管理。 LinkedIn-Version 需要有一套计划:定期升级版本、针对当前版本运行测试,以及安排专人跟踪弃用通知。这是人们在评估开发工作量时最容易忽略的维护成本。

媒体处理流程。 图片、文档和视频都需要两步上传,各自有独立的接口和需要等待的资源状态,还要在上传之前做好格式和大小校验,以免浪费一次上传。

异步处理与部分失败。 /rest/posts 返回的 201,是所有主流平台中能给到的最强确认信号,但在它之前的资源处理步骤是异步的,lifecycleState 也可能返回 PUBLISH_FAILED,需要编辑后重试。建议对“处理中”状态单独建模,具体做法可参考我们的 社交媒体定时发布 API 指南,切勿仅凭上传调用就认定发布已经成功。

如果你还要撰写文案,LinkedIn 字数统计工具 可以显示“查看更多”折叠位置在哪里。

简要总结

  • 只需一次 POST /rest/posts 调用;帖子的 URN 会出现在 x-restli-id 中,而不是响应体里。
  • 媒体内容需要先 initializeUpload,再上传文件,然后把资源 URN 填入 content.media.id
  • 文档(PDF 和 Office 文件)支持自然发布,上限为 100 MB 和 300 页。
  • 个人主页和公司主页使用不同的权限,实际操作中通常需要两个应用。
  • LinkedIn-Version 是必填项,且旧版本会被淘汰。要提前安排好版本升级计划。

一次搞定,而不是每个平台都重新做一遍

如果 LinkedIn 只是你需要接入的众多网络之一,那么按平台逐一开发的工作量是成倍增长,而不是简单相加。BulkPublish 通过一套 REST API 发布到 15 个平台,包括 LinkedIn 个人主页和公司主页(两个应用、两次审核都已经处理好了)以及 LinkedIn 文档类帖子。版本请求头、资源轮询和令牌刷新都由我们负责,当一条面向多个网络的帖子在某个平台发布失败时,会返回 partial 状态,而不是假装全部成功。API 参考文档见 /developers/,REST 集成概览见 /integrations/rest-api/

相关文章