5 मिनट से कम में CSV से Open Badges कैसे जारी करें

अगर आपने कभी किसी समूह को एक-एक प्राप्तकर्ता करके credential जारी किए हैं, तो आप समस्या पहले से जानते हैं: यह लगभग दस लोगों से आगे स्केल नहीं करता, इससे पहले ही यह नाम और ईमेल कॉपी-पेस्ट करने वाली पूरी दोपहर में बदल जाता है। 40 लोगों का एक bootcamp समूह, 500 लोगों की एक सम्मेलन उपस्थित सूची, या 5,000 लोगों का कॉर्पोरेट प्रशिक्षण रोलआउट — इन सबको एक ही चीज़ चाहिए — एक सूची अपलोड करें, एक badge चुनें, Issue पर क्लिक करें, और चले जाएँ।

https://badges.ninja पर Bulk Credentials बिल्कुल यही करता है। यह मार्गदर्शिका पूरे प्रवाह को कवर करती है: अपनी CSV तैयार करना, बैच कॉन्फ़िगर करना, उसे चलते हुए देखना, और असल दुनिया के गड़बड़ मामलों को संभालना — टाइपो वाली एक प्राप्तकर्ता पंक्ति, आधे में रुक गया एक बैच, या एक ऐसा प्रोग्राम जो dashboard के बजाय अपने खुद के सिस्टम से उसी तरह जारी करना चाहता है।

शुरू करने से पहले: आपको क्या चाहिए

दो चीज़ें, और दोनों शायद आपके पास पहले से हैं:

1. एक badge — visual designer में एक बार डिज़ाइन किया गया, बैच के हर प्राप्तकर्ता के लिए दोबारा इस्तेमाल किया जाता है। अगर आपने अभी तक कोई नहीं बनाया है, तो अपना पहला सत्यापन-योग्य प्रमाणपत्र डिज़ाइन करने पर हमारी गाइड देखें।
2. प्राप्तकर्ताओं की एक CSV — नाम, ईमेल, और (वैकल्पिक रूप से) जारी करने की तारीख। पूरा schema बस इतना ही है।

आपको हर प्राप्तकर्ता के लिए अलग जारीकर्ता खाता, एक mail server, या कोई कोड नहीं चाहिए। इस खंड में सब कुछ dashboard में ही होता है।

चरण 1: अपनी CSV तैयार करें

प्राप्तकर्ता सूची का प्रारूप जानबूझकर न्यूनतम रखा गया है:

name,email,issued_on
Maria Gonzalez,maria@example.com,2026-07-01
David Kim,david@example.com,2026-07-01
Priya Patel,priya@example.com,

• name — आवश्यक। assertion और प्रमाणपत्र पर प्राप्तकर्ता फ़ील्ड भरता है।
• email — आवश्यक। यह Open Badge v2.0 assertion पर प्राप्तकर्ता की पहचान बन जाता है — संग्रहीत करने से पहले प्रत्येक credential के लिए एक अलग salt के साथ hash किया जाता है, कभी भी सादे रूप में नहीं रखा जाता।
• issued_on — वैकल्पिक। इसे खाली छोड़ें और बैच उस क्षण का उपयोग करता है जब हर पंक्ति संसाधित होती है; अगर आप ऐसे समूह का बैकफ़िल कर रहे हैं जिसने असल में पिछले महीने पूरा किया था, तो इसे स्पष्ट रूप से भरें।

अधिकांश प्रोग्राम मालिक इसे सीधे वहीं से एक्सपोर्ट करते हैं जहाँ वे पहले से completion ट्रैक करते हैं — Airtable, Google Sheets, किसी प्रशिक्षक द्वारा सौंपी गई एक स्प्रेडशीट, या किसी LMS ग्रेडबुक से निकाली गई एक CSV। किसी विशेष एक्सपोर्ट टूल की ज़रूरत नहीं; इन तीन कॉलम वाली कोई भी CSV काम करती है।

आम CSV गड़बड़ियाँ (और Preview उन्हें कैसे पकड़ता है)

असल दुनिया की प्राप्तकर्ता सूचियों में कुछ समस्याएँ लगातार आती रहती हैं, आमतौर पर इसलिए कि CSV दो या तीन स्रोत शीट्स को मिलाकर बनाई गई थी:

• ईमेल पतों में पीछे की खाली जगह — किसी PDF रोस्टर या Google Form एक्सपोर्ट से कॉपी-पेस्ट अक्सर एक अदृश्य स्पेस साथ ले आता है। स्प्रेडशीट सेल में यह ठीक दिखता है पर अपलोड पर ईमेल सत्यापन में विफल हो जाता है।
• डुप्लिकेट पंक्तियाँ — वही प्राप्तकर्ता दो बार आ जाता है क्योंकि एक समूह सूची और देर से पंजीकरण करने वालों की सूची बिना डुप्लिकेट हटाए जोड़ दी गई।
• असंगत तारीख प्रारूप — 2026-07-01 वाला एक कॉलम किसी दूसरे एक्सपोर्ट के 07/01/2026 के साथ मिल जाता है। ISO 8601 (YYYY-MM-DD) पर टिके रहें और यह पूरी तरह गायब हो जाता है।
• हेडर के बड़े-छोटे अक्षरों का बेमेल — Email बनाम email बनाम E-mail। पार्सर आम रूपांतरों को लेकर उदार है, पर पूरी तरह से कस्टम हेडर नाम अपने आप मैप नहीं होगा।

इनमें से कोई भी घातक नहीं है — Preview चरण (नीचे) कुछ भी जारी होने से पहले हर एक को सामने ला देता है, तो सुधार यह होता है कि “स्प्रेडशीट संपादित करें, दोबारा अपलोड करें”, न कि “पता लगाएँ कि 3,000 प्राप्तकर्ताओं में से किसे टूटा हुआ badge मिला” ।

चरण 2: बैच कॉन्फ़िगर करें

dashboard से Credentials → Bulk Credentials खोलें और वह badge चुनें जो आप जारी कर रहे हैं। यह वह चरण है जहाँ आप वह सब सेट करते हैं जो पूरे बैच पर लागू होता है: badge स्वयं, एक साझा जारी करने की तारीख अगर आप CSV में प्रति-पंक्ति तारीखें नहीं डाल रहे, और (अगर आपकी जारीकर्ता प्रोफ़ाइल में है तो) वह LinkedIn संगठन ID जो हर प्राप्तकर्ता को एक क्लिक में credential अपनी प्रोफ़ाइल में जोड़ने देगी।

यह दोबारा जाँचने का अच्छा क्षण है कि आपने जो badge चुना है वह अंतिम संस्करण है — प्राप्तकर्ता वही छवि और मानदंड देखेंगे जो जारी करते समय उससे जुड़े थे, वह नहीं जो आप बाद में अपडेट करते हैं।

चरण 3: अपलोड और Preview

अपनी CSV डालें और प्लेटफ़ॉर्म उसे पार्स करता है, आपको एक preview टेबल दिखाता है, और जो कुछ वह संसाधित नहीं कर सकता उसे चिह्नित करता है — एक अनुपस्थित ईमेल, एक गलत प्रारूप वाली तारीख, एक डुप्लिकेट पंक्ति। जब तक आप preview की पुष्टि नहीं करते, कुछ भी जारी नहीं होता।

यह preview चरण जितना दिखता है उससे ज़्यादा मायने रखता है। 2,000 पंक्तियों वाली CSV की एक पंक्ति में टाइपो आँख से चूकना आसान है, और इसे 1,999 सही पंक्तियों के जारी होने से पहले पकड़ना कहीं सस्ता है बजाय बाद में उसे सुलझाने की कोशिश करने के। चिह्नित पंक्तियों को अपनी स्प्रेडशीट में ठीक करें, दोबारा अपलोड करें, और preview अपडेट हो जाता है।

चरण 4: बैच चलाएँ

Issue दबाएँ और बैच संसाधित होने लगता है। एक प्रोग्रेस बार पूर्ण बनाम शेष पंक्तियों को ट्रैक करता है, और बैच सर्वर-साइड चलता है — आपको tab खुला रखने की ज़रूरत नहीं, और बैच के बीच में अपना laptop बंद करने से आपकी जगह नहीं खोती।

