Automatizza gli Open Badge con Zapier, Make e n8n (ricette no-code)

Attiva l'emissione di un badge dal completamento di un Typeform, un acquisto Stripe o un tag Mailchimp — tre ricette no-code funzionanti, ciascuna in meno di 10 minuti.

Nacho Coll Di Aggiornato 10 min di lettura
Attiva l'emissione di un badge dal completamento di un Typeform, un acquisto Stripe o un tag Mailchimp — tre ricette no-code funzionanti, ciascuna in meno di 10 minuti.

Se gestisci un programma di formazione, un corso a pagamento o una mailing list a livelli, il momento in cui qualcuno finisce, acquista o si qualifica è di solito già tracciato da qualche parte — la risposta a un form, un addebito Stripe, un tag Mailchimp. Il badge dovrebbe seguire automaticamente quell’evento. Raramente succede, perché «emettere una credenziale» non è un’azione nativa nella maggior parte degli strumenti, e costruire un ricevitore webhook personalizzato per un’automazione occasionale è eccessivo.

È esattamente per questo che esistono Zapier, Make e n8n. Tutti e tre possono chiamare direttamente l’API di Badges Ninja — senza plugin, senza server intermedio, senza deploy di codice. Di seguito trovi tre ricette funzionanti che puoi copiare oggi stesso, oltre alla gestione della chiave API e al comportamento di retry sugli errori che devi impostare correttamente, così i badge non falliscono in silenzio.

Cosa stai collegando

Ogni ricetta segue lo stesso schema: trigger → (opzionale) ricerca del destinatario → POST HTTP a /awards. L’endpoint /awards è quello che emette effettivamente un badge a un destinatario — lo punti verso un badgeId esistente e lui crea un premio unico e verificabile, con una propria URL di verifica, codice QR e certificato PDF. Consulta la guida rapida all’API se non hai ancora creato un badge; ti servirà il suo ID prima che una di queste automazioni possa funzionare.

L’autenticazione per tutte e tre le piattaforme è la stessa: un header X-Api-Key con una chiave generata dalla tua dashboard. Le piattaforme di automazione non gestiscono bene i flussi OAuth per API REST generiche, quindi le chiavi API sono la scelta giusta qui — durature nel tempo, associate al tuo account e revocabili con un clic se uno Zap dovesse mai comportarsi male.

Crea prima la chiave API

API Keys — empty state

Dalla tua dashboard, apri Impostazioni → Chiavi API, clicca su Crea chiave e dalle un nome che rispecchi il suo compito — zapier-course-completions, non key1. Questo dettaglio conta più di quanto sembri: se tra sei mesi un’automazione dovesse comportarsi male, vuoi poter revocare quella chiave senza rompere altre tre integrazioni che la condividono per caso.

Create key — name form

La chiave viene mostrata una sola volta, per intero, subito dopo la creazione. Copiala immediatamente nell’archivio credenziali sicuro della tua piattaforma di automazione — la «Connection» di Zapier, la «Connection» di Make, o una credenziale n8n — mai in un campo di testo semplice dentro allo Zap/scenario/workflow stesso.

Ricetta 1: Typeform → Badges Ninja (form di completamento coorte)

Caso d’uso: una coorte finisce un corso e compila un breve form «ho completato questo» (oppure invii un form come passaggio finale di un percorso self-paced).

