Automatize Open Badges com Zapier, Make e n8n (receitas sem código)

Dispare a emissão de badges 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 levam menos de 10 minutos cada uma.

Nacho Coll Por Atualizado 11 min de leitura
Dispare a emissão de badges 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 levam menos de 10 minutos cada uma.

Se você conduz um programa de treinamento, um curso pago ou uma lista de e-mail com níveis, o momento em que alguém termina, compra ou se qualifica geralmente já está registrado em algum lugar — uma resposta de formulário, uma cobrança no Stripe, uma tag no Mailchimp. O emblema deveria ser emitido automaticamente a partir desse evento. Isso raramente acontece, porque “emitir uma credencial” não é uma ação nativa na maioria das ferramentas, e criar um receptor de webhook personalizado para uma automação pontual é um exagero.

É exatamente para isso que existem o Zapier, o Make e o n8n. Os três conseguem chamar a API do Badges Ninja diretamente — sem plugin, sem servidor intermediário, sem deploy de código. Abaixo estão três receitas prontas que você pode copiar hoje, além do tratamento de chaves de API e do comportamento de retentativas de erro que você precisa acertar para que os emblemas não deixem de ser emitidos silenciosamente.

O que você vai conectar

Toda receita segue a mesma estrutura: gatilho → (opcional) busca do destinatário → HTTP POST para /awards. O endpoint /awards é o que realmente emite um emblema para um destinatário — você aponta para um badgeId existente e ele cria um award único e verificável, com sua própria URL de verificação, código QR e certificado em PDF. Veja o guia rápido da API se você ainda não criou um emblema; você vai precisar do ID dele antes que qualquer uma dessas automações possa rodar.

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

Crie a chave de API primeiro

API Keys — estado vazio

Desde o seu painel, abra Settings → API Keys, clique em Create Key e dê a ela um nome que combine com sua função — zapier-course-completions, e não key1. Esse nome importa mais do que parece: se uma automação começar a falhar daqui a seis meses, você vai querer revogar aquela chave sem quebrar três outras integrações que a compartilham.

Criar chave — formulário de nome

A chave é exibida uma única vez, por completo, logo após a criação. Copie-a imediatamente para o armazenamento seguro de credenciais da sua plataforma de automação — a “Connection” do Zapier, a “Connection” do Make, ou uma credential do n8n — nunca em 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 “Eu concluí isso” (ou você envia um formulário como etapa final de uma trilha no próprio ritmo).

No Zapier:

  1. Gatilho: Typeform — New Entry, restrito ao seu 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_<sua chave>, Content-Type: application/json
  5. Data (mapeando a partir dos campos do Typeform):
{
  "badgeId": "bdg_9f2a1c",
  "recipient": {
    "name": "{{typeform_name}}",
    "email": "{{typeform_email}}"
  },
  "issuedOn": "2026-08-27"
}

Isso é tudo o que o Zap precisa. Não é necessária uma etapa de filtro se o formulário só dispara em conclusões reais — se for um formulário de contato geral, adicione uma etapa de Filter by Zapier verificando um campo oculto ou um valor de resposta antes de o webhook disparar, para não emitir emblemas a partir de spam ou envios de teste.

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

Caso de uso: uma prova de certificação paga, um nível premium de curso, ou um plano de associação em que o emblema faz parte do que as pessoas estão comprando.

No Zapier:

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

A parte boa de vincular a emissão a um evento de pagamento é que isso fica naturalmente quase idempotente. Os IDs de cobrança do Stripe são únicos, então, se você se preocupa com um Zap disparando de novo por causa de um webhook reenviado, adicione uma etapa de Storage by Zapier que verifique se aquele ID de cobrança já foi processado antes de chamar /awards.

Receita 3: tag do Mailchimp → Badges Ninja

Caso de uso: você marca assinantes manualmente (ou por meio de outra automação) quando eles atingem um marco — participaram de um webinar, terminaram uma sequência de e-mails, indicaram três pessoas — e quer que essa tag dispare um emblema sem você precisar 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: mapeie subscriber.email_address e subscriber.merge_fields.FNAME + LNAME para os campos do destinatário.

Esse padrão é popular em programas de reconhecimento — incentivos de vendas, marcos da comunidade, presença em eventos — nos quais alguém da equipe já tem o hábito de marcar contatos, e você só quer que o emblema saia desse hábito de graça.

Lidando com erros e novas tentativas

As plataformas de automação não são transacionais em relação aos dados dos seus emblemas, então aplique a mesma disciplina que você exigiria de uma integração de verdade:

  • Verifique o código de resposta. Um 200 significa que o award foi criado; um 4xx geralmente indica um badgeId inválido ou um e-mail malformado — isso é um bug de configuração no Zap, não algo para tentar de novo sem pensar. Um 5xx é seguro para tentar novamente.
  • Zapier: execuções de Zap com falha aparecem no Zap History com a requisição e a resposta completas. Ative o Auto-Replay para falhas transitórias, mas configure um alerta por e-mail/Slack para falhas repetidas, para que um Zap quebrado silenciosamente não signifique três meses de emblemas faltando.
  • Make: os scenarios têm uma rota nativa de Error Handler — anexe uma diretiva Resume ou Rollback ao módulo HTTP, e direcione falhas persistentes a um módulo de notificação em vez de simplesmente descartá-las.
  • n8n: como é self-hosted ou na nuvem com controle mais granular, envolva o node HTTP Request em um workflow de Error Trigger, e considere gravar os payloads com falha em um armazenamento leve de fallback (Airtable, Google Sheets) que você possa reprocessar manualmente.

