Reemplaza las Open Badges nativas de Moodle con Badges Ninja (Mejor Diseñador, Misma API)
Moodle incluye Open Badges nativas, pero el diseñador es limitado y la experiencia del destinatario queda encerrada dentro de Moodle. Emite credenciales de Badges Ninja a partir de las finalizaciones de Moodle en su lugar.
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.
Moodle emite Open Badges de forma nativa desde la versión 2.5, y para muchos administradores de cursos eso ya es motivo suficiente para no buscar en otro lado. Viene integrado, es gratis y técnicamente produce una credencial compatible con los estándares. Entonces, ¿por qué tantos administradores de Moodle terminan frustrados cuando llegan a su quincuagésima insignia?
La respuesta honesta: el sistema de insignias de Moodle fue diseñado para cumplir con un requisito de compliance, no para ser un producto de credenciales. Funciona, pero funciona como funciona una característica atornillada a un LMS: funcional, anticuada y limitada por las restricciones de la plataforma en la que vive. Si alguna vez intentaste hacer que una insignia de Moodle se viera como algo distinto a un icono circular de clip-art, o viste a un graduado preguntar “espera, ¿dónde veo esto exactamente otra vez?”, ya conoces la brecha.
Esto no es un ataque a Moodle — es un LMS excelente y su motor de criterios de insignias (finalización de curso, finalización de actividad, otorgamiento manual, membresía de cohorte) está genuinamente bien pensado para disparar una credencial. El problema es todo lo que ocurre después del disparador: las herramientas de diseño, la experiencia del destinatario y la visibilidad de la insignia fuera de tu instancia de Moodle. Eso es exactamente para lo que está construido badges.ninja, y no tienes que abandonar la lógica de finalización de Moodle para usarlo — solo apuntas el disparador hacia un motor de emisión diferente.
Dónde se quedan cortas las insignias nativas de Moodle
El diseñador es un compositor de imágenes basado en coordenadas, no una herramienta de diseño. El editor de insignias de Moodle te permite elegir una imagen base, agregar algunas superposiciones de iconos preestablecidos y ajustar la posición con desplazamientos en píxeles. No hay biblioteca de formas, no hay sistema de paletas, no hay opciones de tipografía más allá de lo que viene incorporado en el conjunto de iconos. Si tu organización tiene una marca — un logo, una paleta de colores, un lenguaje visual específico para tus certificaciones — el editor de Moodle no puede expresarlo. La mayoría de las instituciones terminan diseñando el arte de la insignia en Photoshop o Canva y subiendo un PNG plano, lo que anula el propósito de tener un diseñador integrado.
Los destinatarios necesitan iniciar sesión en Moodle para ver sus propias insignias. Las insignias otorgadas a un estudiante viven dentro de su página de perfil de Moodle. Si ya terminó el curso, olvidó sus credenciales institucionales, o la institución desactivó su cuenta desde entonces, la insignia efectivamente desaparece de su lado — aunque la aserción subyacente pueda seguir resolviéndose en el conector de backpack de Moodle o en la página pública de la insignia. No existe un lugar dedicado, con marca propia y siempre accesible donde un destinatario pueda iniciar sesión solo con su correo electrónico y ver cada credencial que haya obtenido en todos sus cursos.
Compartir es una idea de último momento. Moodle puede enviar insignias a un servicio compatible con Mozilla Backpack, y expone una URL de verificación pública para cada insignia, pero no hay un flujo integrado de “Agregar a LinkedIn”, ni un botón de compartir de un clic, ni análisis de interacción sobre si alguien alguna vez miró la insignia después de emitida. Para programas que quieren que la insignia funcione como marketing de boca en boca — bootcamps, proveedores de educación continua, capacitación corporativa — eso es un costo de oportunidad real.
Las operaciones masivas son torpes. Otorgar una insignia a toda una cohorte funciona si todos completan la actividad disparadora dentro de Moodle al mismo tiempo. Pero si necesitas emitir retroactivamente insignias para una cohorte pasada, importar finalizaciones históricas desde una hoja de cálculo, o emitir una insignia por algo que ocurrió completamente fuera del LMS, terminas escribiendo SQL contra la base de datos de Moodle o peleando con herramientas de importación de CSV que no fueron diseñadas específicamente para insignias.
El patrón de reemplazo: conserva los disparadores de Moodle, cambia el emisor
No necesitas migrar fuera de Moodle para arreglar esto. El patrón más limpio es dejar que Moodle siga haciendo lo que hace bien — rastrear la finalización de cursos, la finalización de actividades, la membresía de cohortes — y hacer que llame a la API de Badges Ninja en el momento en que se dispara una condición de finalización, en lugar de (o además de) otorgar su insignia nativa.
Moodle soporta esto de varias maneras:
-
Webhook de finalización de curso / sondeo de Moodle Web Services (REST). La API core_completion de Moodle expone el estado de finalización por usuario y por curso. Una tarea programada ligera (una tarea cron programada de Moodle, o un job cron externo que consulta la API REST de Moodle) puede sondear por inscripciones recién completadas y, para cada una, llamar al endpoint de otorgamiento de Badges Ninja.
-
Un hook de plugin local. Si tienes un desarrollador en el equipo, el sistema de eventos de Moodle (
\core\event\course_completed) puede ser observado por un pequeño plugin local que dispara una solicitud HTTP en el instante en que ocurre la finalización — sin demora de sondeo. -
Zapier/Make/n8n como pegamento, si prefieres evitar tocar el código de Moodle — Moodle puede enviar eventos de finalización a un receptor de webhook que una herramienta de automatización sin código convierte en una llamada de otorgamiento.
Aquí está la llamada real de otorgamiento, una vez que tienes el nombre y correo de un usuario que completó:
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"
}'
O en Node, dentro de la tarea programada o el receptor de webhook que estés ejecutando:
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();
El correo del destinatario se guarda con hash SHA-256 en reposo, el otorgamiento recibe automáticamente una URL de verificación única, un código QR y un certificado PDF A4, y — algo crítico — el destinatario puede reclamarlo mediante un inicio de sesión con enlace mágico en badges.ninja/me, sin necesidad de una cuenta de Moodle separada. Consulta la forma completa de la solicitud/respuesta en la referencia de la API de awards y la guía de autenticación para entender cómo funcionan las claves de API de principio a fin.
Si prefieres hacerlo en lote — digamos, emitir retroactivamente las finalizaciones de todo un semestre en una sola pasada en lugar de configurar eventos en tiempo real — exporta las finalizaciones de Moodle como CSV y usa el flujo de otorgamiento masivo directamente, que soporta pausa/reanudación para archivos grandes. Eso se cubre en detalle en cómo emitir Open Badges desde un CSV.
Diseñando la insignia en sí
Una vez que la infraestructura está en su lugar, el diseño real de la insignia toma minutos, no un ticket para tu equipo web. El diseñador visual te da más de 80 plantillas de formas, un sistema real de paletas de color, bibliotecas de iconos y carga de fuentes personalizadas — para que una insignia de “Estadística Avanzada — Completado” realmente parezca pertenecer a la marca de tu institución en lugar de a un icono genérico de logro de Moodle.

