Tự động hóa Open Badges với Zapier, Make và n8n (Công thức không cần code)

Nếu bạn đang điều hành một chương trình đào tạo, một khóa học trả phí, hoặc một danh sách email theo cấp bậc, thời điểm ai đó hoàn thành, mua hàng, hoặc đủ điều kiện thường đã được theo dõi ở đâu đó — một câu trả lời form, một giao dịch Stripe, một tag Mailchimp. Huy hiệu lẽ ra phải được cấp tự động ngay sau sự kiện đó. Nhưng điều này hiếm khi xảy ra, vì “cấp một credential” không phải là một hành động có sẵn trong hầu hết các công cụ, và việc xây dựng một bộ nhận webhook riêng cho một lần tự động hóa duy nhất là quá mức cần thiết.

Đây chính xác là lý do Zapier, Make và n8n tồn tại. Cả ba đều có thể gọi trực tiếp API Badges Ninja — không cần plugin, không cần máy chủ trung gian, không cần triển khai code. Dưới đây là ba công thức hoạt động thực tế mà bạn có thể sao chép ngay hôm nay, cùng với cách xử lý API key và hành vi thử lại khi gặp lỗi mà bạn cần thiết lập đúng để huy hiệu không âm thầm cấp thất bại.

Những gì bạn thực sự đang kết nối

Mỗi công thức đều theo cùng một hình mẫu: trigger (kích hoạt) → (tùy chọn) tra cứu người nhận → HTTP POST đến /awards. Endpoint /awards chính là thứ thực sự cấp huy hiệu cho người nhận — bạn trỏ nó đến một badgeId đã tồn tại, và nó sẽ tạo ra một award duy nhất, có thể xác minh, với URL xác minh, mã QR và chứng chỉ PDF riêng. Xem hướng dẫn nhanh về API nếu bạn chưa tạo huy hiệu nào; bạn sẽ cần ID của huy hiệu đó trước khi bất kỳ tự động hóa nào trong số này có thể chạy.

Xác thực cho cả ba nền tảng đều giống nhau: một header X-Api-Key mang theo key được tạo từ dashboard của bạn. Các nền tảng tự động hóa không xử lý tốt các luồng OAuth cho những REST API bất kỳ, vì vậy API key là lựa chọn phù hợp ở đây — tồn tại lâu dài, gắn với tài khoản của bạn, và có thể thu hồi chỉ bằng một cú click nếu một Zap nào đó hoạt động sai.

Tạo API key trước tiên

Từ dashboard của bạn, mở Settings → API Keys, nhấp Create Key, và đặt cho nó một cái tên phù hợp với công việc của nó — zapier-course-completions, chứ không phải key1. Việc đặt tên này quan trọng hơn bạn nghĩ: nếu sáu tháng sau một automation nào đó hoạt động sai, bạn sẽ muốn thu hồi đúng key đó mà không làm hỏng ba tích hợp khác vô tình dùng chung key.

Key chỉ được hiển thị đầy đủ một lần duy nhất, ngay sau khi tạo. Hãy sao chép nó ngay vào kho lưu trữ credential an toàn của nền tảng tự động hóa của bạn — “Connection” của Zapier, “Connection” của Make, hoặc một credential của n8n — không bao giờ dán vào một trường văn bản thuần bên trong chính Zap/scenario/workflow.

Công thức 1: Typeform → Badges Ninja (form hoàn thành khóa học theo nhóm)

Trường hợp sử dụng: một nhóm học viên hoàn thành khóa học và điền một form ngắn “Tôi đã hoàn thành” (hoặc bạn gửi một form như bước cuối cùng của một lộ trình tự học theo tiến độ riêng).

Trong Zapier:

1. Trigger: Typeform — New Entry, giới hạn theo form hoàn thành của bạn.
2. Action: Webhooks by Zapier — POST.
3. URL: https://api.badges.ninja/awards
4. Headers: X-Api-Key: bws_<key của bạn>, Content-Type: application/json
5. Data (ánh xạ từ các trường của Typeform):

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

