Automatiza los Open Badges con Zapier, Make y n8n (recetas sin código)

Si llevas un programa de formación, un curso de pago o una lista de correo electrónico con niveles, el momento en que alguien termina, compra o cumple los requisitos normalmente ya queda registrado en algún sitio: una respuesta de formulario, un cobro en Stripe, una etiqueta en Mailchimp. La insignia debería emitirse automáticamente a partir de ese evento. Casi nunca ocurre así, porque «emitir una credencial» no es una acción nativa en la mayoría de las herramientas, y montar un receptor de webhook a medida para una automatización puntual es excesivo.

Para esto están exactamente Zapier, Make y n8n. Los tres pueden llamar directamente a la API de Badges Ninja: sin plugins, sin servidor intermedio, sin despliegue de código. A continuación tienes tres recetas que puedes copiar hoy mismo, además del manejo de claves de API y del comportamiento de reintentos ante errores que necesitas para que las insignias no dejen de emitirse en silencio.

Lo que vas a conectar

Cada receta sigue la misma estructura: disparador → (opcional) búsqueda del destinatario → HTTP POST a /awards. El endpoint /awards es el que realmente emite una insignia a un destinatario: le indicas un badgeId existente y crea un award único y verificable, con su propia URL de verificación, código QR y certificado en PDF. Consulta la guía rápida de la API si todavía no has creado una insignia; necesitarás su ID antes de que cualquiera de estas automatizaciones pueda funcionar.

La autenticación es la misma en las tres plataformas: un header X-Api-Key con una clave generada desde tu panel. Las plataformas de automatización no manejan bien los flujos OAuth para APIs REST arbitrarias, así que las claves de API son la opción correcta aquí: de larga duración, limitadas a tu cuenta y revocables con un clic si algún Zap falla.

Crea primero la clave de API

Desde tu panel, abre Settings → API Keys, haz clic en Create Key y dale un nombre que describa su función: zapier-course-completions, no key1. Ese nombre importa más de lo que parece: si dentro de seis meses una automatización empieza a fallar, querrás revocar esa clave sin romper otras tres integraciones que la comparten.

La clave se muestra una sola vez, completa, justo después de crearla. Cópiala de inmediato en el almacén seguro de credenciales de tu plataforma de automatización (la «Connection» de Zapier, la «Connection» de Make, o una credential de n8n), nunca en un campo de texto plano dentro del propio Zap, scenario o workflow.

Receta 1: Typeform → Badges Ninja (formulario de finalización de grupo)

Caso de uso: un grupo termina un curso y rellena un formulario corto de «Ya lo he terminado» (o envías un formulario como último paso de un itinerario a tu propio ritmo).

En Zapier:

1. Disparador: Typeform — New Entry, limitado a tu formulario de finalización.
2. Acción: Webhooks by Zapier — POST.
3. URL: https://api.badges.ninja/awards
4. Headers: X-Api-Key: bws_<tu clave>, Content-Type: application/json
5. Data (mapeando los campos de Typeform):

