Open Badges mit Zapier, Make und n8n automatisieren (No-Code-Rezepte)

Löse die Badge-Ausstellung durch einen abgeschlossenen Typeform, einen Stripe-Kauf oder einen Mailchimp-Tag aus – drei funktionierende No-Code-Rezepte, die jeweils unter 10 Minuten dauern.

Nacho Coll Von Aktualisiert 9 Min. Lesezeit
Löse die Badge-Ausstellung durch einen abgeschlossenen Typeform, einen Stripe-Kauf oder einen Mailchimp-Tag aus – drei funktionierende No-Code-Rezepte, die jeweils unter 10 Minuten dauern.

Wenn du ein Trainingsprogramm, einen kostenpflichtigen Kurs oder eine gestaffelte E-Mail-Liste betreibst, ist der Moment, in dem jemand fertig wird, kauft oder sich qualifiziert, meist schon irgendwo erfasst – eine Formularantwort, eine Stripe-Zahlung, ein Mailchimp-Tag. Das Badge sollte diesem Ereignis automatisch folgen. Meistens tut es das nicht, weil „eine Credential ausstellen” in den wenigsten Tools eine native Aktion ist und ein eigener Webhook-Empfänger für eine einmalige Automatisierung völlig überdimensioniert wäre.

Genau dafür gibt es Zapier, Make und n8n. Alle drei können die Badges Ninja API direkt aufrufen – kein Plugin, kein Middleware-Server, kein Code-Deployment. Im Folgenden findest du drei funktionierende Rezepte, die du dir noch heute kopieren kannst, dazu die Handhabung des API-Keys und das Verhalten bei Fehlern und Wiederholungsversuchen, das du richtig hinbekommen musst, damit Badges nicht stillschweigend nicht ausgestellt werden.

Was du hier verdrahtest

Jedes Rezept folgt derselben Struktur: Trigger → (optional) Empfänger-Lookup → HTTP-POST an /awards. Der /awards-Endpunkt stellt tatsächlich ein Badge an einen Empfänger aus – du gibst eine bestehende badgeId an, und er erzeugt eine eindeutige, überprüfbare Verleihung mit eigener Verifizierungs-URL, QR-Code und PDF-Zertifikat. Schau dir den API-Schnelleinstieg an, falls du noch kein Badge erstellt hast – du brauchst dessen ID, bevor eine dieser Automatisierungen laufen kann.

Die Authentifizierung ist bei allen drei Plattformen gleich: ein X-Api-Key-Header mit einem Schlüssel, den du in deinem Dashboard generierst. Automatisierungsplattformen kommen mit OAuth-Flows für beliebige REST-APIs nicht gut zurecht, deshalb sind API-Keys hier die richtige Wahl – langlebig, an dein Konto gebunden und mit einem Klick widerrufbar, falls ein Zap mal Unsinn macht.

Erstelle zuerst den API-Key

API Keys — empty state

Öffne in deinem Dashboard Einstellungen → API-Keys, klicke auf Key erstellen und gib ihm einen Namen, der zu seiner Aufgabe passt – zapier-course-completions, nicht key1. Diese Benennung ist wichtiger, als es klingt: Wenn eine Automatisierung in sechs Monaten Ärger macht, willst du genau diesen Key widerrufen können, ohne drei andere Integrationen zu zerstören, die ihn zufällig mitbenutzen.

Create key — name form

Der Key wird direkt nach der Erstellung einmalig vollständig angezeigt. Kopiere ihn sofort in den sicheren Zugangsdaten-Speicher deiner Automatisierungsplattform – Zapiers „Connection”, Makes „Connection” oder ein n8n-Credential – niemals in ein Klartextfeld innerhalb des Zaps/Scenarios/Workflows selbst.

Rezept 1: Typeform → Badges Ninja (Abschlussformular für eine Kohorte)

Anwendungsfall: Eine Kohorte schließt einen Kurs ab und füllt ein kurzes „Ich habe abgeschlossen”-Formular aus (oder du schickst als letzten Schritt eines selbstgesteuerten Kurses ein Formular).

