Automatiser Open Badges med Zapier, Make og n8n (no-code-oppskrifter)

Hvis du driver et treningsprogram, et betalt kurs eller en e-postliste med nivåer, er øyeblikket noen fullfører, kjøper eller kvalifiserer seg som regel allerede sporet et sted — et skjemasvar, en Stripe-belastning, en Mailchimp-tag. Badgen bør følge automatisk av den hendelsen. Det gjør den sjelden, fordi «utsted et bevis» ikke er en innebygd handling i de fleste verktøy, og det å bygge en egen webhook-mottaker for en enkeltstående automatisering er overkill.

Dette er nøyaktig hva Zapier, Make og n8n er til for. Alle tre kan kalle Badges Ninja API direkte — ingen plugin, ingen mellomvare-server, ingen kodeutrulling. Under følger tre fungerende oppskrifter du kan kopiere i dag, pluss håndtering av API-nøkler og feil-/retry-oppførsel du må få riktig, slik at badges ikke stille feiler å bli utstedt.

Hva du kobler sammen

Hver oppskrift følger samme mønster: utløser → (valgfritt) mottaker-oppslag → HTTP POST til /awards. /awards-endepunktet er det som faktisk utsteder en badge til en mottaker — du peker den mot en eksisterende badgeId, og den oppretter en unik, verifiserbar tildeling med sin egen verifiseringsside, QR-kode og PDF-sertifikat. Se API-hurtigstarten hvis du ikke har opprettet en badge ennå; du trenger ID-en før noen av disse automatiseringene kan kjøre.

Autentisering for alle tre plattformene er den samme: en X-Api-Key-header som bærer en nøkkel generert fra dashbordet ditt. Automatiseringsplattformer håndterer ikke OAuth-flyter godt for vilkårlige REST-API-er, så API-nøkler er riktig løsning her — langvarige, knyttet til kontoen din, og som kan tilbakekalles med ett klikk hvis en Zap noen gang feiler.

Opprett API-nøkkelen først

Fra dashbordet ditt, åpne Settings → API Keys, klikk Create Key, og gi den et navn som passer jobben — zapier-course-completions, ikke key1. Denne navngivingen betyr mer enn den høres ut som: hvis en automatisering oppfører seg dårlig om seks måneder, vil du tilbakekalle den nøkkelen uten å ødelegge tre andre integrasjoner som tilfeldigvis deler den.

Nøkkelen vises én gang, i sin helhet, umiddelbart etter opprettelse. Kopier den inn i automatiseringsplattformens sikre legitimasjonslager med én gang — Zapiers «Connection», Makes «Connection», eller en n8n-legitimasjon — aldri i et rent tekstfelt inne i selve Zap-en/scenarioet/workflowen.

Oppskrift 1: Typeform → Badges Ninja (kull-fullføringsskjema)

Bruksområde: et kull fullfører et kurs og fyller ut et kort «jeg har fullført dette»-skjema (eller du sender et skjema som siste steg i et selvgående løp).

I Zapier:

1. Utløser: Typeform — New Entry, begrenset til fullføringsskjemaet ditt.
2. Handling: Webhooks by Zapier — POST.
3. URL: https://api.badges.ninja/awards
4. Headere: X-Api-Key: bws_<din nøkkel>, Content-Type: application/json
5. Data (mappet fra Typeform-feltene):

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

Det er hele Zap-en. Ingen filter-steg er nødvendig hvis skjemaet bare utløses ved reelle fullføringer — hvis det er et generelt kontaktskjema, legg til et Filter by Zapier-steg som sjekker et skjult felt eller svarverdi før webhooken utløses, slik at du ikke utsteder badges fra spam eller testinnsendinger.

Oppskrift 2: Stripe → Badges Ninja (kjøp = bevis)

Bruksområde: en betalt sertifiseringseksamen, et premium kursnivå, eller en medlemskapsplan der badgen er en del av det folk kjøper.

I Zapier:

1. Utløser: Stripe — New Charge (eller New Invoice Payment Succeeded for abonnementer).
2. Filter: belastningsbeløpet er lik nøyaktig pris for det bevisbelagte produktet — dette er viktig hvis Stripe-kontoen din håndterer flere produkter gjennom én webhook.
3. Handling: Webhooks by Zapier — POST til https://api.badges.ninja/awards, samme headere som over.
4. Data: map charge.billing_details.email og charge.billing_details.name inn i recipient.email / recipient.name.

