Automatiza os Open Badges com o Zapier, o Make e o n8n (receitas sem código)

Dispara a emissão de emblemas a partir da conclusão de um Typeform, de uma compra no Stripe ou de uma tag no Mailchimp — três receitas sem código que funcionam e demoram menos de 10 minutos cada uma.

Nacho Coll Por Atualizado 11 min de leitura
Dispara a emissão de emblemas a partir da conclusão de um Typeform, de uma compra no Stripe ou de uma tag no Mailchimp — três receitas sem código que funcionam e demoram menos de 10 minutos cada uma.

Se estás a gerir um programa de formação, um curso pago ou uma lista de e-mail com níveis, o momento em que alguém termina, compra ou se qualifica já costuma estar registado nalgum lado — uma resposta a um formulário, uma cobrança no Stripe, uma tag no Mailchimp. O emblema devia ser emitido automaticamente a partir desse evento. Raramente acontece assim, porque “emitir uma credencial” não é uma ação nativa na maioria das ferramentas, e construir um recetor de webhook personalizado para uma automação pontual é um exagero.

É exatamente para isto que existem o Zapier, o Make e o n8n. Os três conseguem chamar a API do Badges Ninja diretamente — sem plugin, sem servidor intermédio, sem deploy de código. Abaixo estão três receitas que podes copiar hoje mesmo, além da gestão de chaves de API e do comportamento de novas tentativas em caso de erro que precisas de acertar para que os emblemas não deixem de ser emitidos em silêncio.

O que vais ligar

Cada receita segue a mesma estrutura: gatilho → (opcional) procura do destinatário → HTTP POST para /awards. O endpoint /awards é o que realmente emite um emblema a um destinatário — apontas para um badgeId existente e ele cria um award único e verificável, com o seu próprio URL de verificação, código QR e certificado em PDF. Consulta o guia rápido da API se ainda não tiveres criado um emblema; vais precisar do ID antes de qualquer uma destas automações poder funcionar.

A autenticação é a mesma nas três plataformas: um header X-Api-Key com uma chave gerada a partir do teu painel. As plataformas de automação não lidam bem com fluxos OAuth para APIs REST genéricas, por isso as chaves de API são a escolha certa aqui — de longa duração, restritas à tua conta e revogáveis com um clique se algum Zap se comportar mal.

Cria primeiro a chave de API

API Keys — estado vazio

No teu painel, abre Settings → API Keys, clica em Create Key e dá-lhe um nome que corresponda à sua função — zapier-course-completions, e não key1. Esse nome importa mais do que parece: se, daqui a seis meses, uma automação começar a falhar, vais querer revogar essa chave sem quebrar outras três integrações que a partilham.

Criar chave — formulário de nome

A chave é mostrada uma única vez, na íntegra, logo após a criação. Copia-a de imediato para o armazenamento seguro de credenciais da tua plataforma de automação — a “Connection” do Zapier, a “Connection” do Make, ou uma credential do n8n — nunca para um campo de texto simples dentro do próprio Zap/scenario/workflow.

Receita 1: Typeform → Badges Ninja (formulário de conclusão de turma)

Caso de uso: uma turma termina um curso e preenche um formulário curto de “Concluí isto” (ou envias um formulário como último passo de um percurso ao próprio ritmo).

