你的用户在你的产品里做出了东西，然后离开去别的地方发布。补上这个缺口是一个常见的功能需求，而这项工作的形态几乎完全取决于一开始做出的一个决定。
那个决定：这是谁的账号？
如果帖子发到你自己的账号，一个 API key 就够了。服务器对服务器，没有授权流程，最简单的形式。
如果帖子发到你用户的账号，你就需要 OAuth。每个用户授权你的应用，你收到一个绑定到他们所选工作区、限定范围的 token。
一开始就把这个决定做对。一开始要求用户粘贴一个 API key 的产品，后来往往还是要迁移到 OAuth，而在此期间，它们已经教会用户一个对双方都不利的习惯：把一个长期有效、权限宽泛的凭证，粘贴进一个第三方产品里。
你原本要自己构建的东西
用一个发布 API，而不是直接对接各平台的原因是：直接集成是一个每个平台都要单独做、而且永远做不完的项目：
- 每个平台各自独立的 OAuth 流程，权限范围和 token 有效期各不相同
- 每个平台各自的刷新任务，一旦悄无声息地失败，就会连带把发布功能拖垮
- 每个平台各自独立的媒体上传流程，上传模型各不相同
- 好几个平台都是异步发布，返回 200 不代表已经发布成功
- 每个平台各自独立的速率限制
- 好几个平台都要经过应用审核，这是你无法掌控的日程，还可能被拒绝
- 每个平台按各自的节奏持续推出破坏性变更
对于一个把发布当作附加功能、而不是核心产品的 SaaS 来说，这是一项永久性的维护负担，而且还压在一件不是你的差异化优势的事情上。
你仍然要自己构建的东西
用一个发布 API 并不能省掉所有工作。你仍然需要：
一个连接界面。 用户在某个地方连接他们的账号，并能看到连接的状态。
一个可见的”已断开”状态。 连接会断掉。用户需要能看到这一点并修复它，而这应该是你产品里的一个状态，而不是一个被你悄悄吞掉的错误。
按你产品的方式来组织内容创作。 这个 API 接收的是文案和频道。你的用户实际在做什么、以及这如何映射成一条帖子，是由你来决定的。
失败处理。 总会有发布失败的情况。现在就决定好，用户是从你这里得知这件事，还是靠”发现帖子没出现”来得知。
选择时该检查什么
| 要求 | 原因 |
|---|---|
| 带精细化权限范围的 OAuth | 多用户产品需要它，狭窄的权限范围能限制影响面 |
| 具体的平台列表 | 而不是笼统的”所有主流网络” |
| 创建时校验 | 这样一条超限的文案会在你能向用户展示的地方失败 |
| 你所在档位的速率限制 | 这个数字决定它能不能随你的业务一起扩展 |
| 结构化的错误信息 | 这样你能呈现出有用的信息，而不是一句”发布失败” |
用 BulkPublish 来做这件事
- 认证： 代表用户账号操作用 OAuth 2.1，代表你自己账号操作用 API key
- OAuth 细节： 要求 PKCE（S256），要求提供
scope且没有隐式默认值，单次使用的授权码，可轮换的刷新 token，token 以Bearer bpat_...的形式传递 - 权限范围：
posts:read、posts:write、media:read、media:write、analytics:read、channels:read、full - 接口面： 59 个有文档记录的接口
- 平台： 15 个
有一条边界值得在设计时留意：OAuth token 能访问帖子、排期、标签、媒体、分析、配额使用情况，以及只读的频道数据。账号管理相关的操作，包括团队、组织、账单、购买积分、API key 和 OAuth 应用管理，对任何 OAuth token（包括 full）都会返回 403，因为这些操作理应在用户断开你的应用之后依然存在。这些操作需要用 API key。
现在就了解这一点，总比在生产环境里遇到一个莫名其妙的 403 要好。
| Free | Pro | Business | |
|---|---|---|---|
| 每日 API 请求数 | 30 | 5,000 | 50,000 |
| API key 数量 | 1 | 5 | 10 |
简而言之
先决定你要发布到的是自己的账号还是用户的账号。如果是用户的账号，从第一天起就用 OAuth，而不是以后再迁移。直接对接各平台是一项压在一件不是你产品的事情上的永久性维护负担，而你仍然要自己构建的部分是：连接界面、一个可见的”已断开”状态，以及在出问题时告知用户。