Vậy là xong toàn bộ Zap. Không cần bước lọc nếu form chỉ kích hoạt khi có hoàn thành thực sự — nhưng nếu đây là một form liên hệ chung, hãy thêm bước Filter by Zapier để kiểm tra một trường ẩn hoặc giá trị câu trả lời trước khi webhook kích hoạt, để bạn không cấp huy hiệu từ spam hoặc các lần gửi thử nghiệm.

Công thức 2: Stripe → Badges Ninja (mua hàng = credential)

Trường hợp sử dụng: một kỳ thi cấp chứng chỉ trả phí, một gói khóa học cao cấp, hoặc một gói thành viên mà huy hiệu là một phần của thứ mọi người đang mua.

Trong Zapier:

1. Trigger: Stripe — New Charge (hoặc New Invoice Payment Succeeded cho các gói đăng ký định kỳ).
2. Filter: số tiền giao dịch bằng đúng giá của sản phẩm được cấp credential — điều này quan trọng nếu tài khoản Stripe của bạn xử lý nhiều sản phẩm qua cùng một webhook.
3. Action: Webhooks by Zapier — POST đến https://api.badges.ninja/awards, với các headers giống như trên.
4. Data: ánh xạ charge.billing_details.email và charge.billing_details.name vào recipient.email / recipient.name.

Điểm hay của việc gắn việc cấp huy hiệu với một sự kiện thanh toán là nó tự nhiên gần với tính idempotent. ID giao dịch của Stripe là duy nhất, vì vậy nếu bạn lo lắng một Zap có thể kích hoạt lại khi webhook được thử lại, hãy thêm một bước Storage by Zapier để kiểm tra xem ID giao dịch đó đã được xử lý hay chưa trước khi gọi /awards.

Công thức 3: Tag Mailchimp → Badges Ninja

Trường hợp sử dụng: bạn gắn tag cho người đăng ký thủ công (hoặc thông qua một automation khác) khi họ đạt một cột mốc — tham dự một webinar, hoàn thành một chuỗi email drip, giới thiệu được ba người — và muốn tag đó kích hoạt việc cấp huy hiệu mà bạn không cần trực tiếp đụng vào API.

Trong Zapier:

1. Trigger: Mailchimp — New Tag Added to Subscriber, lọc theo tag cụ thể (ví dụ webinar-attended).
2. Action: Webhooks by Zapier — POST đến https://api.badges.ninja/awards.
3. Data: ánh xạ subscriber.email_address và subscriber.merge_fields.FNAME + LNAME vào các trường người nhận.

Mẫu này rất phổ biến cho các chương trình ghi nhận thành tích — các chương trình thưởng doanh số SPIFF, cột mốc cộng đồng, tham dự sự kiện — nơi ai đó trong nhóm đã có sẵn thói quen gắn tag cho các liên hệ, và bạn chỉ muốn huy hiệu tự động xuất hiện từ thói quen đó mà không tốn thêm công sức.

Xử lý lỗi và thử lại

Các nền tảng tự động hóa không mang tính transactional với dữ liệu huy hiệu của bạn, vì vậy hãy xây dựng cùng một kỷ luật mà bạn mong muốn từ một tích hợp thực thụ:

• Kiểm tra mã phản hồi. 200 nghĩa là award đã được tạo thành công; 4xx thường có nghĩa là badgeId sai hoặc email không hợp lệ — đó là lỗi cấu hình trong Zap, không phải thứ nên thử lại một cách mù quáng. 5xx thì có thể an toàn để thử lại.
• Zapier: các lần chạy Zap thất bại sẽ xuất hiện trong Zap History cùng với toàn bộ request/response. Bật Auto-Replay cho các lỗi tạm thời, nhưng hãy thiết lập cảnh báo qua email/Slack cho các lỗi lặp lại, để một Zap âm thầm bị hỏng không có nghĩa là ba tháng huy hiệu bị thiếu.
• Make: các scenario hỗ trợ một route Error Handler tích hợp sẵn — gắn chỉ thị Resume hoặc Rollback vào module HTTP, và định tuyến các lỗi kéo dài đến một module thông báo thay vì chỉ bỏ qua chúng.
• n8n: vì đây là nền tảng self-hosted hoặc cloud với khả năng kiểm soát chi tiết hơn, hãy bọc node HTTP Request trong một workflow Error Trigger, và cân nhắc ghi các payload thất bại vào một kho lưu trữ dự phòng nhẹ (Airtable, Google Sheets) mà bạn có thể phát lại thủ công.

