Näin myönnät Open Badges -merkkejä CSV-tiedostosta alle 5 minuutissa
Vaihe vaiheelta: lataa CSV-tiedosto vastaanottajista, valitse merkkisi ja paina Myönnä. Keskeytä ja jatka kesken erän, yritä epäonnistumisia uudelleen, vie tulokset. Toimii 10 tai 10 000 hengen ryhmille.
Nacho founded Badges Ninja to make issuing verifiable digital credentials as simple as a single API call — Open Badge v2.0 badges and certificates, minted, hosted, and verifiable without standing up your own issuer infrastructure.
Jos olet joskus myöntänyt credentialeja ryhmälle yksi vastaanottaja kerrallaan, tiedät ongelman jo: se ei skaalaudu noin kymmentä henkilöä pidemmälle ennen kuin siitä tulee kokonainen iltapäivä nimien ja sähköpostien kopioimista ja liittämistä. 40 hengen bootcamp-ryhmä, 500 hengen konferenssin osallistujalista tai 5 000 hengen yritysvalmennus tarvitsevat kaikki saman asian — lataa lista, valitse merkki, klikkaa Myönnä ja kävele pois.
Juuri sitä Bulk Credentials osoitteessa https://badges.ninja tekee. Tämä läpikäynti kattaa koko prosessin: CSV-tiedoston valmistelun, erän määrittämisen, sen ajon seuraamisen ja todellisen maailman sotkuisten tilanteiden käsittelyn — vastaanottajarivin, jossa on kirjoitusvirhe, erän joka keskeytyy puolimatkassa, tai ohjelman joka haluaa myöntää samalla tavalla omista järjestelmistään dashboardin sijaan.
Ennen kuin aloitat: Mitä tarvitset
Kaksi asiaa, jotka sinulla luultavasti jo on:
- Merkki — suunniteltu kerran visuaalisessa suunnittelutyökalussa ja käytetty uudelleen jokaiselle erän vastaanottajalle. Jos et ole vielä rakentanut sellaista, katso oppaamme ensimmäisen todennettavan sertifikaatin suunnittelusta.
- CSV-tiedosto vastaanottajista — nimi, sähköposti ja (valinnaisesti) myöntämispäivä. Siinä koko skeema.
Et tarvitse myöntäjätiliä vastaanottajaa kohden, sähköpostipalvelinta tai mitään koodia. Kaikki tässä osiossa tapahtuu dashboardissa.
Vaihe 1: Valmistele CSV-tiedostosi
Vastaanottajalistan muoto on tarkoituksella minimaalinen:
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 — pakollinen. Täyttää vastaanottajakentän assertiossa ja sertifikaatissa.
- email — pakollinen. Tästä tulee vastaanottajan identiteetti Open Badge v2.0 -assertiossa — hashattu credential-kohtaisella suolalla ennen tallennusta, ei koskaan säilytettynä selkokielisenä.
- issued_on — valinnainen. Jätä se tyhjäksi, niin erä käyttää hetkeä jolloin kukin rivi käsitellään; aseta se eksplisiittisesti, jos täytät jälkikäteen ryhmää joka itse asiassa valmistui viime kuussa.
Useimmat ohjelman omistajat vievät tämän suoraan sieltä missä he jo seuraavat suorituksia — Airtable, Google Sheets, kouluttajan luovuttama taulukko tai LMS:n arviointikirjasta vedetty CSV. Mitään erityistä vientityökalua ei tarvita; mikä tahansa CSV noilla kolmella sarakkeella toimii.
Yleisiä CSV-sudenkuoppia (ja miten esikatselu nappaa ne)
Kourallinen ongelmia esiintyy jatkuvasti todellisen maailman vastaanottajalistoissa, yleensä koska CSV koottiin yhdistämällä kaksi tai kolme lähdetaulukkoa:
- Ylimääräiset välilyönnit sähköpostiosoitteiden lopussa — kopiointi PDF-listasta tai Google Forms -viennistä kantaa usein näkymättömän välilyönnin. Se näyttää hyvältä taulukon solussa mutta epäonnistuu sähköpostin vahvistuksessa latauksen yhteydessä.
- Kaksoisrivit — sama vastaanottaja esiintyy kahdesti, koska ryhmälista ja myöhäisilmoittautujien lista yhdistettiin ilman duplikaattien poistoa.
- Epäjohdonmukaiset päivämäärämuodot — yksi sarake muodossa
2026-07-01sekoitettuna muotoon07/01/2026toisesta viennistä. Pysy ISO 8601 -muodossa (YYYY-MM-DD), niin tämä katoaa täysin. - Otsikoiden kirjainkokoerot —
Emailvs.emailvs.E-mail. Jäsennin on suvaitsevainen yleisten muunnelmien suhteen, mutta täysin mukautettu otsikkonimi ei kartoitu automaattisesti.
Mikään näistä ei ole kohtalokas — esikatseluvaihe (alla) nostaa jokaisen esiin ennen kuin mitään myönnetään, joten korjaus on ”muokkaa taulukkoa, lataa uudelleen” eikä ”selvitä kuka 3 000 vastaanottajasta sai rikkinäisen merkin”.
Vaihe 2: Määritä erä
Avaa dashboardista Credentials → Bulk Credentials ja valitse merkki jonka myönnät. Tässä vaiheessa asetat kaiken mikä koskee koko erää: itse merkin, yhteisen myöntämispäivän jos et laita rivikohtaisia päiviä CSV:ään, ja (jos myöntäjäprofiilillasi on sellainen) LinkedIn-organisaation ID:n jonka avulla jokainen vastaanottaja voi lisätä credentialin profiiliinsa yhdellä klikkauksella.