यह आख़िरी बात स्पष्ट रूप से कहने लायक है क्योंकि बड़े समूहों के लिए असल में यही विवरण मायने रखता है: बैच की स्थिति सर्वर पर रहती है, आपके browser में नहीं। अगर आपका कनेक्शन टूट जाए, आपका laptop सो जाए, या आप बस tab बंद कर दें क्योंकि एक मीटिंग शुरू हो रही है, तो बैच शून्य से दोबारा शुरू होने के बजाय चलता रहता है (या ठीक वहीं से फिर शुरू होता है जहाँ आपने रोका था, अगर आपने रोका था)। 40 लोगों के bootcamp समूह के लिए यह अच्छी सुविधा है। 5,000-पंक्ति के कॉर्पोरेट रोलआउट के लिए, यह “यह बस काम करता है” और “किसी को बीस मिनट तक browser tab की देखभाल करनी पड़ती है” के बीच का फ़र्क है।

आप किसी चल रहे बैच को जानबूझकर भी रोक सकते हैं — मान लीजिए, कोई 3,000-पंक्ति के रन के बीच में बताता है कि badge के मानदंड टेक्स्ट में बदलाव चाहिए — समस्या ठीक करें, और पहले से पूर्ण पंक्तियों को दोबारा जारी किए बिना फिर से शुरू करें।

चरण 5: विफलताएँ संभालें

असल प्राप्तकर्ता सूचियों में खराब पंक्तियाँ होती हैं: टाइपो वाला एक ईमेल डोमेन, एक नाम फ़ील्ड जो असल में खाली है, दो एक्सपोर्ट की गई शीट्स को मिलाने से आई एक डुप्लिकेट प्रविष्टि। जब कोई पंक्ति विफल होती है, तो बैच रुकता नहीं — यह बाकी को संसाधित करता रहता है और बाद में समीक्षा के लिए विफलता को चिह्नित कर देता है। आपको एक नतीजा एक्सपोर्ट मिलता है जो ठीक-ठीक दिखाता है कि कौन-सी पंक्तियाँ सफल रहीं और कौन-सी नहीं, ताकि आप पूरी सूची दोबारा जाँचने के बजाय सिर्फ़ विफल पंक्तियों को ठीक करके एक छोटा फ़ॉलो-अप बैच दोबारा चला सकें।

यह उस CSV-एक्सपोर्ट आदत के लिए मायने रखता है जो credentials dashboard पर पहले से आम है — आप किसी भी समय जो असल में जारी हुआ उसकी एक CSV निकाल सकते हैं, अपनी स्रोत सूची से मिलान कर सकते हैं, और ठीक-ठीक जान सकते हैं कि अभी भी किसे badge चाहिए।

API का रास्ता: वही प्रवाह, कोई Dashboard नहीं

ऊपर की हर बात यह मानती है कि कोई dashboard पर बैठकर wizard के ज़रिए क्लिक कर रहा है। अगर आपके completion पहले से किसी सिस्टम में रहते हैं — एक LMS, एक CRM, एक स्प्रेडशीट automation — तो आप उसी bulk-credential प्रवाह को सीधे Awards API से चला सकते हैं।

प्रति-प्राप्तकर्ता एक न्यूनतम जारी करने वाला कॉल ऐसा दिखता है:

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_9f8e7d6c5b4a",
    "recipient": {
      "name": "Maria Gonzalez",
      "email": "maria@example.com"
    },
    "issuedOn": "2026-07-01T00:00:00Z"
  }'

या Python में, उसी CSV से पढ़ी गई पंक्तियों पर लूप करते हुए जिसे आप अन्यथा हाथ से अपलोड करते:

import csv
import requests

API_KEY = "bws_1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d"
BADGE_ID = "badge_9f8e7d6c5b4a"

with open("recipients.csv") as f:
    for row in csv.DictReader(f):
        requests.post(
            "https://api.badges.ninja/awards",
            headers={"X-Api-Key": API_KEY},
            json={
                "badgeId": BADGE_ID,
                "recipient": {"name": row["name"], "email": row["email"]},
                "issuedOn": row.get("issued_on") or None,
            },
        )

