用 Badges Ninja 取代 Moodle 原生 Open Badges（更強的設計工具、相同的 API）

Moodle 從 2.5 版開始就已經原生簽發 Open Badges，對許多課程管理者來說，這已經是不去看其他方案的理由。它內建、免費，技術上也產出符合標準的憑證。那為什麼這麼多 Moodle 管理者簽發到第五十張徽章時,就開始感到沮喪呢?

老實說：Moodle 的徽章系統是為了打勾合規欄位而設計的,不是為了成為一個真正的憑證產品。它能運作,但運作的方式就像一個硬塞進 LMS 裡的功能——堪用、過時,並被所處平台的限制綁死。如果你曾試著讓 Moodle 徽章看起來不只是一個圓形美工圖示,或聽過學員問「等等,我到底要去哪裡看這個東西?」,你就已經體會過這道落差。

這不是在批評 Moodle——它是一套優秀的 LMS,它的徽章條件引擎(課程完成、活動完成、手動頒發、群組成員資格)在「觸發」憑證這件事上,設計得確實很周到。問題出在觸發之後的每一件事:設計工具、領取者體驗,以及徽章在你的 Moodle 環境之外的可見度。這正是 badges.ninja 專門解決的部分,而且你不必放棄 Moodle 的完成邏輯才能用它——你只需要把觸發點指向另一個簽發引擎。

Moodle 原生徽章的不足之處

設計器只是個以座標為基礎的圖像合成工具,不是設計工具。 Moodle 的徽章編輯器讓你選一張底圖、疊上幾個預設的圖示,再用像素偏移調整位置。沒有形狀庫、沒有調色系統,除了圖示集內建的字型之外沒有其他字型選擇。如果你的機構有自己的品牌——標誌、調色盤、特定的憑證視覺語言——Moodle 的編輯器根本無法表現出來。大多數機構最後都是在 Photoshop 或 Canva 裡設計徽章圖案,再上傳一張扁平 PNG,這樣做等於完全失去內建設計器的意義。

領取者需要 Moodle 帳號才能看到自己的徽章。 學員獲頒的徽章存放在他們的 Moodle 個人檔案頁面裡。如果他們已經修完課程、忘記機構帳密,或機構後來註銷了他們的帳號,徽章在他們那一端就等於消失了——即使底層的斷言可能仍能透過 Moodle 的 backpack 連接器或公開徽章頁面解析出來。沒有一個專屬、有品牌識別、隨時可存取的地方,能讓領取者只用電子郵件登入,就看到自己在所有課程中獲得的每一張憑證。

分享功能形同虛設。 Moodle 可以把徽章推送到相容 Mozilla Backpack 的服務,也會為每張徽章公開驗證網址,但沒有內建的「加入 LinkedIn」流程、沒有一鍵分享按鈕,也沒有任何互動數據可以看出徽章簽發後有沒有人看過。對於想讓徽章發揮口碑行銷效果的計畫——訓練營、繼續教育機構、企業培訓——這就是實質的機會成本。

批次操作很笨拙。 如果全體學員在同一時間於 Moodle 內完成觸發活動,批次頒發徽章沒問題。但如果你需要為過去的班級補發徽章、從試算表匯入歷史完成紀錄,或是為完全發生在 LMS 之外的事情簽發徽章,你就得直接寫 SQL 操作 Moodle 資料庫,或是跟根本不是為徽章設計的 CSV 匯入工具搏鬥。

替換模式：保留 Moodle 的觸發機制,更換簽發者

你不需要遷移出 Moodle 就能解決這個問題。最乾淨的做法,是讓 Moodle 繼續做它擅長的事——追蹤課程完成、活動完成、群組成員資格——並在完成條件觸發的那一刻,呼叫 Badges Ninja API,取代(或並行於)它原生的徽章頒發。

Moodle 支援幾種做法:

1. 課程完成 webhook / Moodle Web Services(REST)輪詢。 Moodle 的 core_completion API 會公開每位使用者在每門課程中的完成狀態。一個輕量的排程任務(Moodle 排程 cron 任務,或呼叫 Moodle REST API 的外部 cron 工作)可以輪詢新完成的註冊紀錄,並針對每一筆呼叫 Badges Ninja 的頒發端點。

2. 本地外掛的事件掛勾。 如果你有開發人員,Moodle 的事件系統(\core\event\course_completed)可以由一個小型本地外掛監聽,在完成的當下立即發出 HTTP 請求——沒有輪詢延遲。

3. 用 Zapier/Make/n8n 當黏著劑,如果你想避免動到 Moodle 的程式碼——Moodle 可以把完成事件推送到一個 webhook 接收端,由無程式碼自動化工具轉換成頒發呼叫。

以下是實際的頒發呼叫,前提是你已經有一位完成學員的姓名與電子郵件:

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_moodle_course_completion",
    "recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
    "issuedOn": "2026-08-31"
  }'

或用 Node,寫在你目前執行的排程任務或 webhook 接收端裡:

const response = await fetch("https://api.badges.ninja/awards", {
  method: "POST",
  headers: {
    "X-Api-Key": process.env.BADGES_NINJA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    badgeId: "badge_moodle_course_completion",
    recipient: { name: completedUser.fullname, email: completedUser.email },
    issuedOn: Date.now(),
  }),
});
const award = await response.json();

領取者的電子郵件會以 SHA-256 雜湊儲存,每筆頒發都會自動取得唯一驗證網址、QR code,以及一份 A4 PDF 證書——最關鍵的是,領取者可以在 badges.ninja/me 透過魔法連結登入來認領,完全不需要另外申請 Moodle 帳號。完整的請求/回應格式請參考頒發 API 參考文件,API 金鑰的完整運作方式請見身分驗證指南。

如果你偏好批次處理——例如一次補齊整學期的完成紀錄,而不是接上即時事件——可以把 Moodle 的完成紀錄匯出成 CSV,直接使用批次頒發流程,它支援大型檔案的暫停/續傳。詳細做法請見如何用 CSV 簽發 Open Badges。

設計徽章本身

管線接好之後,實際設計徽章只需要幾分鐘,不必開一張工單給你的網頁團隊。視覺設計器提供超過 80 種形狀範本、真正的調色系統、圖示庫,以及自訂字型上傳功能——所以像「進階統計學——已完成」這樣的徽章,看起來真的可以屬於你機構的品牌,而不是一個通用的 Moodle 成就圖示。

每一組 API 金鑰都可從管理徽章與簽發者的同一個儀表板進行範圍限定與撤銷,所以把整合用的憑證交給開發人員(或像 Zapier 這樣的自動化工具)並不代表要分享你的主帳號登入資訊。

並排比較：領取者體驗

Moodle 在一件事上仍然勝出:如果你唯一的需求是「徽章存在、技術上符合 Open Badge v2.0 標準,並存放在學員已經在用的 LMS 裡」,原生徽章不需要額外成本,也不需要任何整合工作。但一旦你開始在意設計品質、課程結束後的可攜性,或把簽發變成招生/行銷訊號——大多數機構遲早都會走到這一步——這個取捨就會浮現。

想更全面了解其他 Open Badges 平台在價格與功能上的比較,可參考最便宜的 Open Badges 平台比較。如果你的機構正在權衡 Open Badge v2.0 與更新的可驗證憑證規範,Open Badge v2 vs v3 完整解說會告訴你現在該實際採用哪一個。

準備好簽發你的第一張可驗證憑證了嗎?到 badges.ninja 免費開始——視覺設計器、公開驗證頁面、PDF 證書、Open Badge v2.0 輸出格式,不需要信用卡。