Nos três casos, evite cair na armadilha de “rodou verde, então funcionou”. Uma resposta com aparência de 200 vinda de uma etapa de webhook mal configurada (URL errada, header faltando) ainda pode falhar do lado do Badges Ninja. Confira manualmente a lista de awards do painel toda semana durante o primeiro mês de qualquer automação nova.

O equivalente no Make.com

O criador visual de scenarios do Make se equivale quase diretamente às etapas do Zapier acima:

  1. Trigger module — módulo de observação do Typeform / Stripe / Mailchimp, igual ao 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), body 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 checagem de “conclusão real” no Typeform.

A vantagem do Make aqui é a visibilidade — o editor de scenarios mostra o payload JSON real em cada etapa antes de você ativar, o que torna a depuração de um mapeamento de campo errado bem mais rápida do que a visão de teste passo a passo, mais linear, do Zapier.

O equivalente no n8n

O n8n é a melhor opção se você quiser isso self-hosted, ou se já estiver automatizando outras partes do seu 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 sua X-Api-Key armazenada como uma credential do n8n (não fixada no node), body JSON construído a partir de uma expressão que referencia a saída do node de gatilho.
  3. IF node (opcional) — a mesma checagem de conclusão/valor de cima, colocada antes do node HTTP Request.

Como as credentials do n8n são criptografadas e reutilizáveis entre workflows, essa é a opção mais limpa se você planeja mais de uma automação do Badges Ninja — configure a credential uma vez e reutilize em todo workflow que precisar emitir emblemas.

Por que usar uma etapa de webhook genérica em vez de um app nativo

Zapier, Make e n8n têm marketplaces de apps, e o instinto é procurar um app “Badges Ninja” antes de recorrer a um módulo genérico de HTTP/webhook. Pule essa busca — para uma API REST tão pequena quanto essa (criar um emissor, criar um emblema, criar um award, pronto), uma etapa de webhook genérica te deixa no ar em dez minutos, sem nenhuma dependência de um mantenedor de app terceiro acompanhando o ritmo das mudanças da API. Um app dedicado adiciona uma camada de abstração que você não precisa: você continuaria preenchendo os mesmos campos badgeId, recipient.email e recipient.name, só que por um formulário em vez de um body JSON. A referência da API é curta o suficiente para ler em cinco minutos, e depois de fazer isso, a abordagem de HTTP direto é, na verdade, menos frágil — não existe nenhum ciclo de aprovação de app store entre uma mudança na API do Badges Ninja e sua automação voltar a funcionar.

Teste antes de colocar no ar

Cada plataforma acima te dá uma forma de rodar uma única execução de teste sem esperar por um evento de gatilho real:

  • Zapier — use “Test” na etapa do gatilho para trazer um registro de exemplo, depois “Test” na ação do webhook para disparar exatamente uma requisição real. Confira se o award aparece no seu painel antes de ativar o Zap.
  • Make — rode o scenario manualmente uma vez (botão “Run once”) com um bundle de exemplo, e inspecione a bolha de saída do módulo HTTP para ver o body real da resposta.
  • n8n — use “Execute Node” no node HTTP Request com dados de teste, o que permite ver a requisição e a resposta direto no editor.

Duas coisas valem a pena conferir nessa primeira execução de teste: se o badgeId fixado realmente pertence ao emblema que você pensa que é (um ID desatualizado de um Zap duplicado é um erro comum), e se o campo de e-mail do destinatário está pegando um endereço real, e não um placeholder como {{email}} deixado sem resolver por um erro de digitação no mapeamento. Os dois erros são invisíveis no indicador de “sucesso” da plataforma de automação — a chamada HTTP continua retornando 200 de qualquer jeito — então a única checagem confiável é abrir o award no seu painel e confirmar que o destinatário é quem você espera.

Evitando emblemas duplicados

Toda fonte de gatilho acima pode, em condições reais, disparar mais de uma vez para o mesmo evento — o Stripe reenvia webhooks em caso de timeout, o Typeform pode enviar duas vezes em uma conexão lenta, automações do Mailchimp podem disparar de novo se uma tag for removida e adicionada de volta. Se a emissão do seu emblema não for idempotente, isso vira destinatários recebendo a mesma credencial duas vezes, o que parece descuidado e gera e-mails de suporte.

A proteção mais limpa é uma etapa de busca antes de criar: antes do POST para /awards, adicione uma ação de Search (o “Find Award” do Zapier via uma requisição GET, ou o GET de HTTP equivalente no Make/n8n) contra seus próprios registros de awards — uma planilha do Google leve ou um log no Airtable, no qual o próprio Zap grava logo depois de um award bem-sucedido, funciona bem para isso se você não quiser consultar a API. Se já existir um registro para aquela combinação de destinatário + emblema, direcione para um no-op em vez de emitir de novo. Isso é um acréscimo de cinco minutos, e é a diferença entre uma automação em que você confia sem supervisão e uma que você precisa ficar vigiando.

Quando o no-code não é suficiente

Essas receitas cobrem bem gatilhos de evento único. Quando você estiver emitindo centenas de emblemas a partir de uma única exportação CSV — uma turma se formando, uma lista de participantes de uma conferência, uma renovação em massa de créditos de educação continuada — deixe de lado a plataforma de automação e use o upload em massa de emblemas diretamente: ele pausa e retoma no meio do lote e sobrevive a uma aba do navegador fechada, algo que os loops de webhook sem código não lidam bem em volume.


Pronto para emitir sua primeira credencial verificável? Comece 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