Sertifier vs Credly：定價、功能，以及更便宜的第三選項

如果你正在評估認證平台，「Sertifier vs Credly」就是那個當你把選項縮小到兩個認真競爭者、想搞清楚哪一個真正符合你的預算和你的專案時，會跳出來的搜尋。兩者都簽發可驗證的數位證書與徽章。兩者都能對接 LinkedIn。兩者都很樂意賣你一份企業合約。而且說實話，兩者都是為一種規模和一套銷售流程而打造的，而那種規模與流程，是很多培訓團隊、訓練營和內部 L&D 小組根本不需要的。

這是一場兩個平台的正面對決 —— 定價模式、設計自由度、Open Badge 相容性，以及領獎者體驗 —— 再加上一個誠實的分析：如果 Sertifier 和 Credly 都不是你專案的正確形狀，那麼一個免費／每月 $9 的第三選項該擺在哪裡。

簡短版本

• Credly 是企業級的老牌霸主。深度整合（Salesforce、Workday、各種 LMS 平台）、在領獎者之間有強大的品牌知名度，以及一套由銷售主導的定價模式 —— 這意味著在你跟某個人談過之前，你看不到任何數字。
• Sertifier 把自己定位為更偏自助、面向中端市場的選項 —— 託管的電子郵件寄送、分析儀表板，以及公開的（雖然到了一定量還是要聯絡才能取得的）定價方案。
• Badges Ninja 是免費起步的選項：一套視覺化徽章設計工具、一條符合 Open Badge v2.0 的簽發流程，以及一個領獎者入口網站，全都不用經過銷售通話或年度最低消費。

這些沒有一個是絕對「比較好」的 —— 它們是為不同的買家打造的。以下是細節。

定價模式

Sertifier 和 Credly 都沒有把定價講得完全一目了然，而這件事本身就透露了它們是為誰打造的。

Credly 根本不公開簽發者的定價。你要申請一場示範，一位銷售代表會評估你的領獎者量與整合需求，然後你會拿到一份報價 —— 通常是一份為數百或數千張憑證量身打造的年度合約。那是標準的企業級 SaaS 行為，而如果你是一個大型認證機構或一支財星 500 大的 L&D 團隊，那套白手套式的流程，以及隨之而來的客戶經理服務，可能是值得的。

Sertifier 在入門層級比較透明 —— 針對較小的量有公開的方案 —— 但一旦你的專案需要有意義的領獎者數量，你又會回到「聯絡銷售」的對話，以及一套從外部很難預測的、以額度或席次計算的模式。如果你曾經試過在簽任何東西之前，估算一個 5,000 人的梯次在任一平台上實際上會花多少錢，你就懂那種摩擦。

Badges Ninja 反過來做：Free 方案涵蓋真實使用量（每年最多 1,200 張憑證），Starter 是 $9／月，Pro 是 $29／月。沒有以額度計算的算術，沒有「索取報價」的高牆。你可以在建立帳號之前，就在定價頁面上看到每個方案的確切上限。

設計自由度

Credly 的徽章視覺是由範本驅動的，而且刻意做得相當受限 —— 平台是為了在數千個簽發者之間維持一致性而最佳化，不是為了量身訂做的設計。Sertifier 特別針對證書給你更多版面控制，有一套瞄準文憑與課程結業的範本庫。

Badges Ninja 的視覺化設計工具在這裡是差異化的關鍵：80 多種形狀範本、自訂圖示與標誌上傳、11 種字型、完整的色彩控制，以及對齊格線的貼齊功能 —— 全都在你用來建立徽章的同一條流程裡，而不是一個你得先匯出、再重新上傳的獨立設計工具。

如果你的品牌識別很重要 —— 一個有著鮮明視覺語言的訓練營、一場有贊助商分級徽章的研討會、一個有自家風格的協會 —— 那麼「從範本挑一個」和「做出你想要的那枚確切徽章」之間的設計落差，會在你使用它的第一週就浮現出來。

Open Badge 相容性

