Moodle's native Open Badges vervangen door Badges Ninja (betere designer, dezelfde API)

Moodle geeft al sinds versie 2.5 native Open Badges uit, en voor veel cursusbeheerders is dat reden genoeg om nooit ergens anders te kijken. Het zit ingebouwd, het is gratis en het levert technisch gezien een credential op die aan de standaarden voldoet. Waarom raken zoveel Moodle-beheerders dan gefrustreerd tegen de tijd dat ze hun vijftigste badge hebben uitgereikt?

Het eerlijke antwoord: het badgesysteem van Moodle is ontworpen om een compliance-vakje af te vinken, niet om een volwaardig credentialing-product te zijn. Het werkt, maar het werkt zoals een functie werkt die achteraf op een LMS is geplakt — functioneel, gedateerd en beperkt door de grenzen van het platform waarin het leeft. Als je ooit hebt geprobeerd om een Moodle-badge er anders uit te laten zien dan een rond clipart-icoontje, of een afgestudeerde hebt horen vragen: “wacht, waar zie ik dit ding nu eigenlijk terug?”, ken je de kloof al.

Dit is geen afbraak van Moodle — het is een uitstekend LMS en de criteria-engine voor badges (cursusafronding, activiteitsafronding, handmatige toekenning, cohortlidmaatschap) is echt goed doordacht om een credential te triggeren. Het probleem zit in alles wat na die trigger komt: de ontwerptools, de ervaring van de ontvanger en de zichtbaarheid van de badge buiten je Moodle-omgeving. Precies daarvoor is badges.ninja gebouwd, en je hoeft de afrondingslogica van Moodle niet op te geven om het te gebruiken — je richt de trigger simpelweg op een andere uitgifte-engine.

Waar de native badges van Moodle tekortschieten

De designer is een op coördinaten gebaseerde beeldcompositor, geen ontwerptool. Met de badge-editor van Moodle kies je een basisafbeelding, plak je er een paar vooraf ingestelde icoon-overlays op en pas je de positie aan met pixeloffsets. Er is geen vormenbibliotheek, geen paletsysteem, geen lettertypekeuze buiten wat al in de iconenset is ingebakken. Als jouw organisatie een merkidentiteit heeft — een logo, een kleurenpalet, een specifieke visuele taal voor je certificeringen — dan kan de editor van Moodle dat niet uitdrukken. De meeste instellingen ontwerpen de badge-afbeelding uiteindelijk in Photoshop of Canva en uploaden een platte PNG, wat het hele idee van een ingebouwde designer teniet doet.

Ontvangers hebben een Moodle-login nodig om hun eigen badges te zien. De toegekende badges van een cursist staan op zijn of haar Moodle-profielpagina. Als iemand de cursus al heeft afgerond en verder is gegaan, de institutionele inloggegevens is vergeten, of de instelling het account inmiddels heeft gedeactiveerd, is de badge voor die persoon in feite verdwenen — ook al is de onderliggende assertion misschien nog steeds op te vragen via Moodle’s backpack-connector of de publieke badgepagina. Er is geen speciale, van huisstijl voorziene, altijd bereikbare plek waar een ontvanger simpelweg met zijn e-mailadres kan inloggen en elke credential kan zien die hij ooit in welke cursus dan ook heeft verdiend.

Delen is een bijzaak. Moodle kan badges doorsturen naar een dienst die compatibel is met Mozilla Backpack en biedt voor elke badge een publieke verificatie-URL, maar er is geen ingebouwde “Toevoegen aan LinkedIn”-flow, geen deelknop met één klik, en geen engagement-analyse over of iemand ooit naar de badge heeft gekeken nadat die is uitgereikt. Voor programma’s die willen dat de badge werkt als mond-tot-mondreclame — bootcamps, aanbieders van permanente educatie, bedrijfstrainingen — is dat een reële gemiste kans.

Bulkbewerkingen zijn omslachtig. Een badge toekennen aan een heel cohort werkt prima als iedereen de triggerende activiteit tegelijk binnen Moodle afrondt. Maar als je badges met terugwerkende kracht moet toekennen aan een eerder cohort, historische afrondingen vanuit een spreadsheet moet importeren, of een badge moet uitreiken voor iets wat volledig buiten het LMS is gebeurd, zit je vast aan het schrijven van SQL tegen de database van Moodle of aan het worstelen met CSV-importtools die niet specifiek voor badges zijn gebouwd.

Het vervangingspatroon: houd de triggers van Moodle, verander de uitgever

Je hoeft niet van Moodle af te stappen om dit op te lossen. Het schoonste patroon is om Moodle te laten doen waar het goed in is — het bijhouden van cursusafronding, activiteitsafronding, cohortlidmaatschap — en het op het moment dat aan een afrondingsvoorwaarde wordt voldaan de Badges Ninja-API te laten aanroepen, in plaats van (of naast) het toekennen van de eigen native badge.

