Automatiser les Open Badges avec Zapier, Make et n8n (recettes no-code)

Si vous gérez un programme de formation, un cours payant ou une liste d’e-mails segmentée par niveaux, le moment où quelqu’un termine, achète ou remplit une condition est en général déjà suivi quelque part : une réponse à un formulaire, un paiement Stripe, un tag Mailchimp. Le badge devrait suivre automatiquement cet événement. Ce n’est presque jamais le cas, parce qu’« émettre une créance » n’est une action native dans quasiment aucun outil, et qu’écrire un récepteur de webhook sur mesure pour une automatisation ponctuelle relève du surdimensionnement.

C’est exactement le rôle de Zapier, Make et n8n. Les trois peuvent appeler directement l’API Badges Ninja : pas de plugin, pas de serveur intermédiaire, aucun déploiement de code. Voici trois recettes opérationnelles que vous pouvez copier dès aujourd’hui, ainsi que la gestion des clés API et le comportement de nouvelle tentative en cas d’erreur à bien maîtriser pour que les badges n’échouent jamais silencieusement à l’émission.

Ce que vous allez relier

Chaque recette suit la même structure : déclencheur → (optionnel) recherche du destinataire → requête HTTP POST vers /awards. Le endpoint /awards est celui qui émet réellement un badge à un destinataire : vous lui indiquez un badgeId existant et il crée une remise unique et vérifiable, avec sa propre URL de vérification, son QR code et son certificat PDF. Consultez le guide de démarrage rapide de l’API si vous n’avez pas encore créé de badge ; vous aurez besoin de son identifiant avant de pouvoir exécuter l’une de ces automatisations.

L’authentification est identique sur les trois plateformes : un en-tête X-Api-Key contenant une clé générée depuis votre tableau de bord. Les plateformes d’automatisation gèrent assez mal les flux OAuth pour des API REST arbitraires, ce qui fait des clés API le bon choix ici : elles sont durables, associées à votre compte, et révocables en un clic si un Zap venait à mal se comporter.

Créez d’abord la clé API

Depuis votre tableau de bord, ouvrez Paramètres → Clés API, cliquez sur Créer une clé, et donnez-lui un nom correspondant à son rôle — zapier-course-completions, pas key1. Ce nommage compte plus qu’il n’y paraît : si une automatisation dysfonctionne dans six mois, vous voudrez révoquer cette clé précise sans casser trois autres intégrations qui la partagent.

La clé n’est affichée en entier qu’une seule fois, immédiatement après sa création. Copiez-la sans attendre dans le coffre à identifiants sécurisé de votre plateforme d’automatisation — la « Connection » de Zapier, la « Connection » de Make, ou un identifiant n8n — jamais dans un champ en texte brut à l’intérieur du Zap, du scénario ou du workflow lui-même.

Recette 1 : Typeform → Badges Ninja (formulaire de fin de cohorte)

Cas d’usage : une cohorte termine un cours et remplit un court formulaire « J’ai terminé » (ou vous envoyez un formulaire comme dernière étape d’un parcours en autonomie).

Dans Zapier :

1. Déclencheur : Typeform — New Entry, limité à votre formulaire de fin de cours.
2. Action : Webhooks by Zapier — POST.
3. URL : https://api.badges.ninja/awards
4. En-têtes : X-Api-Key: bws_<votre clé>, Content-Type: application/json
5. Données (mappées depuis les champs Typeform) :

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

C’est tout le Zap. Aucune étape de filtre n’est nécessaire si le formulaire ne se déclenche que sur de véritables fins de cours — s’il s’agit d’un formulaire de contact généraliste, ajoutez une étape Filter by Zapier vérifiant un champ caché ou une valeur de réponse avant que le webhook ne parte, pour ne pas émettre de badges à partir de spam ou de soumissions de test.

Recette 2 : Stripe → Badges Ninja (achat = créance)

Cas d’usage : un examen de certification payant, un palier de cours premium, ou un plan d’adhésion où le badge fait partie de ce que les gens achètent.

Dans Zapier :

1. Déclencheur : Stripe — New Charge (ou New Invoice Payment Succeeded pour les abonnements).
2. Filtre : le montant du paiement doit correspondre exactement au prix du produit donnant droit au badge — important si votre compte Stripe gère plusieurs produits via un même webhook.
3. Action : Webhooks by Zapier — POST vers https://api.badges.ninja/awards, avec les mêmes en-têtes que ci-dessus.
4. Données : mappez charge.billing_details.email et charge.billing_details.name vers recipient.email / recipient.name.

