用 Zapier、Make 和 n8n 自動化 Open Badges（免程式碼範本）

如果你在經營一個培訓計畫、一門付費課程,或是分等級的電子郵件名單,通常有人完成、購買或符合資格的那一刻,系統早就記錄下來了——一份表單回覆、一筆 Stripe 扣款、一個 Mailchimp 標籤。徽章理應自動跟著那個事件發出去。但實際上很少發生,因為「發放憑證」在大多數工具裡並不是內建動作,而為了一次性的自動化去架設自訂 webhook 接收端又太大費周章。

這正是 Zapier、Make 和 n8n 派上用場的地方。三者都能直接呼叫 Badges Ninja API——不需要外掛、不需要中介伺服器、不需要部署程式碼。以下是三個你今天就能複製使用的範本,再加上 API 金鑰處理方式與錯誤重試機制,讓徽章不會悄悄發放失敗。

你要串接的是什麼

每個範本都遵循同一個結構:觸發 → (選擇性)收件人查詢 → HTTP POST 到 /awards。/awards 端點就是實際把徽章發給收件人的地方——你指向一個既有的 badgeId,它就會建立一個獨一無二、可驗證的頒發紀錄,附帶自己的驗證網址、QR code 與 PDF 證書。如果你還沒建立徽章,可以先看 API 快速入門;在執行這些自動化之前,你需要先拿到它的 ID。

三個平台的驗證方式都一樣:一個帶著從你的儀表板產生的金鑰的 X-Api-Key 標頭。自動化平台對於任意 REST API 的 OAuth 流程處理得並不好,所以 API 金鑰在這裡是最適合的選擇——長效、綁定到你的帳號,而且萬一某個 Zap 出錯,一鍵就能撤銷。

先建立 API 金鑰

在你的儀表板中,打開設定 → API 金鑰,點擊建立金鑰,並取一個能對應其用途的名稱——像是 zapier-course-completions,而不是 key1。這個命名習慣比聽起來更重要:如果六個月後某個自動化出了狀況,你會希望能撤銷那一把金鑰,而不會連帶弄壞另外三個剛好共用它的整合。

金鑰只會在建立完成後完整顯示一次。請立刻把它複製到你的自動化平台的安全憑證儲存區——Zapier 的「Connection」、Make 的「Connection」,或是 n8n 的憑證——絕對不要放進 Zap/scenario/workflow 內部的純文字欄位。

範本 1：Typeform → Badges Ninja(結業表單)

使用情境:一個學員群組完成課程並填寫一份簡短的「我完成了」表單(或是你把表單當作自主學習課程的最後一步發送出去)。

在 Zapier 中:

1. 觸發:Typeform — New Entry,限定在你的結業表單上。
2. 動作:Webhooks by Zapier — POST。
3. 網址:https://api.badges.ninja/awards
4. 標頭:X-Api-Key: bws_<your key>、Content-Type: application/json
5. 資料(從 Typeform 欄位對應):

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

這就是整個 Zap。如果表單只在真正完成時觸發,就不需要 Filter 步驟——但如果它是一般聯絡表單,就在 webhook 觸發前加一個 Filter by Zapier 步驟,檢查隱藏欄位或答案值,避免因為垃圾訊息或測試提交而發出徽章。

範本 2：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,標頭同上。
4. 資料:把 charge.billing_details.email 與 charge.billing_details.name 對應到 recipient.email / recipient.name。

把發放行為綁定到付款事件的好處在於:它天生就接近冪等(idempotent)。Stripe 的扣款 ID 是唯一的,所以如果你擔心某個 Zap 因為 webhook 重試而再次觸發,可以加一個 Storage by Zapier 步驟,在呼叫 /awards 之前先檢查該扣款 ID 是否已經處理過。

範本 3：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. 資料:把 subscriber.email_address 與 subscriber.merge_fields.FNAME + LNAME 對應到收件人欄位。

這個模式在表彰計畫中很受歡迎——業務激勵競賽、社群里程碑、活動出席——因為團隊裡已經有人習慣為聯絡人加標籤,而你只是想順便讓徽章從這個習慣中自然產生。

處理錯誤與重試

自動化平台對你的徽章資料並不具備交易性保證,所以要建立起你會期望一個真正整合該有的紀律:

• 檢查回應狀態碼。200 代表頒發已建立;4xx 通常代表 badgeId 錯誤或電子郵件格式不正確——那是 Zap 的設定錯誤,不該盲目重試。5xx 則可以安全地重試。
• Zapier:失敗的 Zap 執行紀錄會出現在 Zap History 中,包含完整的請求/回應內容。針對暫時性失敗開啟自動重播(Auto-Replay),但也要針對持續失敗設定電子郵件/Slack 提醒,以免一個悄悄壞掉的 Zap 造成三個月徽章都沒發出去卻沒人察覺。
• Make:場景(scenario)支援原生的**錯誤處理(Error Handler)**路徑——在 HTTP 模組上附加 Resume 或 Rollback 指令,並將持續性失敗導向通知模組,而不是單純丟棄。
• n8n:因為它可以自架或雲端使用,提供更細緻的控制,可以把 HTTP Request 節點包在一個 Error Trigger 工作流程中,並考慮把失敗的酬載寫入輕量的備援儲存空間(Airtable、Google Sheets),之後手動重播。

三個平台都一樣,要避免落入「跑起來是綠色就代表成功」的陷阱。一個設定錯誤的 webhook 步驟(網址錯誤、缺少標頭)看起來可能是 200,但在 Badges Ninja 這端仍然可能失敗。在任何新自動化上線的第一個月,建議每週抽查一次儀表板的頒發紀錄清單。