Cada clave de API tiene un alcance definido y es revocable desde el mismo panel donde gestionas insignias y emisores, así que entregar la credencial de integración a un desarrollador (o a una herramienta de automatización como Zapier) no significa compartir el inicio de sesión de tu cuenta principal.

Comparación directa: experiencia del destinatario
| Insignia nativa de Moodle | Badges Ninja | |
|---|---|---|
| Dónde la ven los destinatarios | Dentro del perfil de Moodle, requiere inicio de sesión | badges.ninja/me, enlace mágico, sin contraseña |
| Verificación pública | Sí, URL pública por insignia | Sí, endpoint JSON-LD de Open Badge v2.0 |
| Herramientas de diseño | Icono fijo + desplazamientos de posición | 80+ plantillas, paletas, fuentes/iconos personalizados |
| Compartir en LinkedIn | Manual, sin botón integrado | Flujo nativo de Agregar a Perfil de LinkedIn |
| Emisión histórica masiva | SQL o solución manual con CSV | Otorgamiento masivo integrado con pausa/reanudación |
| Visibilidad de interacción | Ninguna | Estadísticas de vistas/comparticiones por otorgamiento |
| Acceso después de dejar la institución | Ligado al estado de la cuenta de Moodle | Persistente, propiedad del destinatario |
Moodle todavía gana en una cosa: si tu único requisito es “la insignia existe, es técnicamente compatible con Open Badge v2.0 y vive dentro del LMS que el estudiante ya usa”, las insignias nativas no cuestan nada extra y no requieren trabajo de integración. La desventaja aparece en el momento en que te importa la calidad del diseño, la portabilidad después de que termina el curso, o convertir la emisión en una señal de reclutamiento/marketing — que es la mayoría de las instituciones, eventualmente.
Para una mirada más amplia de cómo se comparan otras plataformas de Open Badges en precio y funciones, consulta la comparación de la plataforma de Open Badges más económica. Y si tu institución está evaluando Open Badge v2.0 frente a la especificación más nueva de credenciales verificables, Open Badge v2 vs v3 explicado cubre cuál conviene lanzar hoy en realidad.
¿Listo para emitir tu primera credencial verificable? Comienza gratis en badges.ninja — diseñador visual, página de verificación pública, certificado PDF, salida en Open Badge v2.0. No se requiere tarjeta de crédito.
Cómo se hizo este artículo
Algunos artículos de este blog se redactan con la ayuda de un asistente de IA y luego son revisados, verificados y editados por el equipo de Badges Ninja antes de publicarse. Cada ejemplo de código y precio se verifica con el producto en vivo. Más información sobre nuestro proceso editorial y de IA en nuestra página de proceso editorial .

Sobre el autor
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.
Más de Nacho Coll
- El mejor software de certificados digitales en 2026 (gratis y de pago comparados)10 sept 2026 · 11min de lectura
- Diseña tu primer certificado digital verificable (sin necesitar un diseñador)3 sept 2026 · 11min de lectura
- Automatiza las Open Badges con Zapier, Make y n8n (recetas sin código)27 ago 2026 · 11min de lectura