Ở cả ba nền tảng, hãy tránh cái bẫy “chạy màu xanh nghĩa là thành công.” Một phản hồi trông giống 200 từ một bước webhook cấu hình sai (sai URL, thiếu header) vẫn có thể thất bại ở phía Badges Ninja. Hãy kiểm tra ngẫu nhiên danh sách award trên dashboard hàng tuần trong tháng đầu tiên của bất kỳ automation mới nào.

Tương đương trên Make.com

Trình xây dựng scenario trực quan của Make gần như tương ứng trực tiếp với các bước Zapier ở trên:

1. Module Trigger — module theo dõi Typeform / Stripe / Mailchimp, giống như trigger trong Zapier.
2. Module HTTP → Make a Request — Method POST, URL https://api.badges.ninja/awards, headers được thiết lập trong bảng Headers (X-Api-Key, Content-Type: application/json), body dưới dạng raw JSON với các biến được ánh xạ từ trigger.
3. Filter tùy chọn giữa các module cho việc kiểm tra số tiền của Stripe hoặc bảo vệ “hoàn thành thực sự” trên Typeform.

Lợi thế của Make ở đây là khả năng quan sát — trình chỉnh sửa scenario cho bạn thấy payload JSON thực tế ở mỗi bước trước khi bạn bật nó lên, giúp việc gỡ lỗi một ánh xạ trường sai nhanh hơn nhiều so với chế độ xem thử nghiệm từng bước tuyến tính hơn của Zapier.

Tương đương trên n8n

n8n là lựa chọn phù hợp nhất nếu bạn muốn tự lưu trữ (self-hosted), hoặc nếu bạn đã tự động hóa các phần khác trong hệ thống của mình ở đó rồi:

1. Node Trigger — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (đều là các node tích hợp sẵn).
2. Node HTTP Request — Method POST, URL https://api.badges.ninja/awards, xác thực được đặt là Header Auth với X-Api-Key của bạn được lưu trữ như một credential của n8n (không hardcode trong node), body JSON được xây dựng từ một expression tham chiếu đến output của node trigger.
3. Node IF (tùy chọn) — cùng cơ chế bảo vệ về hoàn thành/số tiền như trên, đặt trước node HTTP Request.

Vì các credential của n8n được mã hóa và có thể tái sử dụng qua nhiều workflow, đây là lựa chọn gọn gàng hơn nếu bạn dự định triển khai nhiều hơn một automation Badges Ninja — thiết lập credential một lần, tái sử dụng trong mọi workflow cần cấp huy hiệu.

Vì sao nên dùng một bước webhook chung thay vì một ứng dụng gốc

Zapier, Make và n8n đều có các kho ứng dụng riêng, và bản năng đầu tiên thường là tìm kiếm một ứng dụng “Badges Ninja” trước khi chuyển sang một module HTTP/webhook chung. Hãy bỏ qua việc tìm kiếm đó — với một REST API nhỏ như thế này (tạo một tổ chức cấp, tạo một huy hiệu, tạo một award, xong), một bước webhook chung sẽ giúp bạn vận hành thực tế trong mười phút mà không phụ thuộc chút nào vào một nhà phát triển ứng dụng bên thứ ba phải theo kịp các thay đổi của API. Một ứng dụng chuyên biệt sẽ thêm một lớp trừu tượng mà bạn không cần: bạn vẫn sẽ phải điền cùng các trường badgeId, recipient.email và recipient.name, chỉ là thông qua một form thay vì một body JSON. Tài liệu tham khảo API đủ ngắn để đọc trong năm phút, và một khi bạn đã đọc xong, cách tiếp cận HTTP thuần thực ra lại ít mong manh hơn — không có chu trình phê duyệt của kho ứng dụng nào đứng giữa một thay đổi trong API Badges Ninja và việc automation của bạn hoạt động trở lại.

Kiểm thử trước khi kích hoạt thực tế

