अपनी वेबसाइट पर बैज सत्यापन एम्बेड करें (न iframe, न SDK)

अगर आप credential जारी करते हैं, तो देर-सबेर कोई पूछेगा: “मुझे कैसे पता चले कि यह बैज असली है?” इसका ईमानदार जवाब कभी “PNG पर भरोसा कीजिए” नहीं होना चाहिए। Open Badge v2.0 इसका हल एक सार्वजनिक, मशीन-पठनीय सत्यापन एंडपॉइंट से देता है, और अपनी साइट पर “Verified” विजेट लगाने में लगभग दस पंक्तियों का कोड लगता है — न iframe, न थर्ड-पार्टी एम्बेड स्क्रिप्ट, और न ही कोई SDK।

यह पोस्ट दिखाती है कि एंडपॉइंट को कैसे कॉल करें और नतीजा कैसे दिखाएँ — vanilla JavaScript में, और सर्वर पर Node व Python में। साथ ही यह भी बताती है कि “सत्यापन” असल में क्या जाँचता है, यह एंडपॉइंट badges.ninja द्वारा प्राप्तकर्ताओं को पहले से दिए जाने वाले मानव-उपयोग वाले पेजों के साथ कहाँ फिट होता है, और वे गलतियाँ कौन-सी हैं जिनसे सत्यापन विजेट पूरा दिखता है पर चुपचाप कुछ भी साबित नहीं करता।

“Verified” का असल मतलब क्या है

Open Badge v2.0 असर्शन एक JSON-LD दस्तावेज़ है जिसकी बनावट तय होती है: खुद असर्शन (किसे मिला, कब), BadgeClass का संदर्भ (यह क्या है, मानदंड कौन तय करता है), और जारीकर्ता प्रोफ़ाइल का संदर्भ (कौन इसकी गारंटी दे रहा है)। जब आप किसी बैज को “सत्यापित” करते हैं, तो असल में तीन अलग चीज़ें जाँच रहे होते हैं:

1. क्या असर्शन मौजूद है और resolve होता है। award ID असली है, अंदाज़े से बनाई या बदली हुई नहीं।
2. क्या इसे रद्द किया गया है। जारीकर्ता बाद में बैज रद्द कर सकता है — गलती से जारी हुआ credential, नीति का उल्लंघन, या खत्म हो चुका प्रमाणन — और सही सत्यापनकर्ता को यह दिखाना चाहिए, सिर्फ़ यह पुष्टि नहीं कि रिकॉर्ड मौजूद है।
3. क्या पूरी कड़ी आपस में जुड़ी है। असर्शन के badge और जारीकर्ता संदर्भ वास्तव में असली, मेल खाने वाले रिकॉर्ड तक पहुँचते हैं, अनाथ या बेमेल ID तक नहीं।

जो सत्यापन विजेट सिर्फ़ किसी URL को पिंग करके 200 स्टेटस देखता है, वह बिंदु 2 को पूरी तरह चूक जाता है। रद्द किया गया असर्शन भी ठीक से resolve होता है — बस उसके पेलोड में रद्दीकरण का फ़्लैग होता है। अगर आपका विजेट सिर्फ़ “रिक्वेस्ट सफल हुई या नहीं” देखता है, तो रद्द किया गया credential भी verified दिखेगा, जो विजेट न होने से भी बुरा है।

सार्वजनिक मानव-पेज बनाम API एंडपॉइंट

https://badges.ninja पर जारी हर award को एक सार्वजनिक URL मिलता है, जिसे प्राप्तकर्ता सीधे साझा कर सकते हैं, और उसे देखने के लिए साइनअप की ज़रूरत नहीं:

