用 Zapier、Make 和 n8n 自动颁发 Open Badges（无代码方案）

如果你在运营培训项目、付费课程,或者带有分级机制的邮件列表,那么某人完成课程、完成购买或者达标的那一刻,通常已经在某个地方被记录下来了——一份表单提交、一笔 Stripe 扣款、一个 Mailchimp 标签。徽章本应根据这个事件自动触发颁发,但实际情况很少如此,因为“颁发一份凭证”在大多数工具里都不是原生操作,而专门为一次性自动化搭建自定义 webhook 接收端又显得小题大做。

这正是 Zapier、Make 和 n8n 派上用场的地方。这三者都能直接调用 Badges Ninja API——不需要插件,不需要中间服务器,也不需要部署代码。下面是三个你今天就能直接照搬的方案,以及为了避免徽章悄悄颁发失败,你需要处理好的 API 密钥管理和错误重试机制。

你到底要把什么串联起来

每个方案都遵循同样的结构:触发条件 →(可选)查找收件人 → 向 /awards 发送 HTTP POST。/awards 端点的作用,就是真正把徽章颁发给收件人——你只需指定一个已存在的 badgeId,它就会创建一个独一无二、可验证的 award,并附带专属的验证 URL、二维码和 PDF 证书。如果你还没创建过徽章,请先查看 API 快速上手指南;在运行这些自动化之前,你需要先拿到徽章的 ID。

三个平台的身份验证方式相同:请求头 X-Api-Key 携带一个从控制台生成的密钥。自动化平台对任意 REST API 的 OAuth 流程支持得都不太好,所以在这里用 API 密钥才是正确的选择——长期有效、绑定到你的账户,并且一旦某个 Zap 出问题,可以一键吊销。

第一步:先创建 API 密钥

在你的控制台中,打开 Settings → API Keys,点击 Create Key,并为它取一个能体现用途的名字——比如 zapier-course-completions,而不是 key1。这个命名比听起来更重要:如果六个月后某个自动化流程出了问题,你会希望只吊销 那一个 密钥,而不会影响其他三个恰好共用同一密钥的集成。

密钥只会在创建后完整显示一次。请立刻把它复制到你的自动化平台的安全凭据存储中——Zapier 的“Connection”、Make 的“Connection”,或者 n8n 的 credential——切勿直接写进 Zap、scenario 或 workflow 内部的明文字段里。

方案一:Typeform → Badges Ninja(班级结业表单)

适用场景:一个班级完成课程后,填写一份简短的“我已完成”表单(或者你在自定进度课程的最后一步发送这样一份表单)。

在 Zapier 中:

1. 触发条件:Typeform — New Entry,限定为你的结业表单。
2. 操作:Webhooks by Zapier — POST。
3. URL:https://api.badges.ninja/awards
4. Headers:X-Api-Key: bws_<你的密钥>、Content-Type: application/json
5. Data(从 Typeform 字段映射):