Tämä on hyvä hetki tarkistaa kahdesti, että valitsemasi merkki on lopullinen versio — vastaanottajat näkevät sen kuvan ja kriteerit jotka siihen on liitetty myöntämishetkellä, eivät sitä miksi päivität sen myöhemmin.
Vaihe 3: Lataa ja esikatsele
Pudota CSV-tiedostosi sisään, ja alusta jäsentää sen, näyttää sinulle esikatselutaulukon ja merkitsee kaiken mitä se ei voi käsitellä — puuttuvan sähköpostin, virheellisen päivämäärän, kaksoisrivin. Mitään ei myönnetä ennen kuin vahvistat esikatselun.

Tämä esikatseluvaihe merkitsee enemmän kuin miltä näyttää. Kirjoitusvirhe yhdellä rivillä 2 000 rivin CSV:ssä on helppo ohittaa silmämääräisesti, ja on paljon halvempaa napata se ennen kuin 1 999 oikeaa riviä on jo myönnetty kuin yrittää purkaa se jälkikäteen. Korjaa merkityt rivit taulukossasi, lataa uudelleen, ja esikatselu päivittyy.
Vaihe 4: Aja erä
Paina Myönnä, ja erä alkaa käsitellä. Edistymispalkki seuraa valmiita vs. jäljellä olevia rivejä, ja erä ajetaan palvelinpuolella — sinun ei tarvitse pitää välilehteä auki, eikä läppärin sulkeminen kesken erän hukkaa paikkaasi.
Tuo viimeinen osa kannattaa avata auki, koska se on yksityiskohta jolla on oikeasti merkitystä suurille ryhmille: erän tila elää palvelimella, ei selaimessasi. Jos yhteytesi katkeaa, läppärisi menee lepotilaan, tai suljet vain välilehden koska kokous alkaa, erä jatkaa ajamista (tai jatkuu tismalleen siitä mihin jäi jos keskeytit sen) sen sijaan että alkaisi alusta. 40 hengen bootcamp-ryhmälle tämä on kiva lisä. 5 000 rivin yritysjulkaisulle se on ero sen välillä että ”se vain toimii” ja että ”jonkun täytyy vahtia selaimen välilehteä kaksikymmentä minuuttia”.
Voit myös keskeyttää käynnissä olevan erän tarkoituksella — sanotaan että joku huomauttaa että merkin kriteeriteksti tarvitsee säädön puolivälissä 3 000 rivin ajoa — korjata ongelman ja jatkaa myöntämättä uudelleen jo valmistuneita rivejä.
Vaihe 5: Käsittele epäonnistumiset
Todellisissa vastaanottajalistoissa on huonoja rivejä: kirjoitusvirheen sisältävä sähköpostidomain, nimikenttä joka on itse asiassa tyhjä, kaksoismerkintä kahden viedyn taulukon yhdistämisestä. Kun rivi epäonnistuu, erä ei pysähdy — se jatkaa loppujen käsittelyä ja merkitsee epäonnistumisen tarkistettavaksi jälkikäteen. Saat tulosviennin joka näyttää tarkalleen mitkä rivit onnistuivat ja mitkä eivät, joten voit korjata vain epäonnistuneet rivit ja ajaa pienen jatkoerän sen sijaan että tarkistaisit koko listan uudelleen.
Tällä on merkitystä CSV-vientitavalle joka on jo yleinen credentials-dashboardissa — voit vetää CSV:n siitä mitä oikeasti myönnettiin milloin tahansa, ristiviitata sen lähdelistaasi vasten ja tietää tarkalleen kuka tarvitsee vielä merkin.
API-polku: Sama prosessi, ei dashboardia
Kaikki edellä olettaa että joku istuu dashboardin ääressä klikkaillen ohjatun toiminnon läpi. Jos suorituksesi elävät jo jossakin järjestelmässä — LMS:ssä, CRM:ssä, taulukkoautomaatiossa — voit ajaa saman bulk-credential-prosessin suoraan Awards API:sta.
Minimaalinen vastaanottajakohtainen myöntämiskutsu näyttää tältä:
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"
}'
Tai Pythonilla, käymällä silmukassa läpi rivejä jotka luetaan samasta CSV:stä jonka muuten lataisit käsin:
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,
},
)
Tähän kannattaa tarttua kun credentialin myöntämisen laukaisee jokin aivan muu — kurssin suoritus-webhook, CRM-vaiheen muutos, lomakkeen lähetys — eikä henkilö joka manuaalisesti vie CSV:n. Käsittelemme todennuksen ja koko request/response-rakenteen API-pikaoppaassa. Jokainen näin luotu credential on identtinen dashboardin ohjatulla toiminnolla luodun kanssa: sama Open Badge v2.0 -assertio, sama todennus-URL, sama PDF-sertifikaatti.
Dashboardin ohjattu toiminto vs. API: Kumman oikeasti haluat?
| Dashboard Bulk Credentials | Awards API | |
|---|---|---|
| Paras kun | Kertaluontoinen tai satunnainen erä (ryhmän valmistuminen, konferenssin osallistuminen) | Toistuva laukaisin (jokainen kurssin suoritus, jokainen osto) |
| Käyttöönoton vaiva | Ei mitään — vie CSV, lataa se | Kertaluontoinen integrointityö (webhook tai skripti) |
| Kuka ajaa sen | Ohjelman omistaja, ei koodia | Se joka omistaa laukaisevan järjestelmän |
| Epäonnistumisten käsittely | Esikatselu + rivikohtainen tulosvienti | Pyyntökohtainen HTTP-status, käsitelty omassa uudelleenyrityslogiikassasi |
Useimmat tiimit aloittavat dashboardin ohjatulla toiminnolla koska se ei vaadi muuta kuin CSV:n, ja siirtyvät APIin vasta kun sama erä on ajettu manuaalisesti kolme tai neljä kertaa ja kaava on selvästi automatisoinnin arvoinen.
Yksityisyys: Mitä oikeasti tallennetaan
CSV nimiä ja sähköposteja on henkilötietoa, ja kannattaa tietää mitä sille tapahtuu latauksen jälkeen. Vastaanottajan sähköpostiosoitetta ei koskaan tallenneta selkokielisenä itse credentialiin — se hashataan credential-kohtaisella suolalla osana Open Badge v2.0 -assertiota, noudattaen spesifikaation hashed-vastaanottajaidentiteetin muotoa. Juuri tuota hashia vastaan verifioija tarkistaa, ei raakaa osoitetta. Nimikenttä tallennetaan sellaisena kuin se on syötetty, koska sen on tarkoitus näkyä sertifikaatissa ja todennussivulla. Jos rivi tarvitsee korjausta myöntämisen jälkeen — yleisimmin väärin kirjoitettu nimi — voit muokata tai peruuttaa yksittäisen credentialin credentials-dashboardista koskematta muuhun erään.
Erän jälkeen: Ilmoita vastaanottajille
Merkin myöntäminen ja siitä kertominen vastaanottajalle ovat kaksi eri vaihetta. Jos CSV:si ei jo laukaise sähköpostia oman järjestelmäsi kautta, dashboardin joukkojakoprosessi antaa sinun monivalita juuri luomasi credentialit ja lähettää personoidun jakosähköpostin niille kaikille yhdellä kertaa — katso jakosähköpostien joukkolähetys koko läpikäynnistä, mukaan lukien miten vastaanottajakohtainen personointi (nimi, merkin kuva, todennuslinkki) korvataan automaattisesti.
Milloin Bulk Credentials on oikea työkalu
Joukkomyöntäminen on oikea valinta aina kun ”erä”-kehys sopii todelliseen maailmaan: ryhmä joka valmistui samana päivänä, konferenssi joka juuri päättyi, valmennuksen julkaisu joka osuu compliance-määräaikaan. Jos sen sijaan myönnät kertaluontoisia credentialeja sitä mukaa kun yksittäisiä virstanpylväitä saavutetaan — yksittäinen ylennys, yksittäisen projektin valmistuminen — yksittäisen credentialin lomake on nopeampi kuin yhden rivin CSV:n kokoaminen.
Kaikkeen toistuvaan — samaan kurssiin joka pyörii joka kuukausi, jatkuvaan perehdytysputkeen — yllä oleva API-polku on yhden kerran pystyttämisen arvoinen. Se muuttaa ”aja bulk credentials manuaalisesti joka ryhmälle” muotoon ”suoritukset myöntävät credentialeja jo automaattisesti”, joka on tämän työnkulun versio jonka useimmat ohjelman omistajat oikeasti haluavat toisen tai kolmannen manuaalisen erän jälkeen.
Valmis myöntämään ensimmäisen todennettavan credentialisi? Aloita ilmaiseksi badges.ninjassa — visuaalinen suunnittelutyökalu, julkinen todennussivu, PDF-sertifikaatti, Open Badge v2.0 -tuloste. Luottokorttia ei tarvita.
Miten tämä artikkeli tehtiin
Osa tämän blogin artikkeleista laaditaan tekoälyavustajan avulla, minkä jälkeen Badges Ninja -tiimi tarkistaa, faktantarkistaa ja muokkaa ne ennen julkaisua. Jokainen koodiesimerkki ja hinta tarkistetaan live-tuotteesta. Lue lisää toimituksellisesta ja tekoälyprosessistamme toimitusprosessin sivulla .

Kirjoittajasta
Nacho Coll
Founder & Engineer at Badges Ninja
Nacho founded Badges Ninja to make issuing verifiable digital credentials as simple as a single API call — Open Badge v2.0 badges and certificates, minted, hosted, and verifiable without standing up your own issuer infrastructure. Writes about the Open Badges spec, credential verification, and running a credentialing platform serverless on AWS, from the operator side of the wire.
Lisää käyttäjältä Nacho Coll
- Näin lisäät LinkedIn-palvelun ”Lisää profiiliin” -painikkeen Open Badges -merkkeihisi20.8.2026 · 8min lukuaika
- Open Badges vs. PDF-todistukset: Kumpi sopii ohjelmallesi vuonna 2026?10.8.2026 · 5min lukuaika
- Open Badge v2 vs v3 selitettynä: Kumpaa spesifikaatiota sinun pitäisi käyttää tänään?6.8.2026 · 7min lukuaika


