
图文消息草稿接口怎么接?从认证头到请求体的最小路径
围绕图文消息草稿接口的接入路径写的一篇文章,解释认证方式、请求体结构、适用场景以及和基础转换接口的边界。
“图文消息草稿接口怎么接?”
如果你已经有基础的 Markdown 转微信 HTML 能力,下一步最常见的问题就是这个。
因为很多团队真正想要的,不只是“转得出来”,而是:
- 直接生成公众号草稿
- 少做后台粘贴
- 把内容更顺地推进到发布前状态
图文消息草稿接口解决的是什么问题
它解决的是:
把排版后的内容进一步提交为公众号图文草稿。
所以它不是一个普通的 HTML 转换接口,而是更靠近发布链路的能力。
如果没有它,一个典型流程通常是:
- 本地或服务端生成微信 HTML
- 手动进入公众号后台
- 粘贴正文
- 手动设置封面和保存草稿
而有了图文消息草稿接口之后,这几步可以收缩成一次调用。
当前公开示例里的接口形式
当前示例里,对应接口是:
POST /api/v1/article-draft需要的认证头有 3 个:
Wechat-AppidWechat-App-SecretMd2wechat-API-Key
这 3 个头分别代表两层权限:
- 公众号自身凭证
- 你的 md2wechat 服务凭证
这也是为什么它和基础转换接口不一样。
最小请求体应该长什么样
从当前公开示例看,请求体大致是:
{
"markdown": "# 标题\n\n\n\n正文内容",
"theme": "default",
"fontSize": "medium",
"convertVersion": "v1",
"coverImageUrl": "https://example.com/cover.jpg"
}也就是说,它通常需要:
- Markdown 内容
- 主题
- 字号
- 转换版本
- 封面图
这比基础转换接口多了一层“草稿化”的上下文。
接入时的推荐顺序
比较稳的接法通常不是一上来就接草稿接口,而是:
- 先确认基础转换接口已经跑通
- 再确认公众号凭证和 API Key 都可用
- 最后再接图文消息草稿接口
这样做的原因很简单:
- 先排除 Markdown 和主题问题
- 再排除凭证和权限问题
- 最后再排除草稿创建问题
如果三层一起调试,定位错误会比较慢。
图文消息草稿接口适合谁
下面这些人群比较适合直接接它:
- 高频发布的公众号团队
- 想让 AI/Agent 直接推进草稿的人
- 已经有稳定 Markdown 内容来源的人
- 希望减少后台重复劳动的人
如果你只是偶尔发一篇文章,基础转换接口可能已经够用。
但如果你开始在意工作流效率,这个接口就很关键。
它和小绿书草稿接口有什么区别
图文消息草稿接口更偏:
- Markdown 长文
- 主题排版
- 封面图
- 更完整的文章结构
而小绿书草稿接口更偏:
- 标题
- 轻量正文
- 多图数组
所以两者应该分别讲,而不是混在一个“高级草稿接口”里含糊带过。
一个更现实的产品边界
很多用户会把“图文消息草稿接口怎么接”理解成纯技术问题。
其实它同时也是产品边界问题。
因为这意味着你已经从:
- 基础排版能力
走到了:
- 与公众号后台更深的流程集成
所以在官网和文档里,这个接口应该明确标成高级能力,而不是埋在示例里。
总结
图文消息草稿接口的接法并不复杂,真正要搞清楚的是它的权限层级和工作流位置。
更稳的顺序是:
- 先跑通基础转换
- 再准备公众号凭证和 API Key
- 最后接图文消息草稿
这样更容易排错,也更容易把它纳入 Agent First 的发布链路。
更多文章

md2wechat 工具矩阵:CLI、Skill、Obsidian、飞书插件分别适合谁
梳理 md2wechat 相关项目的分工,帮助用户按自己的工作流入口选择更合适的接入方式。

feishu-md2wechat:把飞书文档一键转成公众号文章
介绍 feishu-md2wechat 的用途、适配场景、导出方式和高级 API 价值,帮助飞书用户理解更适合自动化的公众号排版流程。

微信公众号草稿 API 是什么?为什么它比“只转 HTML”更有价值
解释微信公众号草稿 API 的作用、适用场景、与 Markdown 转 HTML 的区别,以及为什么它是 Agent First 工作流里更关键的一层。
邮件列表
加入我们的社区
订阅邮件列表,及时获取最新消息和更新