Substituindo os Open Badges nativos do Moodle pelo Badges Ninja (Designer Melhor, Mesma API)

O Moodle emite Open Badges nativamente desde a versão 2.5, e para muitos administradores de curso isso já é motivo suficiente para nunca procurar outra opção. Vem embutido, é gratuito e tecnicamente produz uma credencial compatível com os padrões. Então por que tantos administradores do Moodle acabam frustrados quando chegam à quinquagésima insígnia?

A resposta honesta: o sistema de emblemas do Moodle foi projetado para marcar uma caixinha de conformidade, não para ser um produto de credenciamento. Ele funciona, mas funciona do jeito que uma funcionalidade parafusada em um LMS funciona — funcional, datada e limitada pelas restrições da plataforma em que vive. Se você já tentou fazer um emblema do Moodle parecer algo diferente de um ícone circular de clip-art, ou já viu um formando perguntar “espera, onde eu vejo isso mesmo?”, você já conhece essa lacuna.

Isso não é uma crítica ao Moodle — é um LMS excelente e seu mecanismo de critérios de emblemas (conclusão de curso, conclusão de atividade, concessão manual, participação em coorte) é genuinamente bem pensado para disparar uma credencial. O problema é tudo o que vem depois do gatilho: as ferramentas de design, a experiência do destinatário e a visibilidade do emblema fora da sua instância do Moodle. É exatamente para isso que o badges.ninja foi construído, e você não precisa abrir mão da lógica de conclusão do Moodle para usá-lo — você só aponta o gatilho para um mecanismo de emissão diferente.

Onde os emblemas nativos do Moodle deixam a desejar

O designer é um compositor de imagens baseado em coordenadas, não uma ferramenta de design. O editor de emblemas do Moodle permite escolher uma imagem base, adicionar algumas sobreposições de ícones pré-definidos e ajustar a posição com deslocamentos em pixels. Não há biblioteca de formas, não há sistema de paletas, não há opções de fonte além do que já vem embutido no conjunto de ícones. Se a sua organização tem uma marca — um logotipo, uma paleta de cores, uma linguagem visual específica para suas certificações — o editor do Moodle não consegue expressar isso. A maioria das instituições acaba desenhando a arte do emblema no Photoshop ou no Canva e fazendo upload de um PNG plano, o que anula o propósito de ter um designer embutido.

Os destinatários precisam de login no Moodle para ver seus próprios emblemas. Os emblemas concedidos a um aluno ficam dentro da página de perfil dele no Moodle. Se ele já saiu do curso, esqueceu as credenciais institucionais, ou a instituição já desativou a conta dele, o emblema efetivamente some do lado dele — mesmo que a asserção subjacente ainda possa ser resolvida pelo conector de backpack do Moodle ou pela página pública do emblema. Não existe um lugar dedicado, com marca própria e sempre acessível onde um destinatário possa fazer login apenas com o e-mail e ver todas as credenciais que já conquistou em todos os cursos.

Compartilhar é uma reflexão tardia. O Moodle consegue enviar emblemas para um serviço compatível com o Mozilla Backpack, e expõe uma URL de verificação pública para cada emblema, mas não existe um fluxo integrado de “Adicionar ao LinkedIn”, nem um botão de compartilhamento com um clique, nem análise de engajamento sobre se alguém realmente olhou o emblema depois de emitido. Para programas que querem que o emblema funcione como marketing boca a boca — bootcamps, provedores de educação continuada, treinamento corporativo — isso é um custo de oportunidade real.

As operações em massa são desajeitadas. Conceder um emblema para uma turma inteira funciona se todo mundo completa a atividade que dispara o emblema dentro do Moodle ao mesmo tempo. Mas se você precisa emitir retroativamente emblemas para uma turma passada, importar conclusões históricas de uma planilha, ou emitir um emblema para algo que aconteceu totalmente fora do LMS, você acaba escrevendo SQL direto no banco de dados do Moodle ou brigando com ferramentas de importação de CSV que não foram feitas especificamente para emblemas.

O padrão de substituição: mantenha os gatilhos do Moodle, mude o emissor

