Automatisera Open Badges med Zapier, Make och n8n (no-code-recept)

Om du driver ett utbildningsprogram, en betald kurs eller en e-postlista med nivåer så är ögonblicket när någon blir klar, köper eller kvalificerar sig oftast redan spårat någonstans — ett formulärsvar, en Stripe-betalning, en Mailchimp-tagg. Badgen borde följa automatiskt av den händelsen. Det gör den sällan, eftersom “utfärda ett credential” inte är en inbyggd åtgärd i de flesta verktyg, och att bygga en egen webhook-mottagare för en engångsautomatisering är överkurs.

Det är precis vad Zapier, Make och n8n är till för. Alla tre kan anropa Badges Ninja API:et direkt — utan plugin, utan mellanliggande server, utan kodutrullning. Nedan är tre fungerande recept du kan kopiera idag, plus hanteringen av API-nyckeln och det retry-beteende vid fel du behöver få rätt så att badges inte tyst misslyckas att utfärdas.

Vad du kopplar ihop

Varje recept följer samma form: trigger → (valfri) mottagaruppslagning → HTTP POST till /awards. Endpointen /awards är det som faktiskt utfärdar en badge till en mottagare — du pekar den mot ett befintligt badgeId och den skapar en unik, verifierbar utmärkelse med sin egen verifieringsURL, QR-kod och PDF-certifikat. Se API-snabbstarten om du inte redan skapat en badge — du behöver dess ID innan någon av dessa automatiseringar kan köras.

Autentiseringen är densamma för alla tre plattformarna: en X-Api-Key-header som bär en nyckel genererad från din dashboard. Automatiseringsplattformar hanterar inte OAuth-flöden särskilt bra för godtyckliga REST-API:er, så API-nycklar är rätt val här — långlivade, knutna till ditt konto och återkallningsbara med ett klick om en Zap någonsin skulle bete sig fel.

Skapa API-nyckeln först

Öppna Settings → API Keys i din dashboard, klicka på Create Key och ge den ett namn som matchar dess jobb — zapier-course-completions, inte key1. Den namngivningen spelar större roll än det låter: om en automatisering börjar bete sig illa om sex månader vill du kunna återkalla just den nyckeln utan att sabba tre andra integrationer som råkar dela den.

Nyckeln visas en gång, i sin helhet, direkt efter att den skapats. Kopiera in den i din automatiseringsplattforms säkra credential-lager direkt — Zapiers “Connection”, Makes “Connection”, eller ett n8n-credential — aldrig i ett vanligt textfält inuti själva Zapen/scenariot/workflowet.

Recept 1: Typeform → Badges Ninja (formulär för avslutad kohort)

Användningsfall: en kohort avslutar en kurs och fyller i ett kort “jag är klar”-formulär (eller så skickar du ut ett sådant formulär som sista steg i en självstyrd utbildningsväg).

I Zapier:

1. Trigger: Typeform — New Entry, avgränsat till ditt avslutsformulär.
2. Åtgärd: Webhooks by Zapier — POST.
3. URL: https://api.badges.ninja/awards
4. Headers: X-Api-Key: bws_<your key>, Content-Type: application/json
5. Data (mappat från Typeform-fälten):

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

Det är hela Zapen. Inget filtersteg behövs om formuläret bara triggas vid riktiga avslut — om det är ett allmänt kontaktformulär, lägg till ett Filter by Zapier-steg som kontrollerar ett dolt fält eller ett svarsvärde innan webhooken triggas, så att du inte utfärdar badges från skräppost eller testinlämningar.

Recept 2: Stripe → Badges Ninja (köp = credential)

Användningsfall: ett betalt certifieringsprov, en premiumnivå av en kurs, eller ett medlemskap där badgen är en del av det folk köper.

I Zapier:

1. Trigger: Stripe — New Charge (eller New Invoice Payment Succeeded för prenumerationer).
2. Filter: betalningsbeloppet är exakt lika med priset på den produkt som ger credentialet — det här spelar roll om ditt Stripe-konto hanterar flera produkter genom en enda webhook.
3. Åtgärd: Webhooks by Zapier — POST till https://api.badges.ninja/awards, samma headers som ovan.
4. Data: mappa charge.billing_details.email och charge.billing_details.name till recipient.email / recipient.name.