這是唯一一個三個平台在功能上都對等的領域，而且值得把話講白：Credly、Sertifier 和 Badges Ninja 全都簽發符合 Open Badge v2.0 的憑證，帶有 JSON-LD 斷言、公開驗證，以及 LinkedIn 的 Add-to-Profile 整合。如果你唯一的要求是「這張憑證必須是 Open Badge」，那麼這三個沒有一個會在規格相容性上落敗。

它們分歧的地方在於徽章周圍的東西：Credly 的領獎者網路效應（拿到徽章的人一看到 Credly 的介面就認得，因為他們在別的簽發者那裡見過）、Sertifier 針對證書的特定格式，以及 Badges Ninja 把徽章和從同一張憑證自動產生的 PDF 證書結合在一起的做法，再加上一個位於 badges.ninja/me 的領獎者入口網站，領獎者用一個魔法連結就能登入 —— 沒有密碼可忘記。

領獎者體驗

Credly 的領獎者體驗成熟而好認 —— 許多專業人士早就見過來自另一個簽發者的 Credly 徽章通知，這可能對你有利（熟悉感）也可能對你不利（你的徽章看起來跟別人的都一樣）。

Sertifier 的領獎者流程以寄出的電子郵件和一個託管的證書／徽章頁面為核心；它乾淨俐落，但比較沒有圍繞著一個持續性的「錢包」概念來打造。

Badges Ninja 的領獎者入口網站把每一張憑證都當成一個持續增長的收藏的一部分：領獎者免密碼登入，看到他們在這個平台上跨每一個簽發者所賺到的每一枚徽章，並取得一個公開的個人檔案網址（badges.ninja/u/{handle}），可以放進履歷或簡介裡。每一張憑證還附帶一個唯一的驗證網址、一個 QR code，以及一份可下載的 PDF —— 所以領獎者拿到的是怎麼分享的多種選項，而不只是一張用電子郵件寄來的圖片。

整合與 API 存取

Credly 對大型組織來說真正的強項是它的整合面 —— 與各大 LMS 平台、HRIS 系統和認證機構的連接器與夥伴關係，這些機構在 Credly 的 API 上已經打造了好幾年。如果你已經有一套以 Workday 或 Salesforce 為中心的技術堆疊，而且想要一個「見過這種場面」的廠商，那份成熟度是有價值的。

Sertifier 的 API 比較樸素，但涵蓋了要點 —— 以程式化方式簽發、撤銷和查詢證書 —— 而且它以儀表板為先的分析，意味著很多團隊根本不會碰到 API。

Badges Ninja 的 API 刻意做得小巧、以 REST 為先。兩種驗證模式幾乎涵蓋所有使用情境：一個 Cognito JWT（Authorization: Bearer <token>）用於任何跑在 SPA 內部的東西，以及一把 API 金鑰（X-Api-Key: bws_<32-hex>）用於伺服器對伺服器的呼叫。一份最精簡的憑證長這樣：

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "bdg_9f8e7d6c",
    "recipientEmail": "trainee@example.com",
    "recipientName": "Jamie Rivera"
  }'

或用 Python 做同樣的呼叫：

import requests

resp = requests.post(
    "https://api.badges.ninja/awards",
    headers={"X-Api-Key": "bws_1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d"},
    json={
        "badgeId": "bdg_9f8e7d6c",
        "recipientEmail": "trainee@example.com",
        "recipientName": "Jamie Rivera",
    },
)
print(resp.json())

那一次呼叫就會回傳憑證記錄、唯一的驗證網址，以及一個 QR code 參照 —— 不需要另外呼叫來「發布」或「啟用」這張憑證。對於從一個 webhook（課程結業、表單提交、購買事件）觸發簽發的團隊來說，那就是一個整合接點，而不是一套多步驟的交握。完整的請求／回應結構記錄在 awards API 參考文件與驗證指南裡。

分析與報表

如果你的團隊不想自己打造報表，Sertifier 內建的儀表板是一個真正的賣點：開信率、LinkedIn 分享數和證書瀏覽次數都是開箱即用的。Credly 的分析在企業層級走得更遠，有著瞄準 L&D 領導層向高階主管匯報的梯次級與組織級彙總。

