Threads

概览

提供商 ID 为 threads。元数据记录了两步发布：先创建文本容器，再发布该容器。提供商采用文档中的单次调用路径，把 media_type=TEXT 与 auto_publish_text=true 一起发送，因此一次请求即可创建并发布文本帖子。

要求

• 一个配置了 Threads 用例的 Meta 应用，以及它的 client id 和 client secret。
• 一个已注册、可供授权步骤回调的重定向 URI。
• 一个已授权该应用的 Threads 账号。

凭证

授权码会在 API 主机上交换，随后再按文档中的 60 天交换流程申请长期令牌。连接保存的是该令牌。

连接

redirectUri 必填；两个主机默认使用 Meta 公布的值，因此只提供一个主机的调用方不会在不知情的情况下混用主机对：

{
  "type": "start",
  "provider": "threads",
  "options": { "redirectUri": "https://example.com/oauth/callback/threads" }
}

syndroo connect --input connect.json --json

未提供选项时，授权主机为 https://www.threads.net，API 主机为 https://graph.threads.net，默认范围列表为 threads_basic 加 threads_content_publish。机器调用方可以把 client id 和 secret 作为连接选项传入，也可以把它们作为两个凭证字段读取。

启动步骤会返回一个授权动作，由浏览器在 Threads 授权主机完成；本地 CLI 会自行完成该 OAuth 回调，使用 --redirect-uri 和控制终端，或使用 --callback-url -，如凭证参考所述。这条本地回调路径只针对本地服务器做了模拟测试；尚未连接真实的 Threads 账号。

部署服务器

本页的 syndroo connect 流程保持在本地。如需通过自己的 Cloudflare Worker 运行 Threads OAuth，并从 GitHub Actions 发布，请按照部署服务器操作。该流程使用已确认的主机注册 https://YOUR-WORKER.YOUR-SUBDOMAIN.workers.dev/oauth/callback/threads，并运行 syndroo server connect threads --app-id APP_ID。

自托管 Server。Server 流程使用 @syndroo/[email protected] 和 @syndroo/[email protected]。验收限制见CLI 参考。

首次发布

发送的文本来自目标的 text 发布选项：

{
  "type": "prepare",
  "content": {},
  "targets": [
    { "provider": "threads", "options": { "text": "Hello from Syndroo." } }
  ]
}

syndroo publish --input post.json --json

提供商会自行固定 media_type 和 auto_publish_text；它们不是调用方选项。账号唯一有证据支持的 URL 是个人资料 URL，因此投递结果会报告帖子 ID，并且当已保存的账号有用户名时，还会报告个人资料 URL。本指南不虚构帖子永久链接格式。

能力

清单声明 text。未解决。可获取的 Meta 资料中没有文本长度限制，因此本指南不给出具体数字。

选项

故障排除

提供商从不重试，也不会重新分类。如果在发布调用失败时已经创建容器，就会形成真实的不确定窗口；使用单次调用路径时没有需要核对的已保存容器，调用后的超时仍保持 unknown 且不可重试。

未解决。可获取的 Meta 资料对两个主机应为 .net 还是 .com 存在分歧，也没有通用错误代码表，并且这些资料没有记录 PKCE 支持。因此提供商默认使用该集合中的 .net 主机对。

撤销与安全

未解决。尚未从 Meta 的一手来源获取令牌或应用撤销步骤，因此本指南不提供具体做法。安全的本地步骤是在 Meta 账号设置中移除应用访问权限，然后断开本地连接：

syndroo connect --disconnect <connectionId>