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 Coll Kirjoittanut Päivitetty 7 min lukuaika
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.

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:

  1. 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.
  2. 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-01 sekoitettuna muotoon 07/01/2026 toisesta viennistä. Pysy ISO 8601 -muodossa (YYYY-MM-DD), niin tämä katoaa täysin.
  • Otsikoiden kirjainkokoerotEmail vs. email vs. 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.

Bulk Credentials — vaihe 1, määritys

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.

Bulk Credentials — vaihe 2, lataus

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 CredentialsAwards API
Paras kunKertaluontoinen tai satunnainen erä (ryhmän valmistuminen, konferenssin osallistuminen)Toistuva laukaisin (jokainen kurssin suoritus, jokainen osto)
Käyttöönoton vaivaEi mitään — vie CSV, lataa seKertaluontoinen integrointityö (webhook tai skripti)
Kuka ajaa senOhjelman omistaja, ei koodiaSe joka omistaa laukaisevan järjestelmän
Epäonnistumisten käsittelyEsikatselu + rivikohtainen tulosvientiPyyntö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.

Nacho Coll

Kirjoittajasta

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.

Takaisin Blogiin

Aiheeseen liittyvät artikkelit