Det trevliga med att koppla utfärdande till en betalningshändelse: det är naturligt nära idempotent. Stripes betalnings-ID:n är unika, så om du är orolig för att en Zap triggas om vid en återförsökt webhook, lägg till ett Storage by Zapier-steg som kollar om du redan har behandlat det betalnings-ID:t innan du anropar /awards.

Recept 3: Mailchimp-tagg → Badges Ninja

Användningsfall: du taggar prenumeranter manuellt (eller via en annan automatisering) när de når en milstolpe — deltog i ett webinar, avslutade en dripp-sekvens, hänvisade tre personer — och vill att den taggen ska trigga en badge utan att du själv rör API:et.

I Zapier:

1. Trigger: Mailchimp — New Tag Added to Subscriber, filtrerat på den specifika taggen (t.ex. webinar-attended).
2. Åtgärd: Webhooks by Zapier — POST till https://api.badges.ninja/awards.
3. Data: mappa subscriber.email_address och subscriber.merge_fields.FNAME + LNAME till mottagarfälten.

Det här mönstret är populärt för erkännandeprogram — säljtävlingar (SPIFF:ar), community-milstolpar, eventnärvaro — där någon i teamet redan har för vana att tagga kontakter, och du bara vill att badgen ska falla ut gratis ur den vanan.

Hantera fel och återförsök

Automatiseringsplattformar är inte transaktionella med din badge-data, så bygg in samma disciplin som du skulle vilja ha från en riktig integration:

• Kontrollera svarskoden. En 200 betyder att utmärkelsen skapades; en 4xx betyder oftast ett felaktigt badgeId eller en felformaterad e-postadress — det är en konfigurationsbugg i Zapen, inte något att blint försöka igen. En 5xx är säker att försöka igen.
• Zapier: misslyckade Zap-körningar hamnar i Zap History med hela förfrågan/svaret. Slå på Auto-Replay för tillfälliga fel, men sätt upp en e-post-/Slack-varning för upprepade fel så att en tyst trasig Zap inte innebär tre månader av saknade badges.
• Make: scenarier stöder en inbyggd Error Handler-rutt — koppla ett Resume- eller Rollback-direktiv till HTTP-modulen, och dirigera bestående fel till en notifieringsmodul istället för att bara kasta bort dem.
• n8n: eftersom det är självhostat eller molnbaserat med mer detaljerad kontroll, wrappa HTTP Request-noden i ett Error Trigger-workflow, och överväg att skriva misslyckade payloads till ett enkelt reservlager (Airtable, Google Sheets) som du kan spela upp igen manuellt.

I alla tre fallen, undvik fällan “det körde grönt, så det fungerade”. Ett svar som ser ut som 200 från ett felkonfigurerat webhook-steg (fel URL, saknad header) kan ändå misslyckas på Badges Ninja-sidan. Stickprovskontrollera dashboardens utmärkelselista varje vecka under den första månaden av varje ny automatisering.

Make.com-motsvarigheten

Makes visuella scenariobyggare mappar nästan direkt mot Zapier-stegen ovan:

1. Trigger-modul — Typeform-/Stripe-/Mailchimp-bevakningsmodul, precis som Zapier-triggern.
2. HTTP → Make a Request-modul — metod POST, URL https://api.badges.ninja/awards, headers satta i Headers-tabellen (X-Api-Key, Content-Type: application/json), body som rå JSON med mappade variabler från triggern.
3. Valfritt Filter mellan moduler för Stripe-beloppskontrollen eller “riktigt avslut”-skyddet på Typeform.

Makes fördel här är synlighet — scenarioredigeraren visar dig den faktiska JSON-payloaden i varje steg innan du aktiverar den, vilket gör felsökning av en felaktig fältmappning mycket snabbare än Zapiers mer linjära steg-för-steg-testvy.

n8n-motsvarigheten

n8n passar bäst om du vill ha detta självhostat, eller om du redan automatiserar andra delar av din stack där:

1. Trigger-nod — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (alla inbyggda noder).
2. HTTP Request-nod — metod POST, URL https://api.badges.ninja/awards, autentisering satt till Header Auth med din X-Api-Key lagrad som ett n8n-credential (inte hårdkodad i noden), JSON-body byggd från ett uttryck som refererar till trigger-nodens output.
3. IF-nod (valfritt) — samma avslut-/beloppsskydd som ovan, placerat före HTTP Request-noden.