Su Zapier:

  1. Trigger: Typeform — New Entry, limitato al tuo form di completamento.
  2. Azione: Webhooks by Zapier — POST.
  3. URL: https://api.badges.ninja/awards
  4. Header: X-Api-Key: bws_<your key>, Content-Type: application/json
  5. Dati (mappati dai campi Typeform):
{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

Questo è tutto lo Zap. Non serve un passaggio di filtro se il form si attiva solo per completamenti reali — se invece è un form di contatto generico, aggiungi un passaggio Filter by Zapier che controlli un campo nascosto o un valore di risposta prima che il webhook parta, così non emetti badge da spam o invii di test.

Ricetta 2: Stripe → Badges Ninja (acquisto = credenziale)

Caso d’uso: un esame di certificazione a pagamento, un livello di corso premium, o un piano di membership in cui il badge fa parte di ciò che le persone stanno acquistando.

Su Zapier:

  1. Trigger: Stripe — New Charge (o New Invoice Payment Succeeded per gli abbonamenti).
  2. Filtro: l’importo dell’addebito corrisponde esattamente al prezzo del prodotto che dà diritto alla credenziale — importante se il tuo account Stripe gestisce più prodotti attraverso un unico webhook.
  3. Azione: Webhooks by Zapier — POST verso https://api.badges.ninja/awards, stessi header di prima.
  4. Dati: mappa charge.billing_details.email e charge.billing_details.name su recipient.email / recipient.name.

Il lato positivo di legare l’emissione a un evento di pagamento: è naturalmente quasi idempotente. Gli ID degli addebiti Stripe sono unici, quindi se temi che uno Zap si riattivi su un webhook ripetuto, aggiungi un passaggio Storage by Zapier che verifichi se hai già elaborato quell’ID addebito prima di chiamare /awards.

Ricetta 3: Tag Mailchimp → Badges Ninja

Caso d’uso: tagghi manualmente gli iscritti (oppure tramite un’altra automazione) quando raggiungono un traguardo — hanno partecipato a un webinar, finito una sequenza drip, portato tre referral — e vuoi che quel tag attivi un badge senza toccare tu stesso l’API.

Su Zapier:

  1. Trigger: Mailchimp — New Tag Added to Subscriber, filtrato sul tag specifico (es. webinar-attended).
  2. Azione: Webhooks by Zapier — POST verso https://api.badges.ninja/awards.
  3. Dati: mappa subscriber.email_address e subscriber.merge_fields.FNAME + LNAME sui campi del destinatario.

Questo schema è molto usato nei programmi di riconoscimento — SPIFF di vendita, traguardi della community, partecipazione a eventi — dove qualcuno del team ha già l’abitudine di taggare i contatti, e tu vuoi solo che il badge scaturisca gratis da quell’abitudine.

Gestire errori e retry

Le piattaforme di automazione non sono transazionali rispetto ai dati dei tuoi badge, quindi devi applicare la stessa disciplina che vorresti da un’integrazione vera:

  • Controlla il codice di risposta. Un 200 significa che il premio è stato creato; un 4xx di solito indica un badgeId errato o un’email malformata — è un bug di configurazione nello Zap, non qualcosa da ritentare alla cieca. Un 5xx è sicuro da ritentare.
  • Zapier: le esecuzioni Zap fallite finiscono nella Zap History con richiesta/risposta complete. Attiva Auto-Replay per i fallimenti transitori, ma imposta un avviso email/Slack sui fallimenti ripetuti, così uno Zap rotto in silenzio non significa tre mesi di badge mancanti.
  • Make: gli scenari supportano un percorso nativo Error Handler — collega una direttiva Resume o Rollback al modulo HTTP, e indirizza i fallimenti persistenti verso un modulo di notifica invece di limitarti a scartarli.
  • n8n: essendo self-hosted o cloud con un controllo più granulare, avvolgi il nodo HTTP Request in un workflow Error Trigger, e valuta di scrivere i payload falliti in un archivio di fallback leggero (Airtable, Google Sheets) che puoi ripetere manualmente.

In tutti e tre i casi, evita la trappola del «se è verde ha funzionato». Una risposta apparentemente 200 da un passaggio webhook mal configurato (URL sbagliato, header mancante) può comunque fallire lato Badges Ninja. Controlla a campione l’elenco premi della dashboard ogni settimana durante il primo mese di qualsiasi nuova automazione.

L’equivalente su Make.com

Il generatore visivo di scenari di Make ricalca quasi direttamente i passaggi Zapier sopra:

  1. Modulo trigger — modulo di ascolto Typeform / Stripe / Mailchimp, come il trigger di Zapier.
  2. HTTP → Make a Request module — Metodo POST, URL https://api.badges.ninja/awards, header impostati nella tabella Headers (X-Api-Key, Content-Type: application/json), corpo in JSON grezzo con variabili mappate dal trigger.
  3. Filter opzionale tra i moduli per il controllo dell’importo Stripe o la verifica «completamento reale» su Typeform.

Il vantaggio di Make qui è la visibilità — l’editor dello scenario ti mostra il payload JSON effettivo a ogni passaggio prima che tu lo attivi, il che rende il debug di un mapping di campo sbagliato molto più veloce rispetto alla vista test più lineare, passo dopo passo, di Zapier.

L’equivalente su n8n

n8n è la scelta migliore se vuoi tutto questo self-hosted, o se stai già automatizzando altre parti del tuo stack lì:

  1. Nodo trigger — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (tutti nodi integrati).
  2. Nodo HTTP Request — Metodo POST, URL https://api.badges.ninja/awards, autenticazione impostata su Header Auth con la tua X-Api-Key salvata come credenziale n8n (non hardcoded nel nodo), corpo JSON costruito con un’espressione che fa riferimento all’output del nodo trigger.
  3. Nodo IF (opzionale) — stesso controllo su completamento/importo di prima, posizionato prima del nodo HTTP Request.

Poiché le credenziali n8n sono cifrate e riutilizzabili tra i workflow, questa è l’opzione più pulita se stai pianificando più di un’automazione Badges Ninja — imposti la credenziale una volta sola e la riutilizzi in ogni workflow che deve emettere badge.

Perché un passaggio webhook generico invece di un’app nativa

Zapier, Make e n8n hanno tutti dei marketplace di app, e l’istinto è cercare un’app «Badges Ninja» prima di ricorrere a un modulo HTTP/webhook generico. Salta quella ricerca — per un’API REST così piccola (crea un emittente, crea un badge, crea un premio, fatto), un passaggio webhook generico ti mette in produzione in dieci minuti, senza alcuna dipendenza da un mantainer di app terze che stia al passo con i cambiamenti dell’API. Un’app dedicata aggiunge un livello di astrazione di cui non hai bisogno: staresti comunque compilando gli stessi campi badgeId, recipient.email e recipient.name, solo tramite un form invece che con un corpo JSON. La documentazione API è abbastanza breve da leggere in cinque minuti, e una volta fatto, l’approccio HTTP grezzo è in realtà meno fragile — non c’è nessun ciclo di approvazione da app store tra un cambiamento dell’API di Badges Ninja e la tua automazione che torna a funzionare.

Testa prima di attivarlo davvero

Ogni piattaforma sopra ti offre un modo per eseguire un singolo test senza aspettare un evento trigger reale:

  • Zapier — usa «Test» sul passaggio trigger per recuperare un record di esempio, poi «Test» sull’azione webhook per far partire esattamente una richiesta reale. Controlla che il premio compaia nella tua dashboard prima di attivare lo Zap.
  • Make — esegui manualmente lo scenario una volta (pulsante «Run once») con un bundle di esempio, e ispeziona la bolla di output del modulo HTTP per vedere il corpo effettivo della risposta.
  • n8n — usa «Execute Node» sul nodo HTTP Request con dati di input di test, così vedi richiesta e risposta direttamente nell’editor.

Due cose da controllare in quel primo test: che il badgeId che hai hardcodato appartenga davvero al badge che pensi (un ID datato di uno Zap duplicato è un errore comune), e che il campo email del destinatario stia recuperando un indirizzo reale e non un segnaposto come {{email}} rimasto non risolto per un errore di mapping. Entrambi gli errori sono invisibili nell’indicatore di «successo» della piattaforma di automazione — la chiamata HTTP restituisce comunque 200 in entrambi i casi — quindi l’unico controllo affidabile è aprire il premio nella tua dashboard e confermare che il destinatario sia quello che ti aspetti.

Evitare badge duplicati

Ognuna delle sorgenti trigger sopra può, in condizioni reali, attivarsi più di una volta per lo stesso evento — Stripe ritenta i webhook in caso di timeout, Typeform può inviare due volte con una connessione lenta, le automazioni Mailchimp possono riattivarsi se un tag viene rimosso e riaggiunto. Se l’emissione dei tuoi badge non è idempotente, questo si traduce in destinatari che ricevono due volte la stessa credenziale, il che appare poco professionale e genera email di supporto.

La protezione più pulita è un passaggio di ricerca-prima-di-creare: prima del POST a /awards, aggiungi un’azione Search (il «Find Award» di Zapier tramite una richiesta GET, o l’equivalente GET HTTP su Make/n8n) contro i tuoi stessi record dei premi — un semplice Google Sheet o Airtable su cui lo stesso Zap scrive subito dopo un premio riuscito va benissimo per questo, se non vuoi interrogare l’API per farlo. Se esiste già un record per quella combinazione destinatario + badge, deviare verso un no-op invece di emettere di nuovo. È un’aggiunta di cinque minuti, ed è la differenza tra un’automazione di cui ti fidi senza sorveglianza e una che devi tenere d’occhio costantemente.

Quando il no-code non basta

Queste ricette coprono bene i trigger a singolo evento. Quando inizi a emettere centinaia di badge da un unico export CSV — una coorte che si laurea, un elenco di partecipanti a una conferenza, un rinnovo massivo di crediti CE — lascia perdere la piattaforma di automazione e usa il caricamento massivo dei badge direttamente: si mette in pausa e riprende a metà batch e sopravvive alla chiusura di una scheda del browser, cosa che i cicli webhook no-code non gestiscono con grazia su grandi volumi.


Pronto a emettere la tua prima credenziale verificabile? Inizia gratis su badges.ninja — designer visuale, pagina di verifica pubblica, certificato PDF, output Open Badge v2.0. Nessuna carta di credito richiesta.

Nacho Coll

Informazioni sull'autore

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.

Torna al Blog

Articoli correlati