इसे तब अपनाना सार्थक है जब credential जारी करना किसी बिल्कुल अलग चीज़ से ट्रिगर होता है — एक course-completion webhook, एक CRM स्टेज बदलाव, एक form submission — न कि किसी व्यक्ति द्वारा हाथ से CSV एक्सपोर्ट करने से। हम प्रमाणीकरण और पूरे request/response आकार को API quickstart में कवर करते हैं। इस तरह बनाया गया हर credential dashboard wizard के ज़रिए बनाए गए के समान होता है: वही Open Badge v2.0 assertion, वही सत्यापन URL, वही PDF प्रमाणपत्र।

Dashboard Wizard बनाम API: असल में आप कौन-सा चाहते हैं?

अधिकांश टीमें dashboard wizard से शुरू करती हैं क्योंकि उसे CSV के अलावा कुछ नहीं चाहिए, और API की ओर तभी बढ़ती हैं जब वही बैच तीन-चार बार हाथ से चलाया जा चुका हो और पैटर्न स्पष्ट रूप से automate करने लायक हो।

गोपनीयता: असल में क्या संग्रहीत होता है

नामों और ईमेल की एक CSV व्यक्तिगत डेटा है, और यह जानना सार्थक है कि अपलोड के बाद उसके साथ क्या होता है। प्राप्तकर्ता का ईमेल पता कभी भी credential पर सादे रूप में संग्रहीत नहीं होता — यह Open Badge v2.0 assertion के हिस्से के रूप में प्रत्येक credential के लिए एक अलग salt के साथ hash किया जाता है, स्पेसिफ़िकेशन के hashed प्राप्तकर्ता पहचान प्रारूप का पालन करते हुए। एक सत्यापनकर्ता इसी hash की जाँच करता है, कच्चे पते की नहीं। नाम फ़ील्ड जैसा दर्ज किया गया वैसा ही संग्रहीत होता है, क्योंकि यह प्रमाणपत्र और सत्यापन पेज पर दिखने के लिए है। अगर जारी करने के बाद किसी पंक्ति को सुधारना हो — सबसे आम तौर पर एक गलत वर्तनी वाला नाम — तो आप credentials dashboard से उस अलग credential को संपादित या रद्द कर सकते हैं, बाकी बैच को छुए बिना।

बैच के बाद: प्राप्तकर्ताओं को सूचित करें

badge जारी करना और प्राप्तकर्ता को उसके बारे में बताना दो अलग-अलग चरण हैं। अगर आपकी CSV पहले से आपके अपने सिस्टम के ज़रिए कोई ईमेल ट्रिगर नहीं करती, तो dashboard का bulk-share प्रवाह आपको अभी बनाए गए credential को multi-select करने और उन सबको एक ही बार में एक व्यक्तिगत share ईमेल भेजने देता है — पूरी मार्गदर्शिका के लिए share ईमेल थोक में भेजना देखें, जिसमें यह भी शामिल है कि प्रति-प्राप्तकर्ता वैयक्तिकरण (नाम, badge छवि, सत्यापन लिंक) अपने आप कैसे प्रतिस्थापित होता है।

Bulk Credentials कब सही उपकरण है

थोक जारी करना तब सही निर्णय है जब “बैच” का ढाँचा असल दुनिया से मेल खाता हो: एक समूह जो एक ही दिन पूरा हुआ, एक सम्मेलन जो अभी समाप्त हुआ, एक प्रशिक्षण रोलआउट जो किसी अनुपालन समय-सीमा तक पहुँच रहा हो। अगर इसके बजाय आप अलग-अलग मील के पत्थर हासिल होते ही एकल credential जारी कर रहे हैं — एक अकेली पदोन्नति, एक अकेली परियोजना पूर्णता — तो एकल-credential फ़ॉर्म एक-पंक्ति की CSV बनाने से तेज़ है।

बार-बार होने वाली किसी भी चीज़ के लिए — हर महीने चलने वाला वही course, एक चलता हुआ onboarding pipeline — ऊपर का API रास्ता एक बार सेट करने लायक है। यह “हर समूह के लिए bulk credentials हाथ से चलाओ” को “completion पहले से अपने आप credential जारी कर देते हैं” में बदल देता है, और यही इस वर्कफ़्लो का वह संस्करण है जो अधिकांश प्रोग्राम मालिक दूसरे या तीसरे मैनुअल बैच के बाद असल में चाहते हैं।

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