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

Activa la emisión de insignias desde una finalización en Typeform, una compra en Stripe o una etiqueta en Mailchimp: tres recetas sin código que funcionan y que toman menos de 10 minutos cada una.

Nacho Coll Por Actualizado 11 min de lectura
Activa la emisión de insignias desde una finalización en Typeform, una compra en Stripe o una etiqueta en Mailchimp: tres recetas sin código que funcionan y que toman menos de 10 minutos cada una.

Si llevas un programa de formación, un curso de pago o una lista de correo con niveles, el momento en que alguien termina, compra o califica 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 construir un receptor de webhook personalizado 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.

Primero crea la clave de API

API Keys — estado vacío

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, vas a querer revocar esa clave sin romper otras tres integraciones que la comparten.

Crear clave — formulario de nombre

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 cohorte)

Caso de uso: una cohorte termina un curso y completa un formulario corto de «Ya terminé esto» (o envías un formulario como paso final de una ruta de autoaprendizaje).

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"
}

Eso es 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, agrega 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 membresía donde la insignia es 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 monto del cobro es igual al precio exacto del producto que otorga la credencial; esto importa si tu cuenta de Stripe maneja 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, agrega un paso de Storage by Zapier que verifique si ya procesaste ese ID de cobro antes de llamar a /awards.

Receta 3: etiqueta de Mailchimp → Badges Ninja

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

En Zapier:

  1. Disparador: Mailchimp — New Tag Added to Subscriber, filtrado a la etiqueta específica (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 popular en programas de reconocimiento (incentivos de ventas, hitos de comunidad, asistencia a eventos) donde alguien del equipo ya tiene el hábito de etiquetar contactos, y simplemente quieres que la insignia surja de ese hábito sin esfuerzo adicional.

Cómo manejar 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 de una integración real:

  • Revisa el código de respuesta. Un 200 significa que el award se creó; un 4xx normalmente indica un badgeId incorrecto o un correo mal formado — eso es un error de configuración en el Zap, no algo para 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 fallas transitorias, pero configura una alerta por correo o Slack para fallas repetidas, para que un Zap roto silenciosamente no signifique tres meses de insignias faltantes.
  • Make: los scenarios admiten una ruta nativa de Error Handler — agrega una directiva Resume o Rollback al módulo HTTP, y dirige las fallas persistentes a un módulo de notificación en lugar de simplemente descartarlas.
  • n8n: como es autoalojado o en la nube con control más granular, envuelve el nodo HTTP Request en un workflow de Error Trigger, y considera escribir los payloads fallidos en un almacén de respaldo liviano (Airtable, Google Sheets) que puedas reprocesar manualmente.

En los tres casos, evita caer en la trampa de «se ejecutó en verde, así que funcionó». Una respuesta que parece un 200 proveniente de un paso de webhook mal configurado (URL equivocada, header faltante) igual puede fallar del lado de Badges Ninja. Revisa manualmente la lista de awards del dashboard cada semana durante el primer mes de cualquier automatización nueva.

El equivalente en Make.com

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

  1. Trigger module — módulo watch 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 crudo con variables mapeadas desde el disparador.
  3. Filter opcional entre módulos para la verificación del monto 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 esto autoalojado, o si ya estás automatizando otras partes de tu stack ahí:

  1. Trigger node — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (todos son nodos 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 nodo), body JSON construido a partir de una expresión que referencia la salida del nodo disparador.
  3. IF node (opcional) — la misma validación de finalización/monto de arriba, ubicada antes del nodo HTTP Request.

Como las credentials de n8n están encriptadas y son reutilizables entre workflows, esta es la opción más limpia si planeas tener 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 el instinto 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, 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 agrega una capa de abstracción que no necesitas: seguirías llenando 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 hagas, el enfoque de HTTP directo resulta en realidad menos frágil — no hay ningún ciclo de aprobación de app store entre un cambio en la API de Badges Ninja y que tu automatización vuelva a funcionar.

Prueba antes de activarlo en producción

Cada una de las plataformas anteriores te da una forma de ejecutar una sola prueba sin esperar 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. Verifica que el award aparezca en tu dashboard 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 nodo HTTP Request con datos de prueba, lo que te permite ver la solicitud y la respuesta directamente en el editor.

Hay dos cosas que vale la pena revisar en esa primera prueba: que el badgeId que escribiste directamente realmente corresponda a la insignia que crees (un ID desactualizado por un Zap duplicado es un error común), y que el campo de correo del destinatario esté tomando una dirección real y no un placeholder como {{email}} que quedó sin resolver por un error de tipeo en el mapeo. Ambos errores son invisibles en el indicador de «éxito» de la plataforma de automatización — la llamada HTTP igual devuelve 200 en cualquier caso — así que la única verificación confiable es abrir el award en tu dashboard 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 webhooks cuando hay timeout, Typeform puede enviar un formulario dos veces con una conexión lenta, las automatizaciones de Mailchimp pueden volver a dispararse si una etiqueta se quita y se vuelve a agregar. Si la emisión de tu insignia no es idempotente, eso se traduce en destinatarios que reciben la misma credencial dos veces, lo cual se ve descuidado 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, agrega una acción de Search (el «Find Award» de Zapier mediante una solicitud GET, o el equivalente GET de HTTP en Make/n8n) contra tus propios registros de awards — un Google Sheet o un log de Airtable livianos, en el que el mismo Zap escriba justo después de un award exitoso, funciona 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 emitir de nuevo. Esto se agrega en cinco minutos, y es 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 no es suficiente

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 — una cohorte que se gradúa, una lista de asistentes a una conferencia, una renovación masiva de créditos de educació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 del lote, y sobrevive a una pestaña del navegador cerrada, algo que los bucles de webhooks sin código no manejan bien a gran volumen.


¿Listo para emitir tu primera credencial verificable? Comienza 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.

Nacho Coll

Sobre el autor

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.

Volver al Blog

Artículos relacionados