Ce qui est appréciable en liant l’émission à un événement de paiement, c’est que cela s’approche naturellement de l’idempotence. Les identifiants de paiement Stripe étant uniques, si vous craignez qu’un Zap ne se redéclenche sur un webhook renvoyé, ajoutez une étape Storage by Zapier qui vérifie si vous avez déjà traité cet identifiant de paiement avant d’appeler /awards.

Recette 3 : Tag Mailchimp → Badges Ninja

Cas d’usage : vous taguez manuellement des abonnés (ou via une autre automatisation) lorsqu’ils atteignent un jalon — participation à un webinaire, fin d’une séquence d’e-mails automatisée, trois filleuls parrainés — et vous voulez que ce tag déclenche un badge sans avoir à toucher l’API vous-même.

Dans Zapier :

1. Déclencheur : Mailchimp — New Tag Added to Subscriber, filtré sur le tag précis (par ex. webinar-attended).
2. Action : Webhooks by Zapier — POST vers https://api.badges.ninja/awards.
3. Données : mappez subscriber.email_address et subscriber.merge_fields.FNAME + LNAME vers les champs du destinataire.

Ce schéma est très utilisé pour les programmes de reconnaissance — SPIFF commerciaux, jalons communautaires, présence à des événements — où quelqu’un dans l’équipe a déjà l’habitude de taguer des contacts, et où vous voulez simplement que le badge découle gratuitement de cette habitude.

Gérer les erreurs et les nouvelles tentatives

Les plateformes d’automatisation ne sont pas transactionnelles vis-à-vis de vos données de badges ; appliquez donc la même rigueur que vous exigeriez d’une véritable intégration.

• Vérifiez le code de réponse. Un 200 signifie que la remise a été créée ; un 4xx signale généralement un badgeId erroné ou un e-mail mal formé — c’est un bug de configuration dans le Zap, pas quelque chose à réessayer aveuglément. Un 5xx peut être réessayé sans risque.
• Zapier : les exécutions de Zap échouées atterrissent dans le Zap History avec la requête et la réponse complètes. Activez Auto-Replay pour les échecs transitoires, mais configurez aussi une alerte e-mail/Slack en cas d’échecs répétés, pour qu’un Zap silencieusement cassé ne signifie pas trois mois de badges manquants.
• Make : les scénarios disposent d’une route native Error Handler — attachez une directive Resume ou Rollback au module HTTP, et routez les échecs persistants vers un module de notification plutôt que de simplement les ignorer.
• n8n : comme il offre un contrôle plus fin en auto-hébergement ou dans le cloud, encapsulez le nœud HTTP Request dans un workflow Error Trigger, et envisagez d’écrire les payloads échoués dans un stockage de secours léger (Airtable, Google Sheets) que vous pourrez rejouer manuellement.

Dans les trois cas, évitez le piège du « c’est passé au vert donc ça a fonctionné ». Une réponse qui ressemble à un 200 provenant d’une étape webhook mal configurée (mauvaise URL, en-tête manquant) peut quand même échouer côté Badges Ninja. Vérifiez chaque semaine, à la main, la liste des remises dans le tableau de bord pendant le premier mois de toute nouvelle automatisation.

L’équivalent sur Make.com

Le générateur visuel de scénarios de Make correspond presque terme à terme aux étapes Zapier ci-dessus :

1. Module déclencheur — module d’observation Typeform / Stripe / Mailchimp, identique au déclencheur Zapier.
2. Module HTTP → Make a Request — méthode POST, URL https://api.badges.ninja/awards, en-têtes définis dans le tableau Headers (X-Api-Key, Content-Type: application/json), corps en JSON brut avec les variables mappées depuis le déclencheur.
3. Filter optionnel entre les modules pour la vérification du montant Stripe ou le garde-fou « fin réelle » sur Typeform.

L’avantage de Make ici, c’est la visibilité — l’éditeur de scénario vous montre le payload JSON réel à chaque étape avant que vous ne l’activiez, ce qui rend le débogage d’un mauvais mappage de champ bien plus rapide que la vue de test étape par étape, plus linéaire, de Zapier.

L’équivalent sur n8n

n8n est le meilleur choix si vous voulez rester en auto-hébergement, ou si vous automatisez déjà d’autres parties de votre stack là-bas :

1. Nœud déclencheur — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (tous des nœuds intégrés).
2. Nœud HTTP Request — méthode POST, URL https://api.badges.ninja/awards, authentification réglée sur Header Auth avec votre X-Api-Key stockée comme identifiant n8n (jamais codée en dur dans le nœud), corps JSON construit à partir d’une expression référençant la sortie du nœud déclencheur.
3. Nœud IF (optionnel) — même garde-fou de complétion/montant que ci-dessus, placé avant le nœud HTTP Request.