No Zapier:

  1. Gatilho: Typeform — New Entry, restrito ao teu formulário de conclusão.
  2. Ação: Webhooks by Zapier — POST.
  3. URL: https://api.badges.ninja/awards
  4. Headers: X-Api-Key: bws_<a tua chave>, Content-Type: application/json
  5. Data (a mapear a partir dos campos do Typeform):
{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

É só isto o Zap. Não é preciso um passo de filtro se o formulário só dispara em conclusões reais — se for um formulário de contacto genérico, adiciona um passo de Filter by Zapier a verificar um campo oculto ou um valor de resposta antes de o webhook disparar, para não emitires emblemas a partir de spam ou de envios de teste.

Receita 2: Stripe → Badges Ninja (compra = credencial)

Caso de uso: um exame de certificação pago, um nível premium de um curso, ou um plano de subscrição em que o emblema faz parte do que as pessoas estão a comprar.

No Zapier:

  1. Gatilho: Stripe — New Charge (ou New Invoice Payment Succeeded para subscrições).
  2. Filtro: o valor da cobrança é igual ao preço exato do produto credenciado — isto importa se a tua conta Stripe processa vários produtos através de um único webhook.
  3. Ação: Webhooks by Zapier — POST para https://api.badges.ninja/awards, com os mesmos headers de cima.
  4. Data: mapeia charge.billing_details.email e charge.billing_details.name para recipient.email / recipient.name.

A parte boa de ligar a emissão a um evento de pagamento é que isso fica naturalmente quase idempotente. Os IDs de cobrança do Stripe são únicos, por isso, se estiveres preocupado com um Zap a disparar de novo por causa de um webhook reenviado, adiciona um passo de Storage by Zapier que verifique se esse ID de cobrança já foi processado antes de chamar /awards.

Receita 3: tag do Mailchimp → Badges Ninja

Caso de uso: marcas subscritores manualmente (ou através de outra automação) quando atingem um marco — assistiram a um webinar, terminaram uma sequência de e-mails, indicaram três pessoas — e queres que essa tag dispare um emblema sem teres de mexer na API.

No Zapier:

  1. Gatilho: Mailchimp — New Tag Added to Subscriber, filtrado para a tag específica (por exemplo, webinar-attended).
  2. Ação: Webhooks by Zapier — POST para https://api.badges.ninja/awards.
  3. Data: mapeia subscriber.email_address e subscriber.merge_fields.FNAME + LNAME para os campos do destinatário.

Este padrão é popular em programas de reconhecimento — incentivos de vendas, marcos de comunidade, presença em eventos — em que alguém da equipa já tem o hábito de marcar contactos, e só queres que o emblema surja desse hábito sem esforço extra.

Como lidar com erros e novas tentativas

As plataformas de automação não são transacionais em relação aos dados dos teus emblemas, por isso aplica a mesma disciplina que exigirias de uma integração a sério:

  • Verifica o código de resposta. Um 200 significa que o award foi criado; um 4xx normalmente indica um badgeId inválido ou um e-mail mal formado — isso é um erro de configuração no Zap, não algo para tentares de novo às cegas. Um 5xx já é seguro repetir.
  • Zapier: as execuções de Zap falhadas aparecem no Zap History com o pedido e a resposta completos. Ativa o Auto-Replay para falhas transitórias, mas configura um alerta por e-mail/Slack para falhas repetidas, para que um Zap avariado em silêncio não signifique três meses de emblemas em falta.
  • Make: os scenarios têm uma rota nativa de Error Handler — associa uma diretiva Resume ou Rollback ao módulo HTTP, e encaminha as falhas persistentes para um módulo de notificação em vez de simplesmente as descartares.
  • n8n: como é self-hosted ou na cloud com controlo mais granular, envolve o node HTTP Request num workflow de Error Trigger, e considera guardar os payloads falhados num armazenamento leve de reserva (Airtable, Google Sheets) que possas reprocessar manualmente.

Nos três casos, evita cair na armadilha do “correu tudo verde, logo funcionou”. Uma resposta com o aspeto de um 200, vinda de um passo de webhook mal configurado (URL errado, header em falta), pode continuar a falhar do lado do Badges Ninja. Verifica manualmente a lista de awards do painel todas as semanas durante o primeiro mês de qualquer automação nova.

O equivalente no Make.com

O criador visual de scenarios do Make corresponde quase diretamente aos passos do Zapier acima:

  1. Trigger module — módulo de observação do Typeform / Stripe / Mailchimp, tal como o gatilho do Zapier.
  2. HTTP → Make a Request module — Method POST, URL https://api.badges.ninja/awards, headers definidos na tabela Headers (X-Api-Key, Content-Type: application/json), corpo como JSON puro com variáveis mapeadas a partir do gatilho.
  3. Filter opcional entre módulos para a verificação do valor no Stripe ou a validação de “conclusão real” no Typeform.

A vantagem do Make aqui é a visibilidade — o editor de scenarios mostra-te o payload JSON real em cada passo antes de o ativares, o que torna a depuração de um mapeamento de campo errado muito mais rápida do que a vista de teste passo a passo, mais linear, do Zapier.

O equivalente no n8n

O n8n é a melhor opção se quiseres isto self-hosted, ou se já estiveres a automatizar outras partes do teu stack por lá:

  1. Trigger node — Typeform Trigger / Stripe Trigger / Mailchimp Trigger (todos nodes nativos).
  2. HTTP Request node — Method POST, URL https://api.badges.ninja/awards, autenticação definida como Header Auth com a tua X-Api-Key guardada como uma credential do n8n (não fixada diretamente no node), corpo JSON construído a partir de uma expressão que referencia a saída do node de gatilho.
  3. IF node (opcional) — a mesma validação de conclusão/valor de cima, colocada antes do node HTTP Request.

Como as credentials do n8n estão encriptadas e são reutilizáveis entre workflows, esta é a opção mais limpa se estiveres a planear mais do que uma automação do Badges Ninja — configura a credential uma vez e reutiliza-a em todos os workflows que precisem de emitir emblemas.

Porquê um passo de webhook genérico em vez de uma app nativa

O Zapier, o Make e o n8n têm todos marketplaces de apps, e o instinto é procurar uma app “Badges Ninja” antes de recorrer a um módulo genérico de HTTP/webhook. Salta essa procura — para uma API REST tão pequena como esta (criar um emissor, criar um emblema, criar um award, pronto), um passo de webhook genérico deixa-te operacional em dez minutos, sem qualquer dependência de um responsável por uma app de terceiros acompanhar o ritmo das alterações da API. Uma app dedicada acrescenta uma camada de abstração de que não precisas: continuarias a preencher os mesmos campos badgeId, recipient.email e recipient.name, só que através de um formulário em vez de um corpo JSON. A referência da API é suficientemente curta para leres em cinco minutos, e depois de o fazeres, a abordagem de HTTP direto é, na verdade, menos frágil — não há nenhum ciclo de aprovação de loja de apps entre uma alteração na API do Badges Ninja e a tua automação voltar a funcionar.

Testa antes de colocares em produção

Todas as plataformas acima dão-te uma forma de correr uma única execução de teste sem esperares por um evento de gatilho real:

  • Zapier — usa “Test” no passo do gatilho para trazer um registo de amostra, depois “Test” na ação do webhook para disparares exatamente um pedido real. Verifica se o award aparece no teu painel antes de ativares o Zap.
  • Make — corre o scenario manualmente uma vez (botão “Run once”) com um bundle de amostra, e inspeciona a bolha de saída do módulo HTTP para veres o corpo real da resposta.
  • n8n — usa “Execute Node” no node HTTP Request com dados de teste, o que te permite ver o pedido e a resposta diretamente no editor.

Há duas coisas que vale a pena verificar nessa primeira execução de teste: se o badgeId que fixaste pertence mesmo ao emblema que pensas que é (um ID desatualizado de um Zap duplicado é um erro comum), e se o campo do e-mail do destinatário está a receber um endereço real e não um placeholder como {{email}} que ficou por resolver por causa de um erro de mapeamento. Os dois erros são invisíveis no indicador de “sucesso” da plataforma de automação — a chamada HTTP continua a devolver 200 de qualquer forma — por isso, a única verificação fiável é abrir o award no teu painel e confirmar que o destinatário é quem esperas.

Como evitar emblemas duplicados

Qualquer uma das fontes de gatilho acima pode, em condições reais, disparar mais do que uma vez para o mesmo evento — o Stripe reenvia webhooks em caso de timeout, o Typeform pode submeter em duplicado numa ligação lenta, as automações do Mailchimp podem voltar a disparar se uma tag for removida e readicionada. Se a emissão do teu emblema não for idempotente, isso traduz-se em destinatários a receberem a mesma credencial duas vezes, o que parece pouco cuidado e gera e-mails de suporte.

A proteção mais limpa é um passo de procura antes de criar: antes do POST para /awards, adiciona uma ação de Search (o “Find Award” do Zapier através de um pedido GET, ou o GET de HTTP equivalente no Make/n8n) contra os teus próprios registos de awards — uma folha de cálculo do Google ou um registo no Airtable leves, em que o próprio Zap escreve logo a seguir a um award bem-sucedido, funcionam bem para isto se não quiseres consultar a API. Se já existir um registo para essa combinação de destinatário + emblema, encaminha para um no-op em vez de emitir de novo. Isto é um acrescento de cinco minutos, e é a diferença entre uma automação em que confias sem vigilância e uma de que tens de andar a cuidar.

Quando o no-code não chega

Estas receitas cobrem bem os gatilhos de evento único. A partir do momento em que estiveres a emitir centenas de emblemas a partir de uma única exportação CSV — uma turma a formar-se, uma lista de participantes de uma conferência, uma renovação em massa de créditos de formação contínua — deixa de lado a plataforma de automação e usa diretamente o carregamento em massa de emblemas: pausa e retoma a meio do lote e sobrevive a um separador do browser fechado, algo que os ciclos de webhook sem código não gerem bem em volume.


Pronto para emitir a tua primeira credencial verificável? Começa grátis em badges.ninja — designer visual, página pública de verificação, certificado em PDF, saída em Open Badge v2.0. Não é necessário cartão de crédito.

Nacho Coll

Sobre o 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.

Voltar ao Blog

Artigos Relacionados