Make.com 對應做法

Make 的視覺化場景建構器幾乎能直接對應到上面的 Zapier 步驟:

1. 觸發模組 — Typeform / Stripe / Mailchimp 監看模組,與 Zapier 的觸發相同。
2. HTTP → Make a Request 模組 — 方法為 POST,網址為 https://api.badges.ninja/awards,在 Headers 表格中設定標頭(X-Api-Key、Content-Type: application/json),主體則以原始 JSON 搭配觸發器對應的變數。
3. 選擇性地在模組之間加入 Filter,用於 Stripe 金額檢查或 Typeform 的「真實完成」防護。

Make 的優勢在於可視性——場景編輯器會在你啟用前,顯示每個步驟實際的 JSON 酬載,這讓除錯欄位對應錯誤比 Zapier 較為線性的逐步測試視圖快得多。

n8n 對應做法

如果你想要自架部署,或是已經在那裡自動化其他部分的系統,n8n 是最合適的選擇:

1. 觸發節點 — Typeform Trigger / Stripe Trigger / Mailchimp Trigger(皆為內建節點)。
2. HTTP Request 節點 — 方法為 POST,網址為 https://api.badges.ninja/awards,驗證方式設為 Header Auth,你的 X-Api-Key 存為 n8n 憑證(不要寫死在節點裡),JSON 主體則透過參照觸發節點輸出的表達式建立。
3. IF 節點(選擇性)— 與上述相同的完成/金額防護,放在 HTTP Request 節點之前。

因為 n8n 憑證是加密且可重複使用的,如果你打算建立超過一個 Badges Ninja 自動化,這是更乾淨的選項——設定一次憑證,在每個需要發放徽章的工作流程中重複使用。

為什麼用通用 webhook 步驟而不是原生應用程式

Zapier、Make 和 n8n 都有應用程式商店,直覺上會想先搜尋「Badges Ninja」應用程式,而不是直接使用通用的 HTTP/webhook 模組。跳過那個搜尋吧——對於這麼小的 REST API(建立簽發者、建立徽章、建立頒發紀錄,就這樣),通用 webhook 步驟能讓你十分鐘內上線,完全不依賴第三方應用程式維護者是否跟得上 API 的變動。專屬應用程式只會多一層你不需要的抽象:你還是得填入同樣的 badgeId、recipient.email 和 recipient.name 欄位,只是透過表單而不是 JSON 主體。API 參考文件短到五分鐘就能讀完,讀完之後你會發現,原始 HTTP 做法其實更不容易出問題——因為在 Badges Ninja API 變動與你的自動化正常運作之間,不存在應用程式商店的審核週期。

上線前先測試

以上每個平台都提供不必等待真實觸發事件、就能執行單次測試的方式:

• Zapier — 在觸發步驟上使用「Test」拉取一筆範例紀錄,再對 webhook 動作使用「Test」,發出剛好一次真實請求。在啟用 Zap 之前,先確認頒發紀錄出現在你的儀表板中。
• Make — 用範例資料手動執行一次場景(「Run once」按鈕),並檢查 HTTP 模組輸出氣泡中的實際回應內容。
• n8n — 在 HTTP Request 節點上使用「Execute Node」搭配測試輸入資料,讓你能在編輯器中直接看到請求與回應內容。

第一次測試執行時有兩件事值得檢查:你寫死的 badgeId 是否真的對應到你以為的那個徽章(重複的 Zap 留下過期 ID 是常見錯誤),以及收件人電子郵件欄位是否真的抓到了實際的地址,而不是因為對應輸入錯誤而未被解析的預留位置像 {{email}}。這兩個錯誤在自動化平台的「成功」指示上都看不出來——HTTP 呼叫無論如何都會回傳 200——所以唯一可靠的檢查方式,就是打開儀表板中的頒發紀錄,確認收件人正是你所預期的那個人。

避免重複發放徽章

上面提到的每一種觸發來源,在真實環境條件下都可能不只觸發一次——Stripe 會在逾時時重試 webhook,Typeform 在連線不穩時可能重複提交,Mailchimp 自動化在標籤被移除又重新加上時可能再次觸發。如果你的徽章發放不具備冪等性,結果就會變成收件人收到同一份憑證兩次,看起來很不專業,也會產生客服信件。

最乾淨的防護做法是在建立之前先查詢一次:在 /awards POST 之前,加一個搜尋動作(Zapier 的「Find Award」透過 GET 請求,或是 Make/n8n 對應的 HTTP GET),查詢你自己的頒發紀錄——如果你不想直接查詢 API,一個輕量的 Google 試算表或 Airtable 紀錄表,由同一個 Zap 在成功頒發後立刻寫入,也一樣能用。如果該收件人 + 徽章組合已經有紀錄,就轉向無動作分支,而不是再次發放。這只是五分鐘就能加上的功能,卻是「一個你能放心無人看管的自動化」和「一個你得隨時盯著的自動化」之間的差別。

什麼時候免程式碼不夠用

以上範本很適合處理單一事件觸發。但一旦你要從單一 CSV 匯出檔案發放數百張徽章——一整個群組畢業、一份研討會出席名單、一次大量繼續教育學分更新——就跳過自動化平台,直接使用批次徽章上傳:它能在批次中途暫停與恢復,即使關閉瀏覽器分頁也能存續,這是免程式碼 webhook 迴圈在大量處理時做不到的。

---

準備好發出你的第一張可驗證憑證了嗎? 立即免費開始使用 badges.ninja——視覺化設計工具、公開驗證頁面、PDF 證書、Open Badge v2.0 輸出格式。無需信用卡。