Les identifiants n8n étant chiffrés et réutilisables entre workflows, c’est l’option la plus propre si vous prévoyez plusieurs automatisations Badges Ninja — configurez l’identifiant une fois, réutilisez-le dans chaque workflow qui doit émettre des badges.

Pourquoi une étape webhook générique plutôt qu’une appli native

Zapier, Make et n8n ont tous des marketplaces d’applications, et le réflexe naturel est de chercher une appli « Badges Ninja » avant de se rabattre sur un module HTTP/webhook générique. Évitez cette recherche — pour une API REST aussi réduite (créer un émetteur, créer un badge, créer une remise, c’est tout), une étape webhook générique vous met en production en dix minutes, sans dépendre d’un mainteneur d’appli tiers qui doit suivre le rythme des évolutions de l’API. Une appli dédiée ajoute une couche d’abstraction dont vous n’avez pas besoin : vous remplirez de toute façon les mêmes champs badgeId, recipient.email et recipient.name, simplement via un formulaire plutôt qu’un corps JSON. La référence de l’API se lit en cinq minutes, et une fois cette lecture faite, l’approche HTTP brute s’avère en réalité moins fragile : aucun cycle d’approbation d’app store ne se dresse entre une évolution de l’API Badges Ninja et le bon fonctionnement de votre automatisation.

Testez avant de mettre en production

Chaque plateforme ci-dessus vous permet d’exécuter un test unique sans attendre un véritable événement déclencheur :

• Zapier — utilisez « Test » sur l’étape de déclenchement pour récupérer un enregistrement type, puis « Test » sur l’action webhook pour envoyer exactement une requête réelle. Vérifiez que la remise apparaît dans votre tableau de bord avant d’activer le Zap.
• Make — exécutez le scénario manuellement une fois (bouton « Run once ») avec un lot d’exemple, et inspectez la bulle de sortie du module HTTP pour voir le corps de réponse réel.
• n8n — utilisez « Execute Node » sur le nœud HTTP Request avec des données de test, ce qui vous permet de voir la requête et la réponse directement dans l’éditeur.

Deux points méritent d’être vérifiés lors de ce premier test : que le badgeId codé en dur correspond bien au badge que vous pensez (un ID obsolète issu d’un Zap dupliqué est une erreur fréquente), et que le champ e-mail du destinataire récupère bien une adresse réelle et non un espace réservé comme {{email}} resté non résolu à cause d’une faute de mappage. Ces deux erreurs sont invisibles dans l’indicateur de « succès » de la plateforme d’automatisation — l’appel HTTP renvoie tout de même un 200 — donc la seule vérification fiable consiste à ouvrir la remise dans votre tableau de bord et à confirmer que le destinataire est bien celui attendu.

Éviter les badges en double

Chacune des sources de déclenchement ci-dessus peut, en conditions réelles, se déclencher plus d’une fois pour un même événement — Stripe relance les webhooks en cas de timeout, Typeform peut soumettre en double sur une connexion lente, les automatisations Mailchimp peuvent se redéclencher si un tag est retiré puis remis. Si votre émission de badges n’est pas idempotente, cela se traduit par des destinataires recevant deux fois la même créance, ce qui fait négligé et génère des e-mails de support.

La protection la plus propre est une étape de recherche avant création : avant la requête POST vers /awards, ajoutez une action Search (le « Find Award » de Zapier via une requête GET, ou l’équivalent HTTP GET dans Make/n8n) sur vos propres enregistrements de remise — un simple journal Google Sheets ou Airtable, alimenté par ce même Zap juste après une remise réussie, suffit très bien si vous ne voulez pas interroger l’API pour ça. Si un enregistrement existe déjà pour cette combinaison destinataire + badge, orientez le flux vers une branche sans action plutôt que d’émettre à nouveau. C’est un ajout de cinq minutes, et c’est ce qui fait la différence entre une automatisation à qui vous pouvez faire confiance sans surveillance, et une que vous devez surveiller en permanence.

Quand le no-code ne suffit plus

Ces recettes couvrent bien les déclencheurs événement par événement. Dès que vous devez émettre des centaines de badges à partir d’un seul export CSV — une cohorte entière qui obtient son diplôme, une liste de participants à une conférence, un renouvellement massif de crédits de formation continue — laissez de côté la plateforme d’automatisation et utilisez directement l’envoi groupé de badges : il se met en pause et reprend en plein milieu d’un lot, et survit à un onglet de navigateur fermé, ce que les boucles de webhook no-code ne gèrent pas correctement à ce volume.

---

Prêt à émettre votre première créance vérifiable ? Démarrez gratuitement sur badges.ninja — concepteur visuel, page de vérification publique, certificat PDF, sortie Open Badge v2.0. Aucune carte bancaire requise.