Moodle ondersteunt dit op een paar manieren:

1. Webhook voor cursusafronding / polling via Moodle Web Services (REST). De core_completion-API van Moodle geeft de afrondingsstatus per gebruiker per cursus weer. Een lichte geplande taak (een geplande cron-taak in Moodle, of een externe cron-job die de REST-API van Moodle aanroept) kan pollen op nieuw afgeronde inschrijvingen en voor elke daarvan het awards-endpoint van Badges Ninja aanroepen.

2. Een hook via een lokale plugin. Als je een ontwikkelaar in dienst hebt, kan het eventsysteem van Moodle (\core\event\course_completed) worden geobserveerd door een kleine lokale plugin die op het moment van afronding direct een HTTP-verzoek verstuurt — zonder pollingvertraging.

3. Zapier/Make/n8n als verbindende schakel, als je liever niet in de codebase van Moodle wilt komen — Moodle kan afrondingsgebeurtenissen doorsturen naar een webhook-ontvanger die een no-code-automatiseringstool omzet in een toekenningsaanroep.

Hier is de daadwerkelijke toekenningsaanroep, zodra je de naam en het e-mailadres van een gebruiker hebt die is afgerond:

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_moodle_course_completion",
    "recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
    "issuedOn": "2026-08-31"
  }'

Of in Node, binnen welke geplande taak of webhook-ontvanger je ook draait:

const response = await fetch("https://api.badges.ninja/awards", {
  method: "POST",
  headers: {
    "X-Api-Key": process.env.BADGES_NINJA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    badgeId: "badge_moodle_course_completion",
    recipient: { name: completedUser.fullname, email: completedUser.email },
    issuedOn: Date.now(),
  }),
});
const award = await response.json();

Het e-mailadres van de ontvanger wordt in rust met SHA-256 gehasht, de toekenning krijgt automatisch een unieke verificatie-URL, een QR-code en een A4 PDF-certificaat, en — cruciaal — de ontvanger kan hem claimen via een magic-link-aanmelding op badges.ninja/me, zonder dat een apart Moodle-account nodig is. Zie de volledige request/response-structuur in de awards API-referentie en de authenticatiehandleiding voor hoe API-sleutels end-to-end werken.

Als je het liever in bulk doet — bijvoorbeeld de afrondingen van een heel semester in één keer met terugwerkende kracht verwerken in plaats van realtime events op te zetten — exporteer dan de afrondingen vanuit Moodle als CSV en gebruik de bulktoekenningsflow rechtstreeks, die pauzeren/hervatten ondersteunt bij grote bestanden. Dat wordt uitgebreid behandeld in hoe je Open Badges uitgeeft vanuit een CSV.

De badge zelf ontwerpen

Zodra de technische verbindingen eenmaal staan, kost het daadwerkelijke ontwerp van de badge minuten, geen ticket naar je webteam. De visuele designer geeft je meer dan 80 vormsjablonen, een echt kleurenpaletsysteem, iconenbibliotheken en het uploaden van eigen lettertypen — zodat een badge voor “Gevorderde statistiek — Afgerond” er ook echt uitziet als iets dat bij de huisstijl van jouw instelling hoort, in plaats van een generiek Moodle-prestatie-icoontje.

Elke API-sleutel heeft een beperkte scope en is intrekbaar vanuit hetzelfde dashboard waar je badges en uitgevers beheert, dus het delen van de integratiecredential met een ontwikkelaar (of een automatiseringstool zoals Zapier) betekent niet dat je de login van je hoofdaccount hoeft te delen.

Naast elkaar: ervaring van de ontvanger

Moodle wint nog altijd op één punt: als je enige eis is dat “de badge bestaat, technisch voldoet aan Open Badge v2.0 en zich bevindt binnen het LMS dat de cursist toch al gebruikt”, dan kosten native badges niets extra en vergen ze geen integratiewerk. De afweging speelt op zodra je waarde hecht aan ontwerpkwaliteit, overdraagbaarheid nadat de cursus is afgelopen, of het inzetten van uitgifte als recruitment-/marketingsignaal — en dat geldt uiteindelijk voor de meeste instellingen.

Voor een breder overzicht van hoe andere Open Badges-platformen zich verhouden op prijs en functies, zie de vergelijking van de goedkoopste Open Badges-platformen. En als jouw instelling Open Badge v2.0 afweegt tegen de nieuwere specificatie voor verifieerbare credentials, behandelt Open Badge v2 versus v3 uitgelegd welke je vandaag daadwerkelijk zou moeten gebruiken.

Klaar om je eerste verifieerbare credential uit te geven? Start gratis op badges.ninja — visuele designer, publieke verificatiepagina, PDF-certificaat, Open Badge v2.0-output. Geen creditcard vereist.