Det fine med å koble utstedelse til en betalingshendelse: det er naturlig idempotent-nært. Stripe-belastnings-ID-er er unike, så hvis du er bekymret for at en Zap kan utløses på nytt ved en gjenforsøkt webhook, legg til et Storage by Zapier-steg som sjekker om du allerede har behandlet den belastnings-ID-en før du kaller /awards.

Oppskrift 3: Mailchimp-tag → Badges Ninja

Bruksområde: du tagger abonnenter manuelt (eller via en annen automatisering) når de når en milepæl — deltok på et webinar, fullførte en drypp-sekvens, henviste tre personer — og vil at den taggen skal utløse en badge uten at du selv rører API-et.

I Zapier:

1. Utløser: Mailchimp — New Tag Added to Subscriber, filtrert til den spesifikke taggen (f.eks. webinar-attended).
2. Handling: Webhooks by Zapier — POST til https://api.badges.ninja/awards.
3. Data: map subscriber.email_address og subscriber.merge_fields.FNAME + LNAME inn i mottakerfeltene.

Dette mønsteret er populært for anerkjennelsesprogrammer — salgs-SPIFF-er, fellesskaps-milepæler, arrangementsdeltakelse — der noen på teamet allerede har for vane å tagge kontakter, og du bare vil at badgen skal falle ut av den vanen gratis.

Håndtering av feil og gjenforsøk

Automatiseringsplattformer er ikke transaksjonelle med badge-dataene dine, så bygg inn samme disiplin du ville ønsket fra en ekte integrasjon:

• Sjekk responskoden. En 200 betyr at tildelingen ble opprettet; en 4xx betyr som regel en ugyldig badgeId eller feilformatert e-post — det er en konfigurasjonsfeil i Zap-en, ikke noe å prøve på nytt blindt. En 5xx er trygt å prøve på nytt.
• Zapier: mislykkede Zap-kjøringer havner i Zap History med hele forespørselen/responsen. Skru på Auto-Replay for forbigående feil, men sett opp et e-post-/Slack-varsel ved gjentatte feil, slik at en stille ødelagt Zap ikke betyr tre måneder med manglende badges.
• Make: scenarioer støtter en innebygd Error Handler-rute — koble en Resume- eller Rollback-direktiv til HTTP-modulen, og rut vedvarende feil til en varslingsmodul i stedet for bare å forkaste dem.
• n8n: siden den er selvhostet eller sky med mer granulær kontroll, pakk HTTP Request-noden inn i en Error Trigger-workflow, og vurder å skrive mislykkede nyttelaster til et lettvekts fallback-lager (Airtable, Google Sheets) du kan kjøre på nytt manuelt.

I alle tre, unngå fellen med «det kjørte grønt, så det virket». En respons som ser 200 ut fra et feilkonfigurert webhook-steg (feil URL, manglende header) kan likevel feile på Badges Ninja-siden. Stikkprøve dashbordets tildelingsliste ukentlig i den første måneden av enhver ny automatisering.

Make.com-ekvivalenten

Makes visuelle scenariobygger kartlegges nesten direkte mot Zapier-stegene over:

1. Trigger-modul — Typeform-/Stripe-/Mailchimp-overvåkingsmodul, samme som Zapier-utløseren.
2. HTTP → Make a Request-modul — Metode POST, URL https://api.badges.ninja/awards, headere satt i Headers-tabellen (X-Api-Key, Content-Type: application/json), body som rå JSON med mappede variabler fra utløseren.
3. Valgfritt Filter mellom moduler for Stripe-beløpssjekken eller «reell fullføring»-vakten på Typeform.

Makes fordel her er synlighet — scenarioredigeringen viser deg den faktiske JSON-nyttelasten ved hvert steg før du skrur den på, noe som gjør feilsøking av en feil feltmapping mye raskere enn Zapiers mer lineære steg-for-steg-testvisning.

n8n-ekvivalenten

n8n er det beste valget hvis du vil ha dette selvhostet, eller hvis du allerede automatiserer andre deler av stacken din der:

1. Trigger-node — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (alle innebygde noder).
2. HTTP Request-node — Metode POST, URL https://api.badges.ninja/awards, autentisering satt til Header Auth med X-Api-Key-en din lagret som en n8n-legitimasjon (ikke hardkodet i noden), JSON-body bygget fra et uttrykk som refererer til utløsernodens output.
3. IF-node (valgfritt) — samme fullførings-/beløpsvakt som over, plassert før HTTP Request-noden.