Badges Ninja 的互動統計就住在每一張憑證和每一枚徽章上 —— 瀏覽數、驗證頁點擊，以及分享次數 —— 再加上電子郵件寄送追蹤（每一次寄給領獎者的開信、點擊與退信），全都能從儀表板上看到，不用另外設定一個報表模組。它不是一個 BI 平台；它是為了回答「到底有沒有人真的看過這張憑證」而做的，不用你先接好一整套分析堆疊。那條驅動批次簽發的同一套 CSV 工作流，在下面的逐步教學裡有說明。

梯次規模的批次簽發

如果你是簽發給一整個梯次，而不是一次一位領獎者，那麼三個平台都支援某種形式的批次上傳。真正的差別會在批次進行到一半出錯時顯現出來 —— 一封格式錯誤的信、一個重複的領獎者、在 1,200 列中第 340 列時的一次網路小故障。

Credly 和 Sertifier 都能處理批次 CSV 上傳，通常是當成一個單一的工作來處理，失敗時就得從頭重跑。Badges Ninja 的批次憑證流程在伺服器端追蹤進度，所以你可以暫停一個批次、關掉瀏覽器，稍後再繼續，而不用重新簽發那些已經成功的列 —— 當一個「梯次」實際上是從一套報名系統拉出來、夾雜著幾封髒信的 3,000 列時，這很有用。完整的逐步教學，附上上傳與進度畫面的截圖，在如何從 CSV 簽發 Open Badges 裡。

Sertifier 和 Credly 真正勝出的地方

對取捨誠實一點：如果你的專案需要深度的 HRIS／LMS 整合、專屬的客戶經理，或者你簽發憑證的規模大到反正會有一個採購團隊要審合約，那麼 Credly 那套企業級機制就是為此量身打造的，而它在領獎者之間的品牌知名度也是真的。Sertifier 的中端層級託管電子郵件寄送與內建分析儀表板，如果你不想自己打造報表、而你的量又符合它公開的方案，那也是真的有用。

那些強項不會只因為存在一個更便宜的選項就消失。它們對某一類特定的買家來說是正確的選擇 —— 主要是規模較大、重度依賴整合、有預算也有時間走一輪銷售流程的專案。

免費／$9 選項勝出的地方

如果你是一支培訓團隊、一個訓練營、一位研討會主辦人，或一個協會，一年簽發從幾張到幾千張不等的憑證，而且你不想坐著聽完一場銷售通話才知道它要多少錢，那就是 Badges Ninja 填補的那道缺口。你會得到：

• 一套有真正創意控制權的視覺化設計工具，而不是一個範本挑選器
• 透過 CSV 的批次簽發，供梯次規模的憑證使用 —— 逐步教學請看如何從 CSV 簽發 Open Badges
• 一個 REST API（https://api.badges.ninja）供程式化簽發使用，如果你想從一個 webhook 或 LMS 結業事件觸發徽章
• 一個領獎者入口網站和公開個人檔案，這樣賺到的憑證就不會只躺在一個收件匣裡
• 一份你在註冊之前就能看到的定價

決策指南

• 大型企業、深度整合、需要專屬客戶成功經理 → Credly。
• 中型專案、想要託管電子郵件＋分析、能接受在一定量時走一步聯絡銷售 → Sertifier。
• 中小型專案、想要設計控制權和透明定價、不想接一通銷售電話 → Badges Ninja。

想更深入地看 Sertifier，請看這篇 Sertifier 替代方案比較；想看針對 Credly 的拆解，請看這篇 Credly 替代方案比較。兩篇都比這裡更詳細地涵蓋了遷移路徑 —— 包括 Badges Ninja 如何接受既有的 Open Badge ID，這樣即使你切換過來，現有的領獎者記錄也還能繼續運作。

---

準備好簽發你的第一張可驗證憑證了嗎？ 在 badges.ninja 免費開始 —— 視覺化設計工具、公開驗證頁、PDF 證書、Open Badge v2.0 輸出。不需要信用卡。