{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

Con eso basta para todo el Zap. No hace falta un paso de filtro si el formulario solo se dispara en finalizaciones reales; si es un formulario de contacto general, añade un paso de Filter by Zapier que revise un campo oculto o un valor de respuesta antes de que se dispare el webhook, para no emitir insignias a partir de spam o envíos de prueba.

Receta 2: Stripe → Badges Ninja (compra = credencial)

Caso de uso: un examen de certificación de pago, un nivel premium de un curso o un plan de socios en el que la insignia forma parte de lo que la gente está comprando.

En Zapier:

1. Disparador: Stripe — New Charge (o New Invoice Payment Succeeded para suscripciones).
2. Filtro: el importe del cobro coincide exactamente con el precio del producto que otorga la credencial; esto importa si tu cuenta de Stripe gestiona varios productos a través de un mismo webhook.
3. Acción: Webhooks by Zapier — POST a https://api.badges.ninja/awards, con los mismos headers de arriba.
4. Data: mapea charge.billing_details.email y charge.billing_details.name a recipient.email / recipient.name.

Lo bueno de vincular la emisión a un evento de pago es que resulta casi naturalmente idempotente. Los ID de cobro de Stripe son únicos, así que si te preocupa que un Zap se vuelva a disparar por un webhook reintentado, añade un paso de Storage by Zapier que compruebe si ya has procesado ese ID de cobro antes de llamar a /awards.

Receta 3: etiqueta de Mailchimp → Badges Ninja

Caso de uso: etiquetas a los suscriptores manualmente (o mediante otra automatización) cuando alcanzan un hito —asistieron a un webinar, terminaron una secuencia de correos, recomendaron a tres personas— y quieres que esa etiqueta dispare una insignia sin tener que tocar la API tú mismo.

En Zapier:

1. Disparador: Mailchimp — New Tag Added to Subscriber, filtrado a la etiqueta concreta (por ejemplo, webinar-attended).
2. Acción: Webhooks by Zapier — POST a https://api.badges.ninja/awards.
3. Data: mapea subscriber.email_address y subscriber.merge_fields.FNAME + LNAME a los campos del destinatario.

Este patrón es habitual en programas de reconocimiento —incentivos de ventas, hitos de comunidad, asistencia a eventos— en los que alguien del equipo ya tiene la costumbre de etiquetar contactos, y solo quieres que la insignia surja de esa costumbre sin esfuerzo añadido.

Gestión de errores y reintentos

Las plataformas de automatización no son transaccionales respecto a los datos de tus insignias, así que aplica la misma disciplina que exigirías a una integración de verdad:

• Comprueba el código de respuesta. Un 200 significa que el award se ha creado; un 4xx normalmente indica un badgeId incorrecto o un correo mal formado —eso es un fallo de configuración en el Zap, no algo que reintentar a ciegas—. Un 5xx sí es seguro reintentarlo.
• Zapier: las ejecuciones de Zap fallidas aparecen en Zap History con la solicitud y la respuesta completas. Activa Auto-Replay para fallos transitorios, pero configura una alerta por correo o Slack para fallos repetidos, de modo que un Zap roto en silencio no se traduzca en tres meses de insignias sin emitir.
• Make: los scenarios cuentan con una ruta nativa de Error Handler —añade una directiva Resume o Rollback al módulo HTTP, y dirige los fallos persistentes a un módulo de notificación en lugar de descartarlos sin más.
• n8n: como es autoalojado o en la nube con un control más granular, envuelve el node HTTP Request en un workflow de Error Trigger, y plantéate guardar los payloads fallidos en un almacén de respaldo ligero (Airtable, Google Sheets) que puedas reprocesar a mano.

En los tres casos, evita caer en la trampa de «se ha ejecutado en verde, así que ha funcionado». Una respuesta con pinta de 200 procedente de un paso de webhook mal configurado (URL equivocada, header ausente) puede seguir fallando por el lado de Badges Ninja. Comprueba manualmente la lista de awards del panel cada semana durante el primer mes de cualquier automatización nueva.

El equivalente en Make.com

El creador visual de scenarios de Make se corresponde casi directamente con los pasos de Zapier de arriba:

1. Trigger module — módulo de observación de Typeform / Stripe / Mailchimp, igual que el disparador de Zapier.
2. HTTP → Make a Request module — Method POST, URL https://api.badges.ninja/awards, headers configurados en la tabla Headers (X-Api-Key, Content-Type: application/json), body como JSON en bruto con variables mapeadas desde el disparador.
3. Filter opcional entre módulos para la comprobación del importe de Stripe o la validación de «finalización real» en Typeform.

La ventaja de Make aquí es la visibilidad: el editor de scenarios te muestra el payload JSON real en cada paso antes de activarlo, lo que hace que depurar un mapeo de campo incorrecto sea mucho más rápido que la vista de prueba paso a paso, más lineal, de Zapier.

El equivalente en n8n

n8n es la mejor opción si quieres tenerlo autoalojado, o si ya estás automatizando otras partes de tu stack ahí:

1. Trigger node — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (todos son nodes integrados).
2. HTTP Request node — Method POST, URL https://api.badges.ninja/awards, autenticación configurada como Header Auth con tu X-Api-Key guardada como una credential de n8n (no escrita directamente en el node), body JSON construido a partir de una expresión que hace referencia a la salida del node disparador.
3. IF node (opcional) — la misma validación de finalización/importe de arriba, colocada antes del node HTTP Request.

Como las credentials de n8n están cifradas y se pueden reutilizar entre workflows, esta es la opción más limpia si tienes pensado montar más de una automatización de Badges Ninja: configura la credential una vez y reutilízala en cada workflow que necesite emitir insignias.

Por qué usar un paso de webhook genérico en lugar de una app nativa

Zapier, Make y n8n tienen sus propios marketplaces de apps, y lo primero que apetece es buscar una app de «Badges Ninja» antes de recurrir a un módulo genérico de HTTP/webhook. Sáltate esa búsqueda: para una API REST tan pequeña como esta (crear un emisor, crear una insignia, crear un award, y listo), un paso de webhook genérico te deja funcionando en diez minutos, sin depender de que un mantenedor externo de la app se mantenga al día con los cambios de la API. Una app dedicada añade una capa de abstracción que no necesitas: seguirías rellenando los mismos campos badgeId, recipient.email y recipient.name, solo que a través de un formulario en lugar de un body JSON. La referencia de la API es lo bastante corta como para leerla en cinco minutos, y una vez que lo hayas hecho, el enfoque de HTTP directo resulta, de hecho, menos frágil: no hay ningún ciclo de aprobación de tienda de apps entre un cambio en la API de Badges Ninja y que tu automatización vuelva a funcionar.

Prueba antes de ponerlo en producción

Todas las plataformas anteriores te dan una forma de ejecutar una única prueba sin esperar a un evento disparador real:

• Zapier — usa «Test» en el paso del disparador para traer un registro de muestra, y luego «Test» en la acción del webhook para disparar exactamente una solicitud real. Comprueba que el award aparece en tu panel antes de activar el Zap.
• Make — ejecuta el scenario manualmente una vez (botón «Run once») con un bundle de muestra, e inspecciona la burbuja de salida del módulo HTTP para ver el body real de la respuesta.
• n8n — usa «Execute Node» en el node HTTP Request con datos de prueba, lo que te permite ver la solicitud y la respuesta directamente en el editor.

Hay dos cosas que merece la pena comprobar en esa primera prueba: que el badgeId que has fijado corresponde de verdad a la insignia que crees (un ID desactualizado por un Zap duplicado es un error habitual), y que el campo de correo del destinatario está tomando una dirección real y no un placeholder como {{email}} que se ha quedado sin resolver por un error de mapeo. Ambos fallos son invisibles en el indicador de «éxito» de la plataforma de automatización —la llamada HTTP sigue devolviendo 200 en cualquier caso—, así que la única comprobación fiable es abrir el award en tu panel y confirmar que el destinatario es quien esperas.

Cómo evitar insignias duplicadas

En condiciones reales, cualquiera de los disparadores anteriores puede activarse más de una vez para el mismo evento: Stripe reintenta los webhooks cuando hay un timeout, Typeform puede enviar el formulario dos veces con una conexión lenta, las automatizaciones de Mailchimp pueden volver a dispararse si se quita y se vuelve a añadir una etiqueta. Si la emisión de tu insignia no es idempotente, eso se traduce en destinatarios que reciben la misma credencial dos veces, lo cual queda poco cuidado y genera correos de soporte.

La protección más limpia es un paso de búsqueda antes de crear: antes del POST a /awards, añade una acción de Search (el «Find Award» de Zapier mediante una solicitud GET, o el GET de HTTP equivalente en Make/n8n) contra tus propios registros de awards —una hoja de Google Sheets o un registro de Airtable sencillos, en los que el propio Zap escribe justo después de un award correcto, funcionan bien para esto si no quieres consultar la API—. Si ya existe un registro para esa combinación de destinatario e insignia, deriva a un no-op en lugar de volver a emitir. Esto se añade en cinco minutos, y marca la diferencia entre una automatización en la que confías sin supervisión y una que tienes que estar vigilando.

Cuando el no-code se queda corto

Estas recetas cubren bien los disparadores de un solo evento. Cuando estés emitiendo cientos de insignias a partir de una sola exportación CSV —un grupo que se gradúa, una lista de asistentes a una conferencia, una renovación masiva de créditos de formación continua— deja de lado la plataforma de automatización y usa directamente la carga masiva de insignias: se pausa y se reanuda a mitad de lote, y sobrevive a que cierres una pestaña del navegador, algo que los bucles de webhooks sin código no gestionan bien a gran volumen.

---

¿Listo para emitir tu primera credencial verificable? Empieza gratis en badges.ninja — diseñador visual, página pública de verificación, certificado en PDF, salida en Open Badge v2.0. No se requiere tarjeta de crédito.