Fordi n8n-legitimasjoner er krypterte og gjenbrukbare på tvers av workflows, er dette det ryddigste alternativet hvis du planlegger mer enn én Badges Ninja-automatisering — sett opp legitimasjonen én gang, gjenbruk den i hver workflow som trenger å utstede badges.

Hvorfor et generisk webhook-steg fremfor en nativ app

Zapier, Make og n8n har alle app-markedsplasser, og instinktet er å søke etter en «Badges Ninja»-app før man griper til en generisk HTTP-/webhook-modul. Hopp over det søket — for et REST-API så lite som dette (opprett en utsteder, opprett en badge, opprett en tildeling, ferdig), får et generisk webhook-steg deg i gang på ti minutter uten avhengighet av en tredjeparts app-vedlikeholder som må holde tritt med API-endringer. En dedikert app legger til et abstraksjonslag du ikke trenger: du ville fortsatt fylle ut de samme badgeId-, recipient.email- og recipient.name-feltene, bare gjennom et skjema i stedet for en JSON-body. API-referansen er kort nok til å leses på fem minutter, og når du har gjort det, er den rå HTTP-tilnærmingen faktisk mindre skjør — det er ingen app-butikk-godkjenningssyklus som står mellom en Badges Ninja API-endring og at automatiseringen din fungerer igjen.

Test før du skrur den live

Hver plattform over gir deg en måte å kjøre én enkelt testkjøring på uten å vente på en reell utløserhendelse:

• Zapier — bruk «Test» på utløsersteget for å hente en eksempelpost, deretter «Test» på webhook-handlingen for å avfyre nøyaktig én reell forespørsel. Sjekk at tildelingen dukker opp i dashbordet ditt før du skrur på Zap-en.
• Make — kjør scenarioet manuelt én gang («Run once»-knappen) med en eksempelbunt, og inspiser HTTP-modulens output-boble for det faktiske responsinnholdet.
• n8n — bruk «Execute Node» på HTTP Request-noden med testinndata, som lar deg se forespørselen og responsen direkte i editoren.

To ting verdt å sjekke på den første testkjøringen: at badgeId-en du hardkodet faktisk tilhører badgen du tror den gjør (en foreldet ID fra en duplisert Zap er en vanlig feil), og at mottaker-e-postfeltet henter en reell adresse og ikke en plassholder som {{email}} som forble uløst på grunn av en mappingfeil. Begge feilene er usynlige i automatiseringsplattformens «suksess»-indikator — HTTP-kallet returnerer fortsatt 200 uansett — så den eneste pålitelige sjekken er å åpne tildelingen i dashbordet ditt og bekrefte at mottakeren er den du forventer.

Unngå duplikate badges

Hver utløserkilde over kan, under virkelige forhold, utløses mer enn én gang for samme hendelse — Stripe prøver webhooks på nytt ved timeout, Typeform kan dobbeltsende ved en treg tilkobling, Mailchimp-automatiseringer kan utløses på nytt hvis en tag fjernes og legges til igjen. Hvis badge-utstedelsen din ikke er idempotent, blir det til at mottakere får det samme beviset to ganger, noe som ser slurvete ut og genererer support-e-post.

Den reneste beskyttelsen er et oppslag-før-opprettelse-steg: før /awards-POST-en, legg til en Search-handling (Zapiers «Find Award» via en GET-forespørsel, eller det tilsvarende Make/n8n HTTP GET) mot dine egne tildelingsposter — et lettvekts Google Sheet eller Airtable-loggen den samme Zap-en skriver til rett etter en vellykket tildeling fungerer fint til dette hvis du ikke vil spørre API-et om det. Hvis en post allerede finnes for den mottaker- + badge-kombinasjonen, grener til en no-op i stedet for å utstede på nytt. Dette er et fem-minutters tillegg, og det er forskjellen mellom en automatisering du stoler på uten tilsyn, og en du må barnevakte.

Når no-code ikke er nok

Disse oppskriftene dekker enkelthendelse-utløsere godt. Når du utsteder hundrevis av badges fra en enkelt CSV-eksport — et kull som fullfører, en konferansedeltakerliste, en bulk CE-poeng-fornyelse — hopp over automatiseringsplattformen og bruk bulk badge-opplasting direkte: den pauser og gjenopptar midt i batchen og overlever en lukket nettleserfane, noe no-code webhook-løkker ikke håndterer elegant i stort volum.

---

Klar til å utstede din første verifiserbare credential? Start gratis på badges.ninja — visuell designer, offentlig verifiseringsside, PDF-sertifikat, Open Badge v2.0-output. Ingen kredittkort nødvendig.