{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

整个 Zap 到这里就完成了。如果表单只在真实完成时触发,就不需要额外的过滤步骤;如果它是一个通用联系表单,就在 webhook 触发前加一个 Filter by Zapier 步骤,检查隐藏字段或答案的值,避免因为垃圾提交或测试提交而颁发徽章。

方案二:Stripe → Badges Ninja(购买即凭证)

适用场景:付费认证考试、课程的高级付费层级,或者会员方案——徽章正是用户购买内容的一部分。

在 Zapier 中:

1. 触发条件:Stripe — New Charge(订阅场景可用 New Invoice Payment Succeeded)。
2. 过滤条件:扣款金额等于目标产品的准确价格——如果你的 Stripe 账户通过同一个 webhook 处理多个产品,这一步就很重要。
3. 操作:Webhooks by Zapier — POST 到 https://api.badges.ninja/awards,Headers 与上面相同。
4. Data:把 charge.billing_details.email 和 charge.billing_details.name 映射到 recipient.email / recipient.name。

把颁发动作绑定到支付事件的好处在于,它天然接近幂等。Stripe 的 charge ID 是唯一的,所以如果你担心 Zap 因为 webhook 重试而重复触发,可以加一个 Storage by Zapier 步骤,在调用 /awards 之前先检查这个 charge ID 是否已经处理过。

方案三:Mailchimp 标签 → Badges Ninja

适用场景:你(或另一个自动化流程)在订阅者达成某个里程碑时手动打标签——参加了一场网络研讨会、完成了一组培育邮件序列、推荐了三个人——你希望这个标签能触发徽章颁发,而无需自己动手调用 API。

在 Zapier 中:

1. 触发条件:Mailchimp — New Tag Added to Subscriber,过滤到具体标签(例如 webinar-attended)。
2. 操作:Webhooks by Zapier — POST 到 https://api.badges.ninja/awards。
3. Data:把 subscriber.email_address 以及 subscriber.merge_fields.FNAME + LNAME 映射到收件人字段。

这种模式在表彰类项目中很受欢迎——销售激励、社区里程碑、活动出席——团队里已经有人习惯给联系人打标签,你只是想让徽章顺理成章地从这个习惯中自动产生。

处理错误与重试

自动化平台对你的徽章数据并不具备事务性,所以要保持你在真正的系统集成中会坚持的那种严谨:

• 检查响应码。 200 表示 award 已成功创建;4xx 通常意味着 badgeId 有误或邮箱格式不对——这是 Zap 里的配置错误,不该盲目重试。5xx 则可以放心重试。
• Zapier:失败的 Zap 运行记录会出现在 Zap History 中,附带完整的请求和响应。对临时性失败开启 Auto-Replay,但也要为持续失败设置邮件/Slack 告警,避免一个悄悄失效的 Zap 意味着连续三个月都没有颁发徽章。
• Make:scenario 原生支持 Error Handler 路由——在 HTTP 模块上附加 Resume 或 Rollback 指令,并把持续性失败导向一个通知模块,而不是直接丢弃。
• n8n:由于它是自托管或云端部署,控制粒度更细,可以把 HTTP Request 节点包裹在 Error Trigger workflow 中,并考虑把失败的 payload 写入一个轻量的备用存储(Airtable、Google Sheets),方便日后手动重放。

在这三种平台上,都要避免“跑绿了就等于成功了”这种陷阱。一个配置错误的 webhook 步骤(URL 写错、缺少 header)也可能返回一个看似 200 的响应,而实际在 Badges Ninja 一侧仍然失败。在任何新自动化上线的第一个月里,建议每周手动抽查一次控制台里的 award 列表。

Make.com 的对应做法

Make 的可视化 scenario 编辑器几乎可以直接对应上面 Zapier 的每一步:

1. Trigger module —— Typeform / Stripe / Mailchimp 的监听模块,与 Zapier 的触发条件相同。
2. HTTP → Make a Request module —— Method 选 POST,URL 为 https://api.badges.ninja/awards,在 Headers 表格中设置 headers(X-Api-Key、Content-Type: application/json),body 使用原始 JSON,变量从触发模块中映射而来。
3. 模块之间可选加入 Filter,用于 Stripe 金额校验或 Typeform 的“真实完成”判断。

Make 的优势在于可见性——scenario 编辑器会在你启用之前,让你看到每一步实际的 JSON payload,这让排查字段映射错误比 Zapier 更偏线性的分步测试视图快得多。

n8n 的对应做法

如果你想自托管,或者你的技术栈中已经在用 n8n 做其他自动化,n8n 会是最合适的选择:

1. Trigger node —— Typeform Trigger / Stripe Trigger / Mailchimp Trigger(均为内置节点)。
2. HTTP Request node —— Method 选 POST,URL 为 https://api.badges.ninja/awards,认证方式设为 Header Auth,X-Api-Key 作为 n8n credential 保存(而不是硬编码在节点里),JSON body 通过引用触发节点输出的表达式来构建。
3. IF node(可选)—— 放在 HTTP Request 节点之前,执行与上面相同的完成/金额判断。

因为 n8n 的 credential 是加密的,并且可以跨 workflow 复用,如果你计划搭建不止一个 Badges Ninja 自动化,这是更简洁的方式——只需配置一次 credential,之后每个需要颁发徽章的 workflow 都可以直接复用。

为什么用通用 webhook 步骤,而不是原生 app

Zapier、Make 和 n8n 都有各自的 app 应用市场,很自然会先想去搜索一个“Badges Ninja”应用,而不是直接用通用的 HTTP/webhook 模块。跳过这一步搜索吧——对于这么小的一个 REST API(创建颁发者、创建徽章、创建 award,就这么多),通用 webhook 步骤能让你十分钟内就上线,完全不依赖某个第三方 app 维护者是否跟得上 API 的变化节奏。专用 app 只会增加一层你并不需要的抽象:你依然要填写同样的 badgeId、recipient.email、recipient.name 字段,只是从 JSON body 换成了一个表单。API 参考文档短到五分钟就能读完,读完之后你会发现,直接用原始 HTTP 反而 更 不脆弱——因为在 Badges Ninja 的 API 变化和你的自动化能重新正常工作之间,不存在任何 app 商店审核周期。

上线之前先测试一次

上面提到的每个平台,都提供了在不等待真实触发事件的情况下,单独运行一次测试的方式:

• Zapier —— 在触发步骤上使用“Test”拉取一条示例数据,再在 webhook 操作上使用“Test”,发出恰好一次真实请求。在启用 Zap 之前,先确认 award 已经出现在你的控制台中。
• Make —— 用“Run once”按钮手动运行一次 scenario,用一份示例 bundle,并检查 HTTP 模块输出气泡里实际的响应 body。
• n8n —— 在 HTTP Request 节点上使用“Execute Node”,配合测试输入数据,可以在编辑器里直接看到请求和响应。

第一次测试运行时,有两点特别值得检查:你写死的 badgeId 是否真的对应你以为的那个徽章(重复复制的 Zap 里残留旧 ID 是个常见错误),以及收件人邮箱字段拿到的是不是一个真实地址,而不是因为映射写错而遗留下来的占位符 {{email}}。这两种错误在自动化平台的“成功”提示里都是不可见的——HTTP 调用无论如何都会返回 200——所以唯一可靠的检查方式,就是打开控制台里的 award,确认收件人正是你预期的那个人。

避免徽章重复颁发

在真实环境下,上面任何一种触发源都可能对同一个事件触发不止一次——Stripe 会在超时后重试 webhook,Typeform 在网络较差时可能重复提交,Mailchimp 的自动化在标签被移除又重新添加时可能再次触发。如果你的徽章颁发不是幂等的,结果就是同一个收件人收到两份相同的凭证,这看起来很不专业,还会引来客服邮件。

最干净的防护方式,是在创建之前先查询一次:在向 /awards 发送 POST 之前,加一个 Search 操作(Zapier 可以用 GET 请求实现“Find Award”,Make/n8n 则用等效的 HTTP GET),查询你自己的 award 记录——如果你不想直接查询 API,一份轻量的 Google Sheets 或 Airtable 日志(由同一个 Zap 在 award 成功后立刻写入)也完全够用。如果针对该收件人 + 徽章组合的记录已经存在,就分支到一个空操作,而不是再次颁发。这只是五分钟就能加上的一步,却决定了一个自动化是你可以完全放手信任的,还是需要你时刻盯着的。

当无代码方案不够用时

这些方案很适合处理单事件触发。但一旦你要从单份 CSV 导出文件里批量颁发成百上千个徽章——比如一整个班级毕业、一份会议参会者名单、一批继续教育学分的批量续期——就该放下自动化平台,直接使用徽章批量上传:它可以在批次中途暂停、恢复,即使浏览器标签页被关闭也不会中断,而这正是无代码 webhook 循环在大批量场景下很难优雅处理的问题。

---

准备好颁发你的第一份可验证凭证了吗? 在 badges.ninja 免费开始——可视化设计器、公开验证页面、PDF 证书、Open Badge v2.0 输出格式。无需信用卡。