Eftersom n8n-credentials är krypterade och återanvändbara över workflows är det här det renare alternativet om du planerar mer än en Badges Ninja-automatisering — sätt upp credentialet en gång, återanvänd det i varje workflow som behöver utfärda badges.

Varför ett generiskt webhook-steg istället för en inbyggd app

Zapier, Make och n8n har alla appmarknadsplatser, och instinkten är att söka efter en “Badges Ninja”-app innan man tar till en generisk HTTP-/webhook-modul. Hoppa över den sökningen — för ett så litet REST-API (skapa en utfärdare, skapa en badge, skapa en utmärkelse, klart) tar ett generiskt webhook-steg dig live på tio minuter utan något beroende av att en tredjeparts appunderhållare håller jämna steg med API-ändringar. En dedikerad app lägger till ett abstraktionslager du inte behöver: du skulle fortfarande fylla i samma badgeId-, recipient.email- och recipient.name-fält, bara genom ett formulär istället för en JSON-body. API-referensen är kort nog att läsa på fem minuter, och när du gjort det är den råa HTTP-metoden faktiskt mindre skör — det finns ingen app-store-godkännandecykel mellan en ändring i Badges Ninja-API:et och att din automatisering fungerar igen.

Testa innan du slår på det på riktigt

Varje plattform ovan ger dig ett sätt att köra en enda testkörning utan att vänta på en riktig triggerhändelse:

• Zapier — använd “Test” på triggersteget för att hämta en exempelpost, sedan “Test” på webhook-åtgärden för att skicka exakt en riktig förfrågan. Kontrollera att utmärkelsen dyker upp i din dashboard innan du slår på Zapen.
• Make — kör scenariot manuellt en gång (knappen “Run once”) med en exempelbundle och inspektera HTTP-modulens output-bubbla för det faktiska svarets body.
• n8n — använd “Execute Node” på HTTP Request-noden med testindata, vilket låter dig se förfrågan och svaret direkt i redigeraren.

Två saker är värda att kontrollera vid den första testkörningen: att det hårdkodade badgeId:t faktiskt tillhör den badge du tror att det gör (ett inaktuellt ID från en duplicerad Zap är ett vanligt misstag), och att mottagarens e-postfält hämtar en riktig adress och inte en platshållare som {{email}} som blivit olöst på grund av en mappningsfel. Båda misstagen är osynliga i automatiseringsplattformens “lyckades”-indikator — HTTP-anropet returnerar ändå 200 — så den enda tillförlitliga kontrollen är att öppna utmärkelsen i din dashboard och bekräfta att mottagaren är den du förväntar dig.

Undvika dubbla badges

Varje triggerkälla ovan kan, under verkliga förhållanden, triggas mer än en gång för samma händelse — Stripe försöker webhooks igen vid timeout, Typeform kan skicka in dubbelt vid en långsam anslutning, Mailchimp-automatiseringar kan trigga om en tagg tas bort och läggs till igen. Om ditt badge-utfärdande inte är idempotent blir det till mottagare som får samma credential två gånger, vilket ser slarvigt ut och genererar supportmejl.

Det renaste skyddet är ett uppslag-innan-skapande-steg: lägg till en Search-åtgärd innan /awards-POST:en (Zapiers “Find Award” via en GET-förfrågan, eller motsvarande HTTP GET i Make/n8n) mot dina egna utmärkelseregister — en enkel Google Sheet eller Airtable-logg som samma Zap skriver till direkt efter en lyckad utmärkelse fungerar bra för detta om du inte vill fråga API:et för det. Om det redan finns en post för den mottagar- + badge-kombinationen, förgrena till en no-op istället för att utfärda igen. Det är ett femminuterstillägg, och det är skillnaden mellan en automatisering du litar på obevakad och en du måste passa.

När no-code inte räcker till

De här recepten täcker enstaka triggerhändelser bra. När du väl utfärdar hundratals badges från en enda CSV-export — en examinerande kohort, en konferensdeltagarlista, en massförnyelse av CE-poäng — hoppa över automatiseringsplattformen och använd bulk badge-uppladdning direkt: den pausar och återupptas mitt i en batch och överlever en stängd webbläsarflik, vilket no-code-webhookloopar inte hanterar lika elegant vid volym.

---

Redo att utfärda ditt första verifierbara credential? Kom igång gratis på badges.ninja — visuell designer, offentlig verifieringssida, PDF-certifikat, Open Badge v2.0-utdata. Inget kreditkort krävs.