Você não precisa migrar para fora do Moodle para resolver isso. O padrão mais limpo é deixar o Moodle continuar fazendo o que ele faz bem — rastrear conclusão de curso, conclusão de atividade, participação em coorte — e fazer com que ele chame a API do Badges Ninja no momento em que uma condição de conclusão é disparada, em vez de (ou junto com) conceder seu emblema nativo.

O Moodle oferece suporte a isso de algumas formas:

1. Webhook de conclusão de curso / polling do Moodle Web Services (REST). A API core_completion do Moodle expõe o estado de conclusão por usuário e por curso. Uma tarefa agendada leve (uma tarefa cron agendada do Moodle, ou um job de cron externo que consulta a API REST do Moodle) pode fazer polling em busca de matrículas recém-concluídas e, para cada uma, chamar o endpoint de concessão do Badges Ninja.

2. Um hook de plugin local. Se você tem um desenvolvedor na equipe, o sistema de eventos do Moodle (\core\event\course_completed) pode ser observado por um pequeno plugin local que dispara uma requisição HTTP no instante em que a conclusão acontece — sem atraso de polling.

3. Zapier/Make/n8n como cola, se você preferir evitar mexer no código do Moodle — o Moodle pode enviar eventos de conclusão para um receptor de webhook que uma ferramenta de automação no-code transforma em uma chamada de concessão.

Aqui está a chamada real de concessão, depois que você tem o nome e o e-mail de um usuário que concluiu:

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_moodle_course_completion",
    "recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
    "issuedOn": "2026-08-31"
  }'

Ou em Node, dentro de qualquer tarefa agendada ou receptor de webhook que você estiver rodando:

const response = await fetch("https://api.badges.ninja/awards", {
  method: "POST",
  headers: {
    "X-Api-Key": process.env.BADGES_NINJA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    badgeId: "badge_moodle_course_completion",
    recipient: { name: completedUser.fullname, email: completedUser.email },
    issuedOn: Date.now(),
  }),
});
const award = await response.json();

O e-mail do destinatário recebe hash SHA-256 em repouso, a concessão ganha automaticamente uma URL de verificação única, um QR code e um certificado em PDF A4, e — criticamente — o destinatário pode reivindicá-la por meio de um login com link mágico em badges.ninja/me, sem precisar de uma conta separada no Moodle. Veja o formato completo de requisição/resposta na referência da API de awards e no guia de autenticação para entender como as chaves de API funcionam de ponta a ponta.

Se você preferir fazer isso em lote — digamos, preenchendo retroativamente as conclusões de um semestre inteiro de uma vez, em vez de configurar eventos em tempo real — exporte as conclusões do Moodle como CSV e use o fluxo de concessão em massa diretamente, que suporta pausar/retomar para arquivos grandes. Isso é abordado em detalhes em como emitir Open Badges a partir de um CSV.

Desenhando o próprio emblema

Com a parte técnica pronta, o design do emblema em si leva minutos, não um chamado para o seu time de web. O designer visual oferece mais de 80 templates de forma, um sistema real de paleta de cores, bibliotecas de ícones e upload de fontes personalizadas — para que um emblema de “Estatística Avançada — Concluído” realmente pareça pertencer à marca da sua instituição, em vez de um ícone genérico de conquista do Moodle.

Cada chave de API tem escopo definido e pode ser revogada no mesmo painel onde você gerencia emblemas e emissores, então entregar a credencial de integração para um desenvolvedor (ou uma ferramenta de automação como o Zapier) não significa compartilhar o login da sua conta principal.

Lado a lado: experiência do destinatário

O Moodle ainda ganha em uma coisa: se o único requisito é “o emblema existe, é tecnicamente compatível com o Open Badge v2.0 e vive dentro do LMS que o aluno já usa”, os emblemas nativos não custam nada extra e não exigem trabalho de integração. A desvantagem aparece no momento em que você se importa com a qualidade do design, a portabilidade depois que o curso termina, ou transformar a emissão em um sinal de recrutamento/marketing — o que é a maioria das instituições, eventualmente.

Para uma visão mais ampla de como outras plataformas de Open Badges se comparam em preço e recursos, veja a comparação da plataforma de Open Badges mais barata. E se a sua instituição está avaliando o Open Badge v2.0 em relação à especificação mais nova de credenciais verificáveis, Open Badge v2 vs v3 explicado cobre qual delas realmente vale a pena lançar hoje.

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