In Zapier:

  1. Trigger: Typeform — New Entry, eingegrenzt auf dein Abschlussformular.
  2. Aktion: Webhooks by Zapier — POST.
  3. URL: https://api.badges.ninja/awards
  4. Header: X-Api-Key: bws_<dein Key>, Content-Type: application/json
  5. Daten (aus den Typeform-Feldern gemappt):
{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

Das ist der komplette Zap. Kein Filterschritt nötig, wenn das Formular nur bei echten Abschlüssen auslöst – handelt es sich um ein allgemeines Kontaktformular, füge vor dem Webhook einen Filter by Zapier-Schritt ein, der ein verstecktes Feld oder einen Antwortwert prüft, damit du keine Badges aus Spam oder Test-Einreichungen ausstellst.

Rezept 2: Stripe → Badges Ninja (Kauf = Credential)

Anwendungsfall: eine kostenpflichtige Zertifizierungsprüfung, eine Premium-Kursstufe oder ein Mitgliedschaftsplan, bei dem das Badge Teil dessen ist, was gekauft wird.

In Zapier:

  1. Trigger: Stripe — New Charge (bei Abos New Invoice Payment Succeeded).
  2. Filter: Der Zahlungsbetrag muss exakt dem Preis des Produkts entsprechen, das die Credential auslöst – wichtig, wenn dein Stripe-Konto mehrere Produkte über einen Webhook abwickelt.
  3. Aktion: Webhooks by Zapier — POST an https://api.badges.ninja/awards, gleiche Header wie oben.
  4. Daten: mappe charge.billing_details.email und charge.billing_details.name auf recipient.email / recipient.name.

Das Schöne daran, die Ausstellung an ein Zahlungsereignis zu koppeln: Sie ist damit von Natur aus fast idempotent. Stripe-Charge-IDs sind eindeutig – falls du befürchtest, dass ein Zap bei einem erneut zugestellten Webhook noch einmal auslöst, füge einen Storage by Zapier-Schritt ein, der prüft, ob du diese Charge-ID schon verarbeitet hast, bevor /awards aufgerufen wird.

Rezept 3: Mailchimp-Tag → Badges Ninja

Anwendungsfall: Du taggst Abonnenten manuell (oder über eine andere Automatisierung), wenn sie einen Meilenstein erreichen – ein Webinar besucht, eine Drip-Sequenz abgeschlossen, drei Personen geworben – und möchtest, dass dieser Tag ein Badge auslöst, ohne selbst die API anzufassen.

In Zapier:

  1. Trigger: Mailchimp — New Tag Added to Subscriber, gefiltert auf den spezifischen Tag (z. B. webinar-attended).
  2. Aktion: Webhooks by Zapier — POST an https://api.badges.ninja/awards.
  3. Daten: mappe subscriber.email_address sowie subscriber.merge_fields.FNAME + LNAME auf die Empfängerfelder.

Dieses Muster ist bei Anerkennungsprogrammen beliebt – Sales-SPIFFs, Community-Meilensteine, Event-Teilnahme – bei denen jemand im Team ohnehin schon die Gewohnheit hat, Kontakte zu taggen, und du willst, dass das Badge einfach als Nebenprodukt aus dieser Gewohnheit entsteht.

Fehler und Wiederholungsversuche behandeln

Automatisierungsplattformen sind gegenüber deinen Badge-Daten nicht transaktional, also baue dieselbe Disziplin ein, die du von einer echten Integration erwarten würdest:

  • Prüfe den Response-Code. Ein 200 bedeutet, dass die Verleihung erstellt wurde; ein 4xx bedeutet meist eine falsche badgeId oder eine fehlerhafte E-Mail-Adresse – das ist ein Konfigurationsfehler im Zap, kein Fall für blindes Wiederholen. Ein 5xx kann gefahrlos wiederholt werden.
  • Zapier: Fehlgeschlagene Zap-Läufe landen mit vollständigem Request/Response in der Zap History. Schalte Auto-Replay für vorübergehende Fehler ein, richte aber auch einen E-Mail-/Slack-Alarm bei wiederholten Fehlern ein, damit ein still kaputter Zap nicht drei Monate lang fehlende Badges bedeutet.
  • Make: Szenarien unterstützen eine native Error-Handler-Route – hänge eine Resume- oder Rollback-Direktive an das HTTP-Modul und leite dauerhafte Fehler an ein Benachrichtigungsmodul weiter, statt sie einfach zu verwerfen.
  • n8n: Da es selbst gehostet oder in der Cloud mit feinerer Kontrolle läuft, umwickle den HTTP-Request-Node mit einem Error-Trigger-Workflow und erwäge, fehlgeschlagene Payloads in einen leichtgewichtigen Fallback-Speicher (Airtable, Google Sheets) zu schreiben, den du manuell erneut abspielen kannst.

Vermeide bei allen dreien die Falle „lief grün, also hat’s geklappt”. Eine 200-artige Antwort von einem falsch konfigurierten Webhook-Schritt (falsche URL, fehlender Header) kann auf der Badges-Ninja-Seite trotzdem fehlschlagen. Wirf im ersten Monat jeder neuen Automatisierung wöchentlich einen Blick in die Verleihungsliste im Dashboard.

Das Make.com-Äquivalent

Der visuelle Scenario-Builder von Make bildet die obigen Zapier-Schritte fast eins zu eins ab:

  1. Trigger-Modul — Typeform-/Stripe-/Mailchimp-Watch-Modul, genau wie der Zapier-Trigger.
  2. HTTP → Make a Request-Modul — Methode POST, URL https://api.badges.ninja/awards, Header in der Headers-Tabelle gesetzt (X-Api-Key, Content-Type: application/json), Body als rohes JSON mit den aus dem Trigger gemappten Variablen.
  3. Optionaler Filter zwischen den Modulen für die Stripe-Betragsprüfung oder den „echter Abschluss”-Schutz bei Typeform.

Makes Vorteil hier ist die Transparenz – der Scenario-Editor zeigt dir das tatsächliche JSON-Payload jedes Schritts, bevor du ihn aktivierst, was das Debuggen eines falschen Feld-Mappings deutlich schneller macht als Zapiers eher lineare Schritt-für-Schritt-Testansicht.

Das n8n-Äquivalent

n8n eignet sich am besten, wenn du es selbst hosten willst oder ohnehin schon andere Teile deines Stacks dort automatisierst:

  1. Trigger-Node — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (alles eingebaute Nodes).
  2. HTTP-Request-Node — Methode POST, URL https://api.badges.ninja/awards, Authentifizierung auf Header Auth gesetzt, mit deinem X-Api-Key gespeichert als n8n-Credential (nicht im Node hartcodiert), JSON-Body über einen Ausdruck aufgebaut, der auf die Ausgabe des Trigger-Nodes verweist.
  3. IF-Node (optional) — derselbe Abschluss-/Betragsschutz wie oben, platziert vor dem HTTP-Request-Node.

Weil n8n-Credentials verschlüsselt und über Workflows hinweg wiederverwendbar sind, ist das die sauberere Option, wenn du mehr als eine Badges-Ninja-Automatisierung planst – Credential einmal anlegen, in jedem Workflow wiederverwenden, der Badges ausstellen muss.

Warum ein generischer Webhook-Schritt statt einer nativen App

Zapier, Make und n8n haben alle App-Marktplätze, und der Reflex ist, zuerst nach einer „Badges Ninja”-App zu suchen, bevor man zu einem generischen HTTP-/Webhook-Modul greift. Spar dir diese Suche – bei einer so kleinen REST-API (Aussteller anlegen, Badge anlegen, Verleihung anlegen, das war’s) bringt dich ein generischer Webhook-Schritt in zehn Minuten live, ganz ohne Abhängigkeit davon, ob ein Drittanbieter-App-Maintainer mit API-Änderungen Schritt hält. Eine dedizierte App fügt eine Abstraktionsebene hinzu, die du nicht brauchst: Du würdest trotzdem dieselben Felder badgeId, recipient.email und recipient.name ausfüllen, nur über ein Formular statt über einen JSON-Body. Die API-Referenz ist kurz genug, um sie in fünf Minuten zu lesen, und danach zeigt sich: Der rohe HTTP-Ansatz ist tatsächlich weniger fragil – zwischen einer Änderung an der Badges-Ninja-API und deiner funktionierenden Automatisierung steht kein App-Store-Freigabezyklus.

Teste, bevor du live gehst

Jede der oben genannten Plattformen bietet dir die Möglichkeit, einen einzelnen Testlauf auszuführen, ohne auf ein echtes Trigger-Ereignis zu warten:

  • Zapier — nutze „Test” beim Trigger-Schritt, um einen Beispiel-Datensatz zu holen, dann „Test” bei der Webhook-Aktion, um genau eine echte Anfrage abzusenden. Prüfe, ob die Verleihung in deinem Dashboard erscheint, bevor du den Zap aktivierst.
  • Make — führe das Szenario einmal manuell aus (“Run once”-Button) mit einem Beispiel-Bundle und schau dir im Output-Bubble des HTTP-Moduls den tatsächlichen Response-Body an.
  • n8n — nutze „Execute Node” am HTTP-Request-Node mit Testdaten, dann siehst du Request und Response direkt im Editor.

Zwei Dinge lohnt es sich, bei diesem ersten Testlauf zu prüfen: dass die hartcodierte badgeId wirklich zu dem Badge gehört, das du meinst (eine veraltete ID aus einem duplizierten Zap ist ein häufiger Fehler), und dass das Empfänger-E-Mail-Feld tatsächlich eine echte Adresse zieht und nicht wegen eines Mapping-Tippfehlers als unaufgelöster Platzhalter wie {{email}} stehen bleibt. Beide Fehler sind in der „Erfolgs”-Anzeige der Automatisierungsplattform unsichtbar – der HTTP-Aufruf liefert so oder so 200 zurück –, deshalb ist die einzig verlässliche Kontrolle, die Verleihung im Dashboard zu öffnen und zu bestätigen, dass der Empfänger der ist, den du erwartest.

Doppelte Badges vermeiden

Jede der oben genannten Trigger-Quellen kann unter realen Bedingungen mehr als einmal für dasselbe Ereignis auslösen – Stripe wiederholt Webhooks bei Timeout, Typeform kann bei langsamer Verbindung doppelt einreichen, Mailchimp-Automatisierungen können erneut auslösen, wenn ein Tag entfernt und wieder hinzugefügt wird. Ist deine Badge-Ausstellung nicht idempotent, erhalten Empfänger dieselbe Credential zweimal – das wirkt schlampig und erzeugt Support-Anfragen.

Der sauberste Schutz ist ein Lookup-vor-Erstellung-Schritt: Füge vor dem /awards-POST eine Search-Aktion ein (Zapiers „Find Award” über eine GET-Anfrage, oder das entsprechende HTTP-GET in Make/n8n) gegen deine eigenen Verleihungs-Datensätze – ein einfaches Google-Sheet oder Airtable-Log, in das derselbe Zap direkt nach einer erfolgreichen Verleihung schreibt, reicht dafür völlig aus, wenn du die API dafür nicht abfragen willst. Existiert bereits ein Datensatz für diese Kombination aus Empfänger und Badge, verzweige zu einem No-op, statt erneut auszustellen. Das ist eine Fünf-Minuten-Ergänzung – und der Unterschied zwischen einer Automatisierung, der du unbeaufsichtigt vertraust, und einer, die du im Auge behalten musst.

Wenn No-Code nicht mehr reicht

Diese Rezepte decken Einzelereignis-Trigger gut ab. Sobald du Hunderte Badges aus einem einzigen CSV-Export ausstellst – eine ganze Kohorte, die abschließt, eine Konferenz-Teilnehmerliste, eine Massen-Erneuerung von CE-Credits – lass die Automatisierungsplattform links liegen und nutze den Badge-Massen-Upload direkt: Er pausiert und setzt mitten im Batch fort und übersteht ein geschlossenes Browser-Tab, was No-Code-Webhook-Schleifen bei diesem Volumen nicht sauber hinbekommen.


Bereit, deine erste überprüfbare Credential auszustellen? Kostenlos starten auf badges.ninja — visueller Designer, öffentliche Verifizierungsseite, PDF-Zertifikat, Open-Badge-v2.0-Ausgabe. Keine Kreditkarte erforderlich.

Nacho Coll

Über den 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.

Zurück zum Blog

Verwandte Artikel