ज़्यादातर प्राप्तकर्ता इसी पेज को LinkedIn, रिज़्यूमे या ईमेल सिग्नेचर में लिंक करेंगे — यह इंसानों के लिए बना है, बैज की इमेज, जारीकर्ता और जारी करने की तारीख दिखाता है, और इसके लिए आपको कुछ नहीं करना पड़ता। नीचे वाला API एंडपॉइंट वही असर्शन संरचित JSON-LD के रूप में लौटाता है, जो तब काम आता है जब आप हमारे पेज पर लिंक भेजने के बजाय अपना UI बना रहे हों।

एंडपॉइंट

GET https://api.badges.ninja/certify-badge/award/{guid}

किसी auth हेडर की ज़रूरत नहीं — यह जान-बूझकर सार्वजनिक है, क्योंकि Open Badges का पूरा मकसद यही है कि कोई भी (नियोक्ता, रिक्रूटर, लाइसेंसिंग बोर्ड) बिना अकाउंट के credential सत्यापित कर सके। लौटाए गए असर्शन के सटीक फ़ील्ड नामों समेत पूरा अनुबंध सत्यापन दस्तावेज़ों में है।

award का GUID दें, जो आपको अपने जारी करने के रिकॉर्ड से मिलेगा या प्राप्तकर्ता द्वारा आपके साथ साझा किए गए badges.ninja/awards/<guid> लिंक से निकाला जा सकता है।

Vanilla JS: fetch करें और दिखाएँ

पूरा विजेट यही है। कोई build स्टेप नहीं, कोई npm पैकेज नहीं, इसे सीधे किसी भी पेज पर डाल दें:

<div id="badge-verify"></div>
<script>
  async function renderBadgeVerification(awardId, mountId) {
    const el = document.getElementById(mountId);
    el.textContent = "Checking badge status";
    try {
      const res = await fetch(
        `https://api.badges.ninja/certify-badge/award/${awardId}`
      );
      if (!res.ok) {
        el.textContent = "Credential not found.";
        return;
      }
      const assertion = await res.json();
      // —— revocation check first, a resolvable assertion isn't enough on its own
      if (assertion.revoked) {
        el.textContent = `Revoked: ${assertion.revocationReason || "no reason given"}`;
        return;
      }
      el.textContent = `Verified, issued ${new Date(assertion.issuedOn).toLocaleDateString()}`;
    } catch (err) {
      el.textContent = "Verification check failed.";
    }
  }
  renderBadgeVerification("REPLACE_WITH_AWARD_ID", "badge-verify");
</script>

REPLACE_WITH_AWARD_ID की जगह असली award GUID डालें। क्लाइंट-साइड इंटीग्रेशन बस इतना ही है: CSS से जूझने के लिए कोई iframe सीमा नहीं, और कोई थर्ड-पार्टी स्क्रिप्ट नहीं जो सत्यापन के साथ अपने analytics या ट्रैकिंग पिक्सल खींच लाए।

सर्वर-साइड: Node

अगर आप अपने बैकएंड पर सत्यापन करना चाहते हैं — मान लीजिए अपने नियंत्रण वाले प्रोफ़ाइल पेज पर “Verified Partner” बैज दिखाने से पहले, या ऑनबोर्डिंग फ़्लो में credential को प्रमाण मानने से पहले — तो fetch वही रहता है, बस DOM वाला हिस्सा हट जाता है:

async function verifyAward(awardId) {
  const res = await fetch(
    `https://api.badges.ninja/certify-badge/award/${awardId}`
  );
  if (!res.ok) return { verified: false, reason: "not_found" };
  const assertion = await res.json();
  if (assertion.revoked) {
    return { verified: false, reason: assertion.revocationReason || "revoked" };
  }
  return { verified: true, issuedOn: assertion.issuedOn, badge: assertion.badge };
}

सर्वर-साइड: Python

import requests
# —— resolve the assertion, then check revocation before trusting it
def verify_award(award_id):
    res = requests.get(f"https://api.badges.ninja/certify-badge/award/{award_id}")
    if res.status_code != 200:
        return {"verified": False, "reason": "not_found"}
    assertion = res.json()
    if assertion.get("revoked"):
        return {"verified": False, "reason": assertion.get("revocationReason", "revoked")}
    return {"verified": True, "issued_on": assertion.get("issuedOn"), "badge": assertion.get("badge")}