Mỗi nền tảng ở trên đều cho bạn cách chạy thử một lần thực thi mà không cần chờ một sự kiện trigger thực sự:

• Zapier — dùng “Test” ở bước trigger để lấy một bản ghi mẫu, sau đó “Test” ở action webhook để gửi đúng một request thực sự. Kiểm tra xem award có xuất hiện trong dashboard của bạn trước khi bật Zap lên hay không.
• Make — chạy scenario thủ công một lần (nút “Run once”) với một gói dữ liệu mẫu, và kiểm tra bong bóng output của module HTTP để xem nội dung response thực tế.
• n8n — dùng “Execute Node” trên node HTTP Request với dữ liệu đầu vào thử nghiệm, cho phép bạn xem request và response ngay trong trình chỉnh sửa.

Có hai điều đáng kiểm tra trong lần chạy thử đầu tiên đó: liệu badgeId bạn đã hardcode có thực sự thuộc về huy hiệu mà bạn nghĩ hay không (một ID cũ còn sót lại từ một Zap bị nhân bản là lỗi thường gặp), và liệu trường email người nhận có đang lấy một địa chỉ thực hay chỉ là một placeholder như {{email}} chưa được giải quyết vì lỗi gõ trong ánh xạ. Cả hai lỗi này đều vô hình trước chỉ báo “thành công” của nền tảng tự động hóa — lệnh gọi HTTP vẫn trả về 200 trong cả hai trường hợp — vì vậy cách kiểm tra đáng tin cậy duy nhất là mở award trong dashboard của bạn và xác nhận người nhận đúng là người bạn mong đợi.

Tránh cấp trùng huy hiệu

Trong điều kiện thực tế, bất kỳ nguồn trigger nào ở trên cũng có thể kích hoạt nhiều hơn một lần cho cùng một sự kiện — Stripe thử lại webhook khi hết thời gian chờ, Typeform có thể gửi trùng khi kết nối chậm, các automation của Mailchimp có thể kích hoạt lại nếu một tag bị xóa rồi thêm lại. Nếu việc cấp huy hiệu của bạn không mang tính idempotent, điều đó sẽ biến thành việc người nhận nhận được cùng một credential hai lần, trông thiếu chuyên nghiệp và tạo ra các email hỗ trợ.

Cách bảo vệ gọn gàng nhất là một bước tra cứu trước khi tạo: trước khi POST đến /awards, thêm một action Search (trong Zapier là “Find Award” thông qua một request GET, hoặc HTTP GET tương đương trong Make/n8n) đối chiếu với các bản ghi award của chính bạn — một Google Sheet hoặc log Airtable nhẹ mà chính Zap đó ghi vào ngay sau khi cấp award thành công cũng hoạt động tốt cho việc này nếu bạn không muốn truy vấn API để làm điều đó. Nếu đã tồn tại một bản ghi cho tổ hợp người nhận + huy hiệu đó, hãy rẽ nhánh sang một no-op thay vì cấp lại. Đây chỉ là một bổ sung năm phút, nhưng lại là sự khác biệt giữa một automation bạn có thể tin tưởng để nó tự chạy và một automation bạn phải liên tục trông chừng.

Khi no-code là chưa đủ

Các công thức này xử lý tốt các trigger sự kiện đơn lẻ. Nhưng một khi bạn cần cấp hàng trăm huy hiệu từ một file CSV xuất ra — một nhóm học viên tốt nghiệp, một danh sách người tham dự hội nghị, một đợt gia hạn tín chỉ CE hàng loạt — hãy bỏ qua nền tảng tự động hóa và dùng trực tiếp tải huy hiệu hàng loạt: tính năng này có thể tạm dừng và tiếp tục giữa chừng một lô, và vẫn tồn tại ngay cả khi tab trình duyệt bị đóng — điều mà các vòng lặp webhook no-code không xử lý tốt khi ở quy mô lớn.

---

Sẵn sàng cấp credential có thể xác minh đầu tiên của bạn? Bắt đầu miễn phí tại badges.ninja — trình thiết kế trực quan, trang xác minh công khai, chứng chỉ PDF, đầu ra Open Badge v2.0. Không cần thẻ tín dụng.