दोनों उदाहरण non-200 जवाब को exception फेंकने के बजाय “not found” मानते हैं। सार्वजनिक सत्यापन एंडपॉइंट के लिए टूटी हुई या अंदाज़े से बनी award ID एक अपेक्षित इनपुट है, अपवाद नहीं, इसलिए उसे पकड़ी गई त्रुटि की जगह सामान्य शाखा की तरह संभालें।

किसी और का UI एम्बेड करने के बजाय नतीजे को अपनी स्टाइल दें

क्योंकि ऊपर का विजेट बस आपके अपने DOM में एक fetch कॉल है, हर पिक्सल आपके हाथ में है। एक आम तरीका है जवाब से सीधे तीन दृश्य अवस्थाएँ बनाना:

• Verified — हरा चेक, “Verified” और जारी करने की तारीख, आपकी साइट के बैज/टैग कॉम्पोनेंट से मेल खाती स्टाइल में।
• Revoked — हल्की या लाल अवस्था जो रद्द करने का कारण छिपाने के बजाय दिखाए। प्राप्तकर्ताओं और तीसरे पक्ष, दोनों को चुपचाप विफलता के बजाय ईमानदार “क्यों” से फ़ायदा होता है।
• Not found — दिखने में इसे “revoked” जैसा ही मानें (झूठी सफलता वाली अवस्था न दिखाएँ), पर शब्द अलग रखें, क्योंकि पेज पढ़ने वाले के लिए गलत ID और जान-बूझकर किया गया रद्दीकरण अलग स्थितियाँ हैं।

इसमें किसी कॉम्पोनेंट लाइब्रेरी की ज़रूरत नहीं। verified / revoked / not_found पर एक switch और तीन CSS क्लास काफ़ी हैं।

कैशिंग, ताकि एंडपॉइंट पर बार-बार चोट न हो

सत्यापन एंडपॉइंट सार्वजनिक और बिना प्रमाणीकरण का है, यानी प्रति-रिक्वेस्ट क्रेडिट खर्च की चिंता नहीं — फिर भी अगर आप इसे क्लाइंट-साइड बिना कैशिंग के कॉल करते हैं, तो हर पेज लोड पर एक नेटवर्क राउंड ट्रिप होता है। जिस पेज पर हर विज़िटर को वही बैज दिखता है (जैसे फ़ुटर में “Verified Partner” बैज), वहाँ हर रिक्वेस्ट पर दोबारा fetch करने के बजाय नतीजे को सर्वर-साइड छोटे TTL के साथ कैश करें — पाँच से पंद्रह मिनट काफ़ी हैं, क्योंकि रद्दीकरण कोई तेज़ी से बदलने वाला संकेत नहीं है:

const cache = new Map();
async function verifyAwardCached(awardId, ttlMs = 10 * 60 * 1000) {
  const hit = cache.get(awardId);
  if (hit && Date.now() - hit.at < ttlMs) return hit.result;
  const result = await verifyAward(awardId);
  cache.set(awardId, { result, at: Date.now() });
  return result;
}

प्रति-विज़िटर विजेट के लिए (जैसे कोई प्राप्तकर्ता अपने निजी साइट पर अपना credential एम्बेड करे), कैश छोड़ दें और पेज लोड पर सीधे ताज़ा कॉल करें — उस पैमाने पर एक अतिरिक्त रिक्वेस्ट नगण्य है।

badges.ninja प्राप्तकर्ताओं को पहले से क्या देता है

पूरी तरह कस्टम एम्बेड बनाने से पहले यह जान लेना अच्छा है कि बिना कुछ किए क्या पहले से उपलब्ध है। हर award के सार्वजनिक पेज में शेयर और एम्बेड स्निपेट तैयार मिलते हैं, जिन्हें प्राप्तकर्ता बिना कोई कोड लिखे सीधे कॉपी कर सकते हैं:

अगर आपका उपयोग-मामला “प्राप्तकर्ता को दिखाने देना कि उसका बैज असली है” है, तो उसके badges.ninja/awards/<guid> पेज का लिंक देना अक्सर कस्टम विजेट बनाने से सरल है — यह वही मानव-पेज है जो पहले दिखाया गया, और verified/revoked का फ़र्क यह पहले से संभालता है। इस पोस्ट वाला कस्टम विजेट तब बनाएँ जब सत्यापन की स्थिति आपके अपने प्रोडक्ट के UI के भीतर दिखानी हो — जैसे पार्टनर डायरेक्टरी, आंतरिक ऑडिट डैशबोर्ड, या उम्मीदवार के बताए प्रमाणन जाँचने वाला हायरिंग टूल — जहाँ किसी दूसरी साइट पर भेजना सही UX नहीं है।

iframe या वेंडर विजेट क्यों नहीं?

कुछ प्लेटफ़ॉर्म सत्यापन स्थिति एम्बेड करने के लिए <iframe src="https://vendor.example.com/verify-widget"> जैसा स्निपेट थमा देते हैं। यह चलता है, पर इसकी असली कीमतें हैं: आप अंदर की सामग्री को अपनी साइट के अनुरूप रीस्टाइल नहीं कर सकते (वेंडर ने जो CSS भेजा, वही मिलेगा), यह एक cross-origin दस्तावेज़ जोड़ता है जिसे आपकी Content-Security-Policy को स्पष्ट रूप से अनुमति देनी पड़ती है, और हर पेज लोड पर तीसरे पक्ष के iframe होस्ट को रिक्वेस्ट जाती है, चाहे विज़िटर को सत्यापन स्थिति की परवाह हो या नहीं। दो-कॉल वाला fetch विजेट इन तीनों से बचाता है — यह आपका DOM है, आपकी स्टाइल है, और यह तभी चलता है जब आप इसे कॉल करने का फ़ैसला करें।

पूरी सत्यापन कड़ी को परखना

अगर आप स्टेटस विजेट से ज़्यादा गहरा कुछ बना रहे हैं — जैसे credentials के बैच को जाँचने वाला ऑडिट टूल, या कंप्लायंस रिपोर्ट — तो असर्शन पर रुकने के बजाय पूरी कड़ी को परखें। असर्शन एक badge URL (BadgeClass: नाम, विवरण, मानदंड) का संदर्भ देता है, और BadgeClass आगे एक issuer URL (संगठन प्रोफ़ाइल) का। कठोर सत्यापनकर्ता तीनों को resolve करता है और पुष्टि करता है कि वे आपस में संगत हैं — बैज सचमुच उसी जारीकर्ता का है जिसका वह दावा करता है, असर्शन सचमुच उसी बैज का संदर्भ देता है जिसका वह दावा करता है — सिर्फ़ यह नहीं कि शीर्ष-स्तर का असर्शन 200 लौटाता है। एकल-credential स्टेटस विजेट को इतनी गहराई नहीं चाहिए, पर यह ढाँचा मौजूद है यह जानना काम आता है, अगर कोई पार्टनर या ऑडिटर कभी पूछे कि “आपका सत्यापन असल में कितना गहरा जाता है?”

बचने योग्य आम गलतियाँ

• सिर्फ़ HTTP स्टेटस जाँचना। जैसा ऊपर बताया, रद्द किया गया असर्शन भी resolve होता है। हमेशा assertion.revoked पढ़ें, सिर्फ़ स्टेटस कोड से सत्यापन का अनुमान न लगाएँ।
• साझा कॉम्पोनेंट में award ID हार्डकोड करना। अगर विजेट कई प्राप्तकर्ताओं के पेजों पर दोबारा इस्तेमाल होना है, तो award ID को पैरामीटर के रूप में लें (data attribute, query string, prop), स्क्रिप्ट में गढ़ी हुई literal के रूप में नहीं।
• नेटवर्क त्रुटियों को चुपचाप निगल जाना। जो try/catch कुछ लॉग नहीं करता और असल में गायब बैज जैसा ही “not found” दिखाता है, वह बाद में डीबगिंग को कष्टदायक बना देता है। अपनी त्रुटि शाखाओं में, कम से कम लॉग में, “नेटवर्क कॉल विफल हुई” और “API ने मना किया” में फ़र्क करें।
• क्लाइंट-साइड ऐप में हर रेंडर पर दोबारा सत्यापन। अगर विजेट किसी React या Vue कॉम्पोनेंट के भीतर है जो बार-बार री-रेंडर होता है, तो प्रति mount एक बार (या कैशिंग वाले हिस्से के अनुसार प्रति कैश TTL विंडो एक बार) सत्यापित करें, हर री-रेंडर पर नहीं।

क्या इसमें क्रेडिट लगते हैं, और क्या यह Free प्लान पर चलता है?

नहीं। सत्यापन एंडपॉइंट जान-बूझकर उस क्रेडिट सिस्टम के बाहर है जो जारी करने को नियंत्रित करता है — बैज वैध है या नहीं यह जाँचने में जारीकर्ता का कुछ खर्च नहीं होता, और इसे कॉल करने वाले विज़िटर के पास अकाउंट, API key या कोई प्लान टियर होना ज़रूरी नहीं। यह तब भी सच है जब बैज Free, Starter या Pro प्लान पर जारी हुआ हो: सत्यापन credential का अपना गुण है, जारीकर्ता की सदस्यता से बँधी कोई सुविधा नहीं। इसी वजह से आप इस विजेट को अनिश्चित ट्रैफ़िक वाले सार्वजनिक पेज (करियर पेज, पार्टनर डायरेक्टरी) पर बेफ़िक्र होकर लगा सकते हैं, अपने अकाउंट से जुड़ी रेट लिमिट की चिंता किए बिना — आप एक रीड-ओनली, सार्वजनिक एंडपॉइंट कॉल कर रहे हैं, प्रमाणीकृत API रूट नहीं।

एक बात साफ़ कह देना ज़रूरी है: एंडपॉइंट द्वारा लौटाए गए असर्शन JSON में प्राप्तकर्ता का कच्चा ईमेल पता शामिल नहीं होता। प्राप्तकर्ता का ईमेल बैकएंड पर hash करके रखा जाता है, ठीक इसलिए कि सार्वजनिक सत्यापन जवाब से निजी संपर्क जानकारी स्क्रैप न की जा सके — जो मिलता है वह credential की पुष्टि के लिए काफ़ी है (बैज, जारीकर्ता, तारीखें, रद्दीकरण स्थिति), और award ID दोहराकर देखने वाले किसी के लिए एंडपॉइंट लीड-जनरेशन टूल नहीं बन जाता।

अपना पहला सत्यापन-योग्य credential जारी करने के लिए तैयार?

badges.ninja पर मुफ़्त शुरू करें — विज़ुअल डिज़ाइनर, सार्वजनिक सत्यापन पेज, PDF प्रमाणपत्र, Open Badge v2.0 आउटपुट। क्रेडिट कार्ड की ज़रूरत नहीं।

असर्शन के हर फ़ील्ड की पूरी टिप्पणी-सहित संरचना के लिए JSON-LD फ़ील्ड संदर्भ देखें। और अगर आप credentials को सिर्फ़ सत्यापित नहीं, बल्कि प्रोग्रामैटिक रूप से जारी कर रहे हैं, तो API क्विकस्टार्ट में प्रमाणीकरण और वह award-creation कॉल बताई गई है जिससे इस एंडपॉइंट का आउटपुट बनता है।