DEV Community: Nacho Coll

Verifieerbare digitale badges uitgeven met BADGES.ninja: Nederlandse gids voor developers en e-learning platforms

Nacho Coll — Mon, 27 Apr 2026 17:44:29 +0000

De Nederlandse en Vlaamse markt voor online onderwijs en micro-credentials groeit snel. Platforms zoals Codaisseur, Winc Academy, NCOI, LOI, Coursera, Udemy en talloze aanbieders van beroepsopleidingen certificeren elk jaar duizenden lerenden — maar veel aanbieders sturen nog altijd een simpele PDF als bewijs van deelname.

Een PDF is niet verifieerbaar, integreert slecht met LinkedIn, en overleeft zelden een wisseling van provider. BADGES.ninja is een platform voor digitale certificaten volgens de Open Badge v2.0-standaard dat precies dit probleem oplost — beschikbaar in het Nederlands en meer dan 30 andere talen.

In deze gids laat ik zien hoe je certificaten uitgeeft via REST API, bulk-uitgifte via CSV integreert, en welke functies ik bijzonder interessant vind voor Nederlandstalige opleidingsaanbieders.

Waarom Open Badge v2.0?

Open Badge v2.0 is de open standaard van IMS Global voor interoperabele digitale certificaten. In tegenstelling tot een PDF bevat elke Open Badge machine-leesbare metadata (uitgever, ontvanger, criteria, uitgiftedatum, vervaldatum, bewijs) en een hosting-URL waarmee elke derde partij het certificaat kan verifiëren. Het werkt precies als een webstandaard: een verifieerbaar JSON-document met ingebedde PNG- of SVG-grafiek.

Het belangrijkste verschil: wanneer iemand de echtheid van een certificaat wil controleren, vraagt hij niet aan de ontvanger, maar aan de uitgever — cryptografisch.

De REST API in de praktijk

BADGES.ninja biedt een volledige REST API met X-Api-Key-authenticatie — ook in het gratis plan. Dat is een duidelijk verschil met de meeste concurrenten, die programmatische toegang reserveren voor enterprise-tarieven.

Voorbeeld: een nieuwe uitgever (Issuer) aanmaken:

curl -X POST https://api.badges.ninja/issuers \
  -H "X-Api-Key: bws_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "name": "Mijn Academie",
      "url": "https://example.com",
      "email": "admin@example.com"
    }
  }'

Antwoord:

{
  "statusCode": 200,
  "info": {
    "issuerId": "https://api.badges.ninja/certify-badge/issuer/abc123-def456"
  }
}

De issuerId is een permanente URL waarnaar verwezen wordt in de JSON-LD-context van het Open Badge-document. Net zo eenvoudig: een badge maken, een award (certificaat) uitgeven, een ontvanger op de hoogte stellen — alles via één enkele REST-endpoint.

Bulk-uitgifte via CSV

Wie ooit heeft geprobeerd om certificaten voor 2.000 bootcampafstudeerders één voor één uit te geven, kent het probleem. De /awards/bulk-functie van BADGES.ninja accepteert een CSV-bestand met ontvangergegevens en regelt de rest:

automatische retry bij fouten
pauzeren/hervatten bij onderbreking
e-mailmelding met individuele certificaatlink
status-webhook voor elk uitgegeven badge

Precies het soort engineering-detail dat je waardeert wanneer het proces halverwege een verzending vastloopt.

IPFS-opslag: permanentie voor de afbeeldingen

Een digitaal certificaat zou net zo lang moeten bestaan als een papieren diploma. Het probleem met klassieke oplossingen: badge-afbeeldingen worden gehost op traditionele servers en verdwijnen wanneer het bedrijf sluit of van provider wisselt.

BADGES.ninja slaat de badge-grafieken op in IPFS (gedecentraliseerd opslagsysteem). Zelfs als het platform op een dag wordt opgeheven, blijft de afbeelding via elke IPFS-gateway bereikbaar — via de content hash. Voor een hogeschool, een hbo-instelling of een publieke onderwijsinstelling is dat een belangrijk argument.

Optionele blockchain-verankering

Certificaten uit het Pro-plan kunnen optioneel verankerd worden op een publieke blockchain. Dat voegt een uitgever-onafhankelijke cryptografische verificatielaag toe — nuttig voor gevallen waarin verifieerbaarheid echt belangrijk is: gereguleerde beroepsdiploma's, compliance-certificaten, medische bijscholing, NL Qualifications-trajecten.

Belangrijk: het is optioneel. Veel onderwijsaanbieders hebben de blockchain-laag niet nodig, en dat is helemaal prima.

Ontvangerportaal en LinkedIn-integratie

De waarde van een certificaat hangt af van hoe de ontvanger het gebruikt. BADGES.ninja bevat een wachtwoordloos ontvangerportaal op badges.ninja/me. Elke ontvanger verzamelt daar al zijn certificaten en kan een publiek profiel aanmaken op badges.ninja/u/<alias>.

Daarnaast bevat elke publieke certificaatpagina:

een één-klik-knop "Toevoegen aan LinkedIn-profiel"
een downloadbaar PDF-certificaat
een scanbare QR-code voor papieren CV's
een publieke verificatie-URL

Meertaligheid als onderscheidende factor

Vrijwel alle leidende platforms voor digitale certificaten zijn ontwikkeld in het Engels en vertalen in het beste geval alleen de gebruikersinterface. BADGES.ninja is vanaf het begin meertalig — meer dan 30 talen worden ondersteund, waaronder Nederlands. Zowel uitgever als ontvanger kunnen hun certificaten in hun eigen taal beheren en delen.

Voor een Nederlandse hogeschool, een Vlaamse opleidingsinstelling, een Belgische universiteit of een EdTech-platform in de Benelux is dat geen esthetisch detail meer, maar een echte adoptie-eis.

Gratis plan om te starten

Het gratis plan staat tot 100 uitgiftes per maand toe — genoeg om het formaat te valideren of een kleine tech-community te certificeren, zonder creditcard. Een redelijke standaardlimiet die veel concurrenten niet bieden.

Conclusie

Als jullie cursussen, bootcamps, bedrijfstrainingen, workshops of certificeringstrajecten verzorgen en jullie certificaatuitgifte willen moderniseren, nodig ik jullie uit om BADGES.ninja te proberen op https://badges.ninja. Het gratis plan dekt 100 uitgiftes per maand, zonder creditcard en zonder tijdslimiet.

Vragen, feedback of use cases? Laat het weten in de reacties — ik antwoord graag. 🎓

Emettere certificazioni digitali verificabili con BADGES.ninja: guida in italiano per sviluppatori e piattaforme e-learning

Nacho Coll — Mon, 27 Apr 2026 17:41:35 +0000

Il mercato italiano della formazione online e delle micro-credenziali sta crescendo rapidamente. Piattaforme come Udemy, Coursera, Talent Garden Innovation School, Aulab, Boolean, Edgemony e i numerosi enti di formazione professionale certificano ogni anno migliaia di studenti — ma molti continuano a inviare un semplice PDF come attestato di partecipazione.

Un PDF non è verificabile, non si integra bene con LinkedIn e raramente sopravvive al cambio di provider. BADGES.ninja è una piattaforma per certificazioni digitali secondo lo standard Open Badge v2.0 che risolve esattamente questo problema — disponibile nativamente in italiano e oltre 30 lingue.

In questa guida mostro come emettere certificazioni via REST API, integrare l'emissione di massa via CSV e quali funzionalità trovo particolarmente interessanti per gli enti di formazione italiani.

Perché Open Badge v2.0?

Open Badge v2.0 è lo standard aperto di IMS Global per le certificazioni digitali interoperabili. A differenza di un PDF, ogni Open Badge contiene metadati leggibili dalle macchine (emittente, destinatario, criteri, data di emissione, scadenza, prove) e un URL di hosting tramite cui qualsiasi terza parte può verificare il certificato. Funziona esattamente come uno standard web: un documento JSON verificabile con grafica PNG o SVG incorporata.

La differenza fondamentale: quando qualcuno vuole verificare l'autenticità di una certificazione, non chiede al destinatario, ma all'emittente — crittograficamente.

La REST API in pratica

BADGES.ninja espone una REST API completa con autenticazione X-Api-Key — anche nel piano gratuito. È una differenza significativa rispetto alla maggior parte dei concorrenti, che riservano l'accesso programmatico ai piani enterprise.

Esempio: creare un nuovo emittente (Issuer):

curl -X POST https://api.badges.ninja/issuers \
  -H "X-Api-Key: bws_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "name": "La Mia Accademia",
      "url": "https://example.com",
      "email": "admin@example.com"
    }
  }'

Risposta:

{
  "statusCode": 200,
  "info": {
    "issuerId": "https://api.badges.ninja/certify-badge/issuer/abc123-def456"
  }
}

L'issuerId è un URL permanente referenziato nel contesto JSON-LD del documento Open Badge. Allo stesso modo: creare un badge, emettere un award (certificazione), notificare un destinatario — tutto attraverso un singolo endpoint REST.

Emissione di massa via CSV

Chiunque abbia provato a emettere certificazioni per 2.000 studenti uno per uno conosce il problema. La funzione /awards/bulk di BADGES.ninja accetta un file CSV con i dati dei destinatari e gestisce il resto:

ritento automatico in caso di errori
pausa/ripresa in caso di interruzione
notifica email con link individuale al certificato
webhook di stato per ogni badge emesso

Esattamente il tipo di dettaglio ingegneristico che si apprezza quando il processo si interrompe a metà invio.

Archiviazione su IPFS: permanenza per le immagini

Una certificazione digitale dovrebbe durare quanto un diploma cartaceo. Il problema delle soluzioni classiche: le immagini dei badge sono ospitate su server tradizionali e scompaiono quando il provider chiude o cambia.

BADGES.ninja archivia le grafiche dei badge su IPFS (sistema di archiviazione decentralizzato). Anche se la piattaforma un giorno venisse dismessa, l'immagine resta accessibile tramite qualsiasi gateway IPFS — tramite il suo content hash. Per un'università, un ITS Academy o un ente pubblico di formazione, è un argomento di peso.

Ancoraggio blockchain opzionale

Le certificazioni del piano Pro possono essere opzionalmente ancorate su una blockchain pubblica. Questo aggiunge un livello di verifica crittografica indipendente dall'emittente — utile per casi in cui la verificabilità è particolarmente importante: titoli professionali regolamentati, certificazioni di compliance, formazione medica continua, percorsi finanziati da Fondi Interprofessionali.

Importante: è opzionale. Molti enti di formazione non hanno bisogno del livello blockchain, e va benissimo così.

Portale destinatario e integrazione LinkedIn

Il valore di una certificazione dipende da come il destinatario la utilizza. BADGES.ninja include un portale destinatario senza password all'indirizzo badges.ninja/me. Ogni destinatario raccoglie qui tutte le sue certificazioni e può creare un profilo pubblico su badges.ninja/u/<alias>.

Inoltre, ogni pagina pubblica di certificazione include:

un pulsante in un clic "Aggiungi al profilo LinkedIn"
un certificato PDF scaricabile
un QR code scansionabile per CV cartacei
un URL di verifica pubblica

Multilinguismo come fattore differenziante

Praticamente tutte le piattaforme leader per certificazioni digitali sono sviluppate in inglese e, nella migliore delle ipotesi, traducono solo l'interfaccia utente. BADGES.ninja è multilingue dall'origine — supporta oltre 30 lingue, tra cui italiano, spagnolo, francese, tedesco, portoghese e molte altre. Sia l'emittente che il destinatario possono gestire e condividere le certificazioni nella propria lingua.

Per un'accademia italiana, un ITS, un'università svizzera italofona o una piattaforma EdTech del Sud Italia, questo non è un dettaglio estetico ma un vero requisito di adozione.

Piano gratuito per iniziare

Il piano gratuito permette fino a 100 emissioni al mese — sufficiente per validare il formato o certificare una piccola tech community senza carta di credito. Un limite ragionevole che molti concorrenti non offrono.

Conclusione

Se gestite corsi, bootcamp, formazione aziendale, workshop o percorsi certificati e volete modernizzare l'emissione delle certificazioni, vi invito a provare BADGES.ninja su https://badges.ninja. Il piano gratuito copre 100 emissioni al mese, senza carta di credito e senza scadenza temporale.

Domande, feedback o casi d'uso? Lasciate un commento — rispondo volentieri. 🎓

Verifizierbare digitale Zertifikate mit BADGES.ninja ausstellen: deutscher Leitfaden für Entwickler und Bildungsanbieter

Nacho Coll — Mon, 27 Apr 2026 17:39:32 +0000

Der deutsche Markt für Online-Weiterbildung und IHK-Zertifikatslehrgänge wächst stetig. Plattformen wie openHPI, Udemy, die IHK-Akademien, oncampus, OPEN vhb oder die zahlreichen Anbieter beruflicher Fortbildung qualifizieren jedes Jahr Hunderttausende Lernende — doch viele Anbieter verschicken nach wie vor ein einfaches PDF als Teilnahmenachweis.

Ein PDF ist nicht überprüfbar, lässt sich nur schlecht in LinkedIn integrieren und überdauert kaum den nächsten Provider-Wechsel. BADGES.ninja ist eine Plattform für digitale Zertifikate nach dem Open-Badge-v2.0-Standard, die genau dieses Problem löst — und die nativ auf Deutsch (Deutschland und Österreich) zur Verfügung steht.

In diesem Leitfaden zeige ich, wie man Zertifikate per REST-API ausstellt, eine CSV-Massenausstellung integriert und welche Funktionen ich für deutschsprachige Bildungsanbieter besonders interessant finde.

Warum Open Badge v2.0?

Open Badge v2.0 ist der offene Standard von IMS Global für interoperable digitale Zertifikate. Im Gegensatz zu einem PDF enthält jedes Open Badge maschinenlesbare Metadaten (Aussteller, Empfänger, Kriterien, Ausstellungsdatum, Ablauf, Belege) und eine Hosting-URL, über die jeder Drittanbieter das Zertifikat verifizieren kann. Es funktioniert genau wie ein Webstandard: ein verifizierbares JSON-Dokument mit eingebetteter PNG- oder SVG-Grafik.

Der wichtige Unterschied: Wenn jemand die Authentizität eines Zertifikats prüfen will, fragt er nicht den Empfänger, sondern den Aussteller — kryptografisch.

Die REST-API in der Praxis

BADGES.ninja stellt eine vollständige REST-API mit X-Api-Key-Authentifizierung bereit — auch im kostenlosen Plan. Das ist ein deutlicher Unterschied zu den meisten Konkurrenten, die programmatischen Zugriff den Enterprise-Tarifen vorbehalten.

Beispiel: einen neuen Aussteller (Issuer) anlegen:

curl -X POST https://api.badges.ninja/issuers \
  -H "X-Api-Key: bws_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "name": "Meine Akademie",
      "url": "https://example.com",
      "email": "admin@example.com"
    }
  }'

Antwort:

{
  "statusCode": 200,
  "info": {
    "issuerId": "https://api.badges.ninja/certify-badge/issuer/abc123-def456"
  }
}

Die issuerId ist eine permanente URL, die im JSON-LD-Kontext des Open-Badge-Dokuments referenziert wird. Genauso einfach: ein Badge anlegen, ein Award (Zertifikat) ausstellen, einen Empfänger benachrichtigen — alles über einen einzigen REST-Endpunkt.

Massenausstellung per CSV

Wer einmal versucht hat, Zertifikate für 2.000 Bootcamp-Absolventen einzeln auszustellen, kennt das Problem. Die /awards/bulk-Funktion in BADGES.ninja akzeptiert eine CSV-Datei mit Empfängerdaten und übernimmt den Rest:

automatische Wiederholung bei Fehlern
Pause/Wiederaufnahme bei Unterbrechung
E-Mail-Benachrichtigung mit individuellem Zertifikatslink
Status-Webhook für jedes ausgegebene Badge

Genau die Art Engineering-Detail, die man zu schätzen weiß, wenn der Prozess mitten im Versand abbricht.

IPFS-Speicherung: Permanenz für die Bildlinks

Ein digitales Zertifikat sollte so lange bestehen wie ein Papierdiplom. Das Problem klassischer Lösungen: Die Badge-Bilder werden auf herkömmlichen Servern gehostet und verschwinden, sobald der Anbieter geschlossen oder gewechselt wird.

BADGES.ninja speichert die Badge-Grafiken auf IPFS (dezentrales Speichersystem). Selbst wenn die Plattform irgendwann eingestellt würde, bleibt das Bild über jeden IPFS-Gateway abrufbar — über seinen Content-Hash. Für eine Hochschule, eine IHK-Akademie oder eine öffentliche Bildungseinrichtung ein gewichtiges Argument.

Optionale Blockchain-Verankerung

Zertifikate aus dem Pro-Plan können optional auf einer öffentlichen Blockchain verankert werden. Das fügt eine vom Aussteller unabhängige kryptografische Verifizierungsschicht hinzu — sinnvoll für Fälle, in denen Verifizierbarkeit besonders wichtig ist: regulierte Berufsabschlüsse, Compliance-Zertifikate, medizinische Fortbildung, BAFA-geförderte Maßnahmen.

Wichtig: Es ist optional. Viele Bildungsanbieter brauchen die Blockchain-Schicht nicht, und das ist völlig in Ordnung.

Empfängerportal und LinkedIn-Integration

Der Wert eines Zertifikats hängt davon ab, wie der Empfänger es nutzt. BADGES.ninja bringt ein passwortloses Empfängerportal unter badges.ninja/me mit. Jeder Empfänger sammelt dort alle seine Zertifikate und kann ein öffentliches Profil unter badges.ninja/u/<alias> anlegen.

Zusätzlich enthält jede öffentliche Zertifikatsseite:

einen Ein-Klick-Button „Zu LinkedIn-Profil hinzufügen"
ein herunterladbares PDF-Zertifikat
einen scanbaren QR-Code für gedruckte Lebensläufe
eine öffentliche Verifizierungs-URL

Mehrsprachigkeit als Differenzierungsmerkmal

Praktisch alle führenden Plattformen für digitale Zertifikate sind in Englisch entwickelt und übersetzen bestenfalls die Benutzeroberfläche. BADGES.ninja ist von Anfang an mehrsprachig — über 30 Sprachen werden unterstützt, einschließlich Deutsch (Deutschland und Österreich). Sowohl Aussteller als auch Empfänger können ihre Zertifikate in der eigenen Sprache verwalten und teilen.

Für eine deutsche IHK-Akademie, eine österreichische WIFI-Niederlassung, eine Schweizer Fachhochschule oder eine EdTech-Plattform in der DACH-Region ist das kein Detail, sondern eine echte Adoptionsanforderung.

Kostenloser Plan zum Starten

Der kostenlose Plan erlaubt bis zu 100 Ausstellungen pro Monat — genug, um das Format zu validieren oder eine kleine Tech-Community zu zertifizieren, ohne Kreditkarte. Sinnvolle Standardgrenze, die viele Konkurrenten so nicht bieten.

Fazit

Wenn ihr Kurse, Bootcamps, betriebliche Schulungen, Workshops oder IHK-Zertifikatslehrgänge anbietet und eure Zertifikatsausgabe modernisieren möchtet, lade ich euch ein, BADGES.ninja unter https://badges.ninja auszuprobieren. Der kostenlose Plan deckt 100 Ausstellungen pro Monat ab, ohne Kreditkarte und ohne Zeitlimit.

Fragen, Feedback oder Use Cases? Lasst es in den Kommentaren wissen — ich antworte gerne. 🎓

Émettre des badges numériques vérifiables avec BADGES.ninja : guide en français pour développeurs et plateformes e-learning

Nacho Coll — Sat, 25 Apr 2026 19:18:09 +0000

Si vous développez une plateforme de cours en ligne, un LMS, un bootcamp ou tout produit qui délivre des « diplômes » à la fin d'un module, vous êtes probablement en train d'envoyer aujourd'hui un PDF par email. Ça fonctionne, mais ce n'est pas vérifiable, ça s'intègre mal avec LinkedIn, et ça ne résiste pas au temps.

BADGES.ninja est une plateforme de credentials numériques conforme au standard Open Badge v2.0, disponible dans plus de 30 langues — dont le français métropolitain et le français des Amériques — et qui expose une API REST complète dès le plan gratuit. Dans cet article, je passe en revue les 7 fonctionnalités qui comptent vraiment pour un profil technique qui va intégrer l'émission de credentials dans son produit.

1. API REST complète avec `X-Api-Key` sur tous les plans

La différence la plus importante avec Credly ou Accredible : l'API REST est disponible sur le plan gratuit et s'authentifie avec un simple en-tête X-Api-Key. Vous générez une clé depuis le tableau de bord et vous émettez des credentials depuis votre backend en quelques minutes.

curl -X POST https://badges.ninja/api/awards \
  -H "X-Api-Key: $BADGES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "badge_id": "abc123",
    "recipient_email": "alice@exemple.fr",    "recipient_name": "Alice Martin"
  }'

Cela vous permet de valider l'intégration end-to-end avant de prendre une décision d'achat — ce que les plateformes qui réservent l'API au plan entreprise ne permettent pas.

2. Émission en masse par CSV avec pause, reprise et réessai

Quand un bootcamp termine une promotion de 500 personnes, émettre les credentials un par un n'est pas viable. La fonction bulk awards accepte un CSV standard et traite le lot avec trois garanties : vous pouvez mettre en pause, reprendre exactement là où le processus s'est arrêté, et le système réessaye automatiquement les lignes en erreur transitoire. C'est le genre de détail qu'on apprécie quand un upload de 2 000 étudiants tombe au milieu.

3. Stockage permanent sur IPFS

Les images des credentials sont stockées sur IPFS (système de fichiers décentralisé), et non dans un bucket privé du fournisseur. Concrètement, même si BADGES.ninja cessait d'opérer un jour, les CIDs des images resteraient récupérables sur n'importe quelle gateway IPFS publique. Pour une université ou un organisme public qui délivre des titres avec une validité de long terme, c'est un argument fort par rapport à un hébergement centralisé traditionnel.

4. Ancrage blockchain optionnel (plan Pro)

Les credentials du plan Pro peuvent être ancrés sur une blockchain publique de manière optionnelle, ajoutant une couche de vérification cryptographique indépendante de l'émetteur. La page publique de chaque credential affiche le hash on-chain et un bouton de vérification. Ce n'est pas obligatoire — beaucoup de cas n'en ont pas besoin — mais c'est disponible quand le contexte réglementaire l'exige (formation médicale continue, certifications de conformité, titres professionnels réglementés comme ceux du RNCP).

5. Éditeur visuel avec plus de 80 modèles

Toutes les équipes n'ont pas un designer disponible pour créer des badges depuis zéro. L'éditeur de canvas inclut 80+ modèles (8 formes × 8 palettes), des filtres, des polices personnalisables, des icônes et des images personnelles. En 5 minutes vous avez l'identité visuelle d'une collection entière sans ouvrir Figma.

6. Portail du destinataire et bouton « Ajouter à LinkedIn »

Un credential vaut ce qu'on en partage. Chaque destinataire reçoit un accès sans mot de passe à badges.ninja/me, où il regroupe tous ses credentials et peut réclamer un profil public sur badges.ninja/u/<alias>. Chaque page publique de credential inclut :

Un bouton en un clic pour l'ajouter au profil LinkedIn
Un certificat PDF A4 téléchargeable
Un QR code scannable pour les CV imprimés
Une URL publique de vérification

7. Open Badge v2.0 + plan gratuit de 100 credentials/mois

Open Badge v2.0 est le standard d'IMS Global pour les credentials interopérables. N'importe quel credential émis avec BADGES.ninja peut être lu par les backpacks tiers qui suivent ce même standard. Et le plan gratuit permet d'émettre jusqu'à 100 credentials par mois sans carte bancaire — largement assez pour valider l'intégration sur un cours complet avant de passer au Pro.

Le facteur multilingue

Un détail que les plateformes concurrentes mettent rarement en avant : BADGES.ninja est disponible dans plus de 30 langues, regroupées par région (Amériques, Europe, Asie & Pacifique). Pour un organisme de formation français, une université belge, un bootcamp québécois ou une plateforme EdTech au Maghreb, cela signifie que le tableau de bord de l'émetteur et le portail du destinataire fonctionnent dans la langue native de votre public. C'est un point de friction en moins pour l'adoption.

Conclusion

Si vous construisez ou maintenez un produit e-learning en français, BADGES.ninja vaut le coup d'œil avant de choisir une plateforme anglo-saxonne plus chère. La combinaison API REST sur le plan gratuit, IPFS, blockchain optionnelle, émission en masse et support multilingue rend l'intégration rapide et la proposition de valeur côté destinataire solide.

Commencez gratuitement sur 👉 https://badges.ninja — 100 émissions par mois sans carte bancaire.

Emita credenciais digitais verificáveis com BADGES.ninja: guia em português para devs e plataformas EAD

Nacho Coll — Sat, 25 Apr 2026 19:15:43 +0000

Se você desenvolve uma plataforma de cursos online, um LMS, um bootcamp ou qualquer produto que entregue "diplomas" ao final de um módulo, provavelmente está gerando hoje um PDF e enviando por email. Funciona, mas não é verificável, não se integra bem com o LinkedIn e não resiste ao tempo.

BADGES.ninja é uma plataforma de credenciais digitais conforme o padrão Open Badge v2.0 que está disponível em mais de 30 idiomas — incluindo português do Brasil e português de Portugal — e expõe uma REST API completa já no plano gratuito. Neste artigo, passo em revista os 7 recursos que mais pesam para um perfil técnico que vai integrar emissão de credenciais no seu produto.

1. REST API completa com `X-Api-Key` em todos os planos

A diferença mais importante em relação a plataformas como Credly ou Accredible: a API REST está disponível no plano gratuito e se autentica com um simples header X-Api-Key. Você gera uma chave no painel e começa a emitir credenciais a partir do seu backend em minutos.

curl -X POST https://badges.ninja/api/awards \
  -H "X-Api-Key: $BADGES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "badge_id": "abc123",
    "recipient_email": "aluno@exemplo.com",    "recipient_name": "João Silva"
  }'

Isso permite validar a integração end-to-end antes de tomar uma decisão de compra, algo que plataformas com API somente no plano enterprise não permitem.

2. Emissão em massa por CSV com pausa, retomada e nova tentativa

Quando um bootcamp encerra uma turma com 500 alunos, emitir uma credencial por vez não é viável. O recurso de bulk awards aceita um CSV padrão e processa o lote com três garantias: você pode pausar, retomar exatamente de onde parou e o sistema tenta novamente automaticamente as linhas que tiveram erro transitório. É o tipo de detalhe que só se nota quando um upload de 2.000 alunos cai pela metade.

3. Armazenamento permanente em IPFS

As imagens das credenciais são armazenadas em IPFS (sistema de arquivos descentralizado), não em um bucket privado do fornecedor. Isso significa que mesmo se a BADGES.ninja deixasse de operar algum dia, os CIDs das imagens continuariam recuperáveis em qualquer gateway IPFS público. Para uma universidade ou um órgão público que emite títulos com validade de longo prazo, isso é um argumento forte frente a hospedagens centralizadas tradicionais.

4. Ancoragem opcional em blockchain (plano Pro)

As credenciais do plano Pro podem ser ancoradas em uma blockchain pública de forma opcional, adicionando uma camada de verificação criptográfica independente do emissor. A página pública de cada credencial mostra o hash on-chain e um botão de verificação. Não é obrigatório ativar — muitos casos não precisam — mas está disponível quando o contexto regulatório exige (formação médica continuada, certificações de compliance, títulos profissionais regulamentados).

5. Editor visual com mais de 80 templates

Nem todo time tem um designer disponível para criar insígnias do zero. O editor de canvas inclui 80+ templates (8 formas × 8 paletas), filtros, fontes personalizáveis, ícones e imagens próprias. Em 5 minutos você tem a identidade visual de uma coleção inteira sem abrir o Figma.

6. Portal do destinatário e botão "Adicionar ao LinkedIn"

Uma credencial vale o quanto é compartilhada. Cada destinatário recebe acesso passwordless em badges.ninja/me, onde reúne todas as suas credenciais e reivindica um perfil público em badges.ninja/u/<alias>. Cada página pública de credencial inclui:

Botão de um toque para adicionar ao perfil do LinkedIn
Certificado em PDF A4 baixável
QR Code escaneável para currículos impressos
URL pública de verificação

7. Open Badge v2.0 + plano gratuito de 100 credenciais/mês

Open Badge v2.0 é o padrão do IMS Global para credenciais interoperáveis. Qualquer credencial emitida com a BADGES.ninja pode ser lida por backpacks de terceiros que sigam o mesmo padrão. E o plano gratuito permite emitir até 100 credenciais por mês sem cartão de crédito — mais que suficiente para validar a integração com um curso completo antes de migrar para o Pro.

O fator multilíngue

Um detalhe que as plataformas concorrentes raramente destacam: a BADGES.ninja está disponível em mais de 30 idiomas, agrupados por região (Américas, Europa, Ásia & Pacífico). Para uma EdTech brasileira, uma faculdade portuguesa, um centro de formação profissional ou um bootcamp regional, isso significa que tanto o painel do emissor quanto o portal do destinatário podem funcionar no idioma nativo do seu público. É um ponto de fricção a menos na adoção.

Conclusão

Se você constrói ou mantém um produto EAD em português, vale a pena avaliar a BADGES.ninja antes de escolher uma plataforma anglo-saxã mais cara. A combinação de REST API no plano gratuito, IPFS, blockchain opcional, emissão em massa e suporte multilíngue torna a integração rápida e a proposta de valor para o destinatário sólida.

Comece de graça em 👉 https://badges.ninja — 100 emissões por mês sem cartão de crédito.

Emite credenciales digitales verificables con BADGES.ninja: guía en español para desarrolladores y plataformas e-learning

Nacho Coll — Sat, 25 Apr 2026 19:02:24 +0000

Si tu equipo desarrolla una plataforma de cursos online, un LMS, un bootcamp o cualquier producto que entregue "diplomas" al finalizar un módulo, probablemente estés generando hoy un PDF y enviándolo por email. Funciona, pero no es verificable, no se integra con LinkedIn y no resiste el paso del tiempo.

BADGES.ninja es una plataforma de credenciales digitales conforme al estándar Open Badge v2.0 que está disponible en más de 30 idiomas —incluyendo español de España, español de Estados Unidos, portugués de Brasil y catalán— y expone una REST API completa desde el plan gratuito. En este artículo paso revista a las 7 funciones que más peso tienen para un perfil técnico que vaya a integrar emisión de credenciales en su producto.

1. REST API completa con `X-Api-Key` en todos los planes

La diferencia más importante con plataformas como Credly o Accredible: la API REST está disponible en el plan gratuito y se autentica con una simple cabecera X-Api-Key. Puedes generar una clave desde el panel y empezar a emitir credenciales desde tu backend en minutos.

curl -X POST https://badges.ninja/api/awards \
  -H "X-Api-Key: $BADGES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "badge_id": "abc123",
    "recipient_email": "alumna@ejemplo.com",    "recipient_name": "María García"
  }'

Esto te permite validar la integración end-to-end antes de tomar una decisión de compra, algo que las plataformas con API solo en plan empresarial no permiten.

2. Emisión masiva por CSV con pausa, reanudación y reintento

Cuando un bootcamp termina un curso con 500 personas, la emisión una a una no es viable. La función de bulk awards acepta un CSV estándar y procesa el lote con tres garantías: puedes pausar, reanudar exactamente donde se quedó y reintenta automáticamente las filas con errores transitorios. Es el tipo de detalle que solo se aprecia cuando el upload de 2.000 alumnos se cae a la mitad.

3. Almacenamiento permanente en IPFS

Las imágenes de las credenciales se guardan en IPFS (sistema de archivos descentralizado), no en un bucket privado del proveedor. Esto significa que aunque BADGES.ninja dejara de operar algún día, los CIDs de las imágenes seguirían siendo recuperables en cualquier gateway IPFS. Para una universidad o un organismo público que emite títulos con validez a largo plazo, esto es un argumento de peso frente a alojamiento centralizado tradicional.

4. Anclaje opcional en blockchain (plan Pro)

Las credenciales del plan Pro pueden anclarse en una blockchain pública de forma opcional, añadiendo una capa de verificación criptográfica independiente del emisor. La página pública de cada credencial muestra el hash on-chain y un botón de verificación. No es obligatorio activarlo —muchos casos no lo necesitan— pero está disponible cuando el contexto regulatorio lo exige (formación médica continuada, certificaciones de cumplimiento, títulos profesionales regulados).

5. Diseñador visual con más de 80 plantillas

No todos los equipos tienen un diseñador disponible para crear insignias desde cero. El editor de lienzo incluye 80+ plantillas (8 formas × 8 paletas), chips de filtrado, fuentes personalizables, íconos e imágenes propias. En 5 minutos tienes la identidad visual de toda una colección sin abrir Figma.

6. Portal del destinatario y botón "Añadir a LinkedIn"

Una credencial vale lo que se comparte. Cada destinatario recibe acceso passwordless a badges.ninja/me, donde reúne todas sus credenciales y reclama un perfil público en badges.ninja/u/<alias>. Cada página pública de credencial incluye:

Botón de un toque para añadirla al perfil de LinkedIn
Certificado en PDF A4 descargable
Código QR escaneable para CV impresos
URL de verificación pública

7. Open Badge v2.0 + plan gratuito de 100 credenciales/mes

Open Badge v2.0 es el estándar de IMS Global para credenciales interoperables. Cualquier credencial emitida con BADGES.ninja se puede leer desde backpacks de terceros que sigan el mismo estándar. Y el plan gratuito permite emitir hasta 100 credenciales al mes sin tarjeta de crédito —más que suficiente para validar la integración con un curso completo antes de pasar al plan Pro.

El factor multilingüe

Un detalle que no suelen destacar las plataformas competidoras: BADGES.ninja está disponible en más de 30 idiomas, agrupados por región (Américas, Europa, Asia & Pacífico). Para una academia mexicana, un bootcamp argentino, una EdTech brasileña o un centro de formación profesional español, esto significa que tanto el panel del emisor como el portal del destinatario pueden funcionar en el idioma nativo de tu público. Es un punto de fricción menos en la adopción.

Conclusión

Si estás construyendo o mantienes un producto e-learning en español, vale la pena evaluar BADGES.ninja antes de elegir una plataforma anglosajona más cara. La combinación de REST API en plan gratuito, IPFS, blockchain opcional, emisión masiva y soporte multilingüe hace que la integración sea rápida y la propuesta de valor para el destinatario sea sólida.

Empieza gratis en 👉 https://badges.ninja — 100 otorgamientos al mes sin tarjeta de crédito.

Pinea archivos en IPFS desde Claude Code, Cursor y Windsurf (Servidor MCP)

Nacho Coll — Sat, 25 Apr 2026 10:47:59 +0000

¡Hola, devs! Soy Nacho, parte del equipo de BWS (Blockchain Web Services). Acabamos de lanzar IPFS.NINJA, un servicio gestionado de pinning para IPFS, y una de las integraciones que más uso personalmente es el servidor MCP que te permite subir archivos, pinear CIDs y consultar uso de almacenamiento directamente desde Claude Code, Cursor o Windsurf — simplemente hablando con la IA en español.

Disclosure completo: trabajo en este producto. Este post es un walkthrough transparente del equipo que lo construyó.

Qué te ofrece MCP

Model Context Protocol (MCP) es un estándar abierto para conectar asistentes de IA con herramientas externas. Nuestro servidor MCP expone 12 tools que el modelo puede invocar a mitad de conversación contra tu cuenta IPFS.NINJA:

Operaciones de archivo

ipfs_upload — Subir contenido (base64 o texto)
ipfs_upload_json — Subir un objeto JSON
ipfs_import_car — Importar archivo CAR (DAG import)
ipfs_list — Listar tus archivos subidos
ipfs_get — Obtener metadatos por CID
ipfs_delete — Despinear y borrar un archivo

Pinning

ipfs_pin — Pinear un CID existente de la red
ipfs_pin_status — Comprobar el progreso del pin

Organización

ipfs_folders_list / ipfs_folders_create

Cuenta

ipfs_profile — Plan, almacenamiento, ancho de banda
ipfs_analytics — Estadísticas diarias

El efecto práctico: dejas de saltar entre terminal, dashboard y editor.

Setup en Claude Code (60 segundos)

1. Regístrate en ipfs.ninja (gratis) y crea una API key en Dashboard → API Keys. Cópiala (sólo se muestra una vez).

2. Añade el servidor MCP:

claude mcp add ipfs-ninja \
  --transport stdio \
  -e IPFS_NINJA_API_KEY=bws_tu_api_key_completa_aqui \
  -- npx -y @ipfs-ninja/mcp-server

O añádelo manualmente a tu .claude/settings.json:

{
  "mcpServers": {
    "ipfs-ninja": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@ipfs-ninja/mcp-server"],
      "env": {
        "IPFS_NINJA_API_KEY": "bws_tu_api_key_completa_aqui"
      }
    }
  }
}

3. Reinicia Claude Code. Escribe /mcp para confirmar que ipfs-ninja está conectado.

El paquete npm es @ipfs-ninja/mcp-server — sin instalación global, se ejecuta vía npx. Requiere Node.js 18+.

Setup en Cursor / Windsurf

En Settings → MCP Servers, añade:

Setting	Valor
Name	`ipfs-ninja`
Transport	`stdio`
Command	`npx`
Args	`-y @ipfs-ninja/mcp-server`
Environment	`IPFS_NINJA_API_KEY=bws_...`

Cómo se siente en la práctica

Una vez instalado, simplemente le hablas al asistente:

Tú: Sube mi README.md a IPFS
Tú: Lista mis archivos recientes
Tú: ¿Cuánto almacenamiento estoy usando?
Tú: Pinea bafyabc123... desde la red IPFS
Tú: Crea una carpeta llamada "project-assets"

El modelo elige la herramienta correcta, llama a nuestra API y devuelve un CID + una URL pública de gateway tipo https://ipfs.ninja/ipfs/<CID>. Sin copiar comandos curl, sin cambiar de ventana.

Workflows reales que esto desbloquea

Deploy de un sitio estático a IPFS desde Claude Code:

Tú: Sube el contenido de mi carpeta dist/ a IPFS
Claude: [sube cada archivo, devuelve CIDs]
Tú: ¿Cuál es el CID de index.html?
Claude: [llama a ipfs_get] → QmXyz... — https://ipfs.ninja/ipfs/QmXyz...

Pipeline de metadata para NFTs:

Tú: Crea una carpeta "my-collection" y sube este JSON de metadata
Claude: [llama a ipfs_folders_create, luego ipfs_upload_json]
        → Carpeta: my-collection
        → CID: QmAbc... — URL permanente lista para tu smart contract

Monitorizar uso sin salir del editor:

Tú: ¿Estoy cerca del límite de almacenamiento?
Claude: [llama a ipfs_profile]
        → Plan: Bodhi, Almacenamiento: 45.2 MB / 100 GB (0.04%)
Tú: Muéstrame mi ancho de banda esta semana
Claude: [llama a ipfs_analytics con days=7]
        → 2.3 MB de banda, 45 requests en 3 días

Pinear contenido existente de la red:

Tú: Pinea el readme de IPFS en QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
Claude: [llama a ipfs_pin] → ¡Pin iniciado! Estado: pinning
Tú: ¿Ya terminó?
Claude: [llama a ipfs_pin_status] → Estado: pinned, Tamaño: 0.008 MB

Troubleshooting (los tres problemas que de verdad ocurren)

IPFS_NINJA_API_KEY environment variable is required — al bloque env de tu MCP config le falta la clave.
API error 402: not enough storage — has alcanzado el límite de almacenamiento del plan. Haz upgrade o borra archivos no usados.
El servidor no aparece en /mcp — olvidaste reiniciar el editor tras añadirlo. Comprueba también que node --version ≥ 18.

Pruébalo

Documentación del MCP Server (en español): ipfs.ninja/docs/es/api/mcp-server
Paquete npm: @ipfs-ninja/mcp-server
Regístrate gratis: ipfs.ninja (Plan Dharma: 1 GB de almacenamiento, 5 GB de banda/mes, todas las features)

Si construyes algo interesante con esto (auto-pinning de assets de blog en cada commit, flujos de mint de NFT desde la IA, etc.), me encantaría que lo cuentes en los comentarios. Lo leemos todo.

— Nacho, equipo BWS

Faça pin de arquivos no IPFS direto do Claude Code, Cursor e Windsurf (Servidor MCP)

Nacho Coll — Sat, 25 Apr 2026 10:39:12 +0000

E aí, devs — sou o Nacho, parte do time da BWS (Blockchain Web Services). Acabamos de lançar o IPFS.NINJA, um serviço gerenciado de pinning para IPFS, e uma das integrações que eu pessoalmente mais uso é o servidor MCP que permite fazer upload de arquivos, pin de CIDs e consultar uso de armazenamento direto do Claude Code, Cursor ou Windsurf — só conversando com a IA em portuguê.

Disclosure completo: eu trabalho neste produto. Este post é um walkthrough transparente do time que construíu a ferramenta.

O que o MCP entrega

Model Context Protocol (MCP) é um padrão aberto para conectar assistentes de IA a ferramentas externas. Nosso servidor MCP expõe 12 tools que o modelo pode chamar no meio da conversa contra sua conta IPFS.NINJA:

Operações de arquivo

ipfs_upload — Upload de conteúdo (base64 ou texto)
ipfs_upload_json — Upload de objeto JSON
ipfs_import_car — Importar CAR file (DAG import)
ipfs_list — Listar arquivos enviados
ipfs_get — Metadados de arquivo por CID
ipfs_delete — Despinar e deletar um arquivo

Pinning

ipfs_pin — Pinar um CID existente da rede
ipfs_pin_status — Verificar progresso do pin

Organização

ipfs_folders_list / ipfs_folders_create

Conta

ipfs_profile — Plano, armazenamento, banda
ipfs_analytics — Estatísticas diárias

Resultado prático: você para de alternar entre terminal, dashboard e editor.

Setup no Claude Code (60 segundos)

1. Crie sua conta em ipfs.ninja (grátis) e gere uma API key em Dashboard → API Keys. Copie a chave (é mostrada uma vez só).

2. Adicione o servidor MCP:

claude mcp add ipfs-ninja \
  --transport stdio \
  -e IPFS_NINJA_API_KEY=bws_sua_api_key_completa_aqui \
  -- npx -y @ipfs-ninja/mcp-server

Ou adicione manualmente no .claude/settings.json:

{
  "mcpServers": {
    "ipfs-ninja": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@ipfs-ninja/mcp-server"],
      "env": {
        "IPFS_NINJA_API_KEY": "bws_sua_api_key_completa_aqui"
      }
    }
  }
}

3. Reinicie o Claude Code. Digite /mcp para confirmar que ipfs-ninja está conectado.

O pacote npm é @ipfs-ninja/mcp-server — sem necessidade de instalação global, roda via npx. Requer Node.js 18+.

Setup no Cursor / Windsurf

Em Settings → MCP Servers, adicione:

Setting	Valor
Name	`ipfs-ninja`
Transport	`stdio`
Command	`npx`
Args	`-y @ipfs-ninja/mcp-server`
Environment	`IPFS_NINJA_API_KEY=bws_...`

Como é na prática

Depois de instalado, você só conversa:

Você: Faz upload do meu README.md para o IPFS
Você: Lista meus arquivos recentes
Você: Quanto storage estou usando?
Você: Pina o CID bafyabc123... da rede IPFS
Você: Cria uma pasta chamada "project-assets"

O modelo escolhe a tool certa, chama nossa API, e retorna um CID + uma URL pública de gateway tipo https://ipfs.ninja/ipfs/<CID>. Sem ficar copiando comando curl, sem trocar de janela.

Workflows reais que isso destrava

Deploy de site estático no IPFS direto do Claude Code:

Você: Faz upload do conteúdo da minha pasta dist/ para o IPFS
Claude: [faz upload de cada arquivo, retorna CIDs]
Você: Qual o CID do index.html?
Claude: [chama ipfs_get] → QmXyz... — https://ipfs.ninja/ipfs/QmXyz...

Pipeline de metadados de NFT:

Você: Cria uma pasta "my-collection" e faz upload deste JSON de metadata
Claude: [chama ipfs_folders_create, depois ipfs_upload_json]
        → Pasta: my-collection
        → CID: QmAbc... — URL permanente pronta para o smart contract

Monitorar uso sem sair do editor:

Você: Tô perto do meu limite de storage?
Claude: [chama ipfs_profile]
        → Plano: Bodhi, Storage: 45.2 MB / 100 GB (0.04%)
Você: Mostra minha banda essa semana
Claude: [chama ipfs_analytics com days=7]
        → 2.3 MB de banda, 45 requests em 3 dias

Pinar conteúdo existente da rede:

Você: Pina o readme do IPFS em QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
Claude: [chama ipfs_pin] → Pin iniciado! Status: pinning
Você: Já acabou?
Claude: [chama ipfs_pin_status] → Status: pinned, Tamanho: 0.008 MB

Troubleshooting (os três problemas que de fato acontecem)

IPFS_NINJA_API_KEY environment variable is required — o bloco env do MCP config está sem a chave.
API error 402: not enough storage — você atingiu o limite do plano. Faz upgrade ou apaga arquivos não usados.
Servidor não aparece no /mcp — esqueceu de reiniciar o editor depois de adicionar. Confirma também que node --version ≥ 18.

Experimenta

Documentação do MCP Server (em português): ipfs.ninja/docs/pt-BR/api/mcp-server
Pacote npm: @ipfs-ninja/mcp-server
Cadastre-se grátis: ipfs.ninja (Plano Dharma: 1 GB de storage, 5 GB de banda/mês, todos os recursos)

Se você construir algo legal com isso (auto-pinning de assets de blog no commit, fluxo de mint de NFT direto da IA, etc.), conta nos comentários. A gente lê tudo.

— Nacho, time BWS

Mutable Content on IPFS: A Practical Guide to IPNS (with Real Examples)

Nacho Coll — Sat, 25 Apr 2026 10:13:42 +0000

Hi devs — Nacho here from the BWS (Blockchain Web Services) team. We just shipped IPFS.NINJA, a managed IPFS pinning service, and one of the most common questions we get is: “How do I update content on IPFS without changing the URL?”

The answer is IPNS (InterPlanetary Name System) — and it's one of those features that sounds confusing until you see it in action.

Full disclosure: I work on this product. This post is a transparent walkthrough from the team that built it, with concrete examples you can copy-paste.

The problem IPNS solves

IPFS is content-addressed: change a single byte in a file, and the CID changes. That's a feature — immutability and verifiability are the whole point.

But it's also a problem when you want to update something:

Your dApp config evolves → new CID → every client needs the new link.
Your NFT metadata levels up → new CID → your smart contract's tokenURI is now pointing at stale content.
You redeploy your IPFS-hosted website → new CID → you have to tell users the new URL.

IPNS gives you a stable, shareable address that you control and can re-point at any time.

How it works (the short version)

When you create an IPNS name, an Ed25519 keypair is generated. The hash of the public key becomes your IPNS address (a string starting with k51...). To publish, you sign a record saying “this name points to CID X” and broadcast it to the IPFS DHT. To resolve, anyone can query the DHT for the latest signed record.

Key properties:

Stable: the k51... address never changes.
Mutable: you can re-publish to point it at a new CID anytime.
Owned: only the holder of the private key (you) can update it.
Decentralized: any IPFS gateway can resolve it.

Use cases that actually matter

Websites on IPFS — redeploy gives a new CID, but ipns://k51... always serves the latest.
NFT metadata that evolves — set tokenURI = ipns://k51... once; update metadata as the asset evolves.
App config files — update without redeploying the app.
Data feeds / daily datasets — publish under a stable address consumers can poll.
DNSLink — connect a real domain (yourdomain.com) to an IPNS name.

Setting up an IPNS name on IPFS.NINJA

IPNS is included on the Bodhi ($5/mo) and Nirvana ($29/mo) plans (3 names / 100 publishes per month, and 10 names / 1,000 publishes respectively). Records are auto-republished every 12 hours so they stay alive on the network.

From the dashboard:

Go to Hosting → IPNS.
Click Create name, give it a label (e.g. my-website).
Copy the resulting k51... address — this is your permanent shareable handle.
Click Publish, paste the CID you want it to point to, and you're live.

Or from the API:

# Create the IPNS key
curl -X POST https://api.ipfs.ninja/ipns/keys \
  -H "X-Api-Key: bws_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{"name": "my-website"}'

# Publish a CID to it
curl -X POST https://api.ipfs.ninja/ipns/publish \
  -H "X-Api-Key: bws_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{"ipnsName": "k51qzi5uqu5dlvj2bv6...", "cid": "bafybei..."}'

Resolve from any gateway:

https://ipfs.ninja/ipns/k51qzi5uqu5dlvj2bv6...
https://dweb.link/ipns/k51qzi5uqu5dlvj2bv6...
ipns://k51qzi5uqu5dlvj2bv6...

Example 1: Static site deployments

A tiny CI script that uploads dist/ and updates IPNS:

# Upload build output
CID=$(curl -s -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: $IPFS_NINJA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"content\": $(cat dist/index.html | base64 -w0 | jq -Rs .), \"description\": \"Website v2.1\"}" \
  | jq -r '.cid')

# Re-point IPNS
curl -X POST https://api.ipfs.ninja/ipns/publish \
  -H "X-Api-Key: $IPFS_NINJA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"ipnsName\": \"k51qzi5uqu5dlvj2bv6...\", \"cid\": \"$CID\"}"

In GitHub Actions:

- name: Upload to IPFS and publish IPNS
  run: |
    CID=$(curl -s -X POST https://api.ipfs.ninja/upload/new \
      -H "X-Api-Key: ${{ secrets.IPFS_NINJA_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d '{"content": '"$(cat build/output.json)"', "description": "Deploy ${{ github.sha }}"}' \
      | jq -r '.cid')
    curl -X POST https://api.ipfs.ninja/ipns/publish \
      -H "X-Api-Key: ${{ secrets.IPFS_NINJA_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d '{"ipnsName": "${{ vars.IPNS_NAME }}", "cid": "'"$CID"'"}'

Your users always hit ipns://k51... (or your DNSLink domain). The deployment URL never changes.

Example 2: Mutable NFT metadata

This is the killer use case for game items, evolving art, dynamic profiles — anywhere on-chain assets need to change without redeploying the contract.

Your smart contract sets tokenURI to an IPNS address once:

tokenURI = "ipns://k51qzi5uqu5dlvj2bv6..."

When the NFT evolves (e.g. game item levels up):

const newMetadata = {
  name: "Dragon Sword",
  description: "A legendary weapon — Level 5",
  image: "ipfs://QmNewImageCID...",
  attributes: [
    { trait_type: "Level", value: 5 },
    { trait_type: "Damage", value: 150 }
  ]
};

// 1. Upload the new metadata
const uploadRes = await fetch("https://api.ipfs.ninja/upload/new", {
  method: "POST",
  headers: { "Content-Type": "application/json", "X-Api-Key": "bws_..." },
  body: JSON.stringify({ content: newMetadata, description: "Dragon Sword v5" })
});
const { cid } = await uploadRes.json();

// 2. Re-point the IPNS name — tokenURI stays the same!
await fetch("https://api.ipfs.ninja/ipns/publish", {
  method: "POST",
  headers: { "Content-Type": "application/json", "X-Api-Key": "bws_..." },
  body: JSON.stringify({ ipnsName: "k51qzi5uqu5dlvj2bv6...", cid })
});

No contract upgrade. No new CID to coordinate. Marketplaces and wallets that resolve IPNS will reflect the new state.

Example 3: Connect your domain with DNSLink

You can point a real domain at an IPNS name with a single TXT record:

_dnslink.yourdomain.com  TXT  "dnslink=/ipns/k51qzi5uqu5dlvj2bv6..."

Verify with dig:

dig +short TXT _dnslink.myapp.com
# "dnslink=/ipns/k51qzi5uqu5dlvj2bv6..."

Then access via:

https://ipfs.ninja/ipns/myapp.com
ipns://myapp.com   (in IPFS-aware browsers like Brave)

Once the TXT record is set, you never have to touch DNS again. Just publish new CIDs to the IPNS name.

Honest gotchas

Propagation isn't instant. Publishing to the DHT can take up to ~60 seconds.
Records expire after 48h if not republished. We auto-republish every 12h to keep yours alive.
Inactive names (no publishes for 90 days) stop being republished — publish anything once to reactivate.
DNSLink DNS changes can take up to 24h to propagate globally. After that, switching CIDs is instant; you don't touch DNS again.

Try it

IPNS docs: ipfs.ninja/docs/api/ipns
Sign up: ipfs.ninja (Free Dharma plan to test, IPNS unlocks on Bodhi at $5/mo)

If you're using IPNS in a way I didn't cover — collaborative docs, evolving on-chain art, machine-readable status pages — I'd love to hear about it in the comments. We're actively shaping the roadmap based on real use cases.

— Nacho, BWS team

Pin Files to IPFS Straight from Claude Code, Cursor, and Windsurf (MCP Server)

Nacho Coll — Sat, 25 Apr 2026 10:11:53 +0000

Hi devs — Nacho here from the BWS (Blockchain Web Services) team. We just shipped IPFS.NINJA, a managed IPFS pinning service, and one of the integrations I personally use the most is the MCP server that lets you upload files, pin CIDs, and check storage usage directly from Claude Code, Cursor, or Windsurf — just by asking the AI in plain English.

Full disclosure: I work on this product. This post is a transparent walkthrough from the team that built it.

What MCP gives you

Model Context Protocol (MCP) is an open standard for connecting AI coding assistants to external tools. Our MCP server exposes 12 tools the model can call mid-conversation against your IPFS.NINJA account:

File operations

ipfs_upload — Upload file content (base64 or text)
ipfs_upload_json — Upload a JSON object
ipfs_import_car — Import a CAR file (DAG import)
ipfs_list — List your uploaded files
ipfs_get — Get file metadata by CID
ipfs_delete — Unpin and delete a file

Pinning

ipfs_pin — Pin an existing CID from the network
ipfs_pin_status — Check pin progress

Organization

ipfs_folders_list / ipfs_folders_create

Account

ipfs_profile — Plan, storage, bandwidth
ipfs_analytics — Daily bandwidth and file stats

The net effect: you stop context-switching between your terminal, the dashboard, and your editor.

Setup for Claude Code (60 seconds)

1. Sign up at ipfs.ninja (free) and create an API key from Dashboard → API Keys. Copy it (it's only shown once).

2. Add the MCP server:

claude mcp add ipfs-ninja \
  --transport stdio \
  -e IPFS_NINJA_API_KEY=bws_your_full_api_key_here \
  -- npx -y @ipfs-ninja/mcp-server

Or add manually to .claude/settings.json:

{
  "mcpServers": {
    "ipfs-ninja": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@ipfs-ninja/mcp-server"],
      "env": {
        "IPFS_NINJA_API_KEY": "bws_your_full_api_key_here"
      }
    }
  }
}

3. Restart Claude Code. Type /mcp to confirm ipfs-ninja is connected.

The npm package is @ipfs-ninja/mcp-server — no global install needed, runs via npx. Requires Node.js 18+.

Setup for Cursor / Windsurf

In Settings → MCP Servers, add:

Setting	Value
Name	`ipfs-ninja`
Transport	`stdio`
Command	`npx`
Args	`-y @ipfs-ninja/mcp-server`
Environment	`IPFS_NINJA_API_KEY=bws_...`

What it actually feels like

Once installed, you just talk to the assistant:

You: Upload my README.md to IPFS
You: List my recent files
You: How much storage am I using?
You: Pin bafyabc123... from the IPFS network
You: Create a folder called "project-assets"

The model picks the right tool, calls our API, and returns a CID + a public gateway URL like https://ipfs.ninja/ipfs/<CID>. No copy-pasting curl commands, no context switching.

Real workflows it unlocks

Deploy a static site to IPFS from Claude Code:

You: Upload the contents of my dist/ folder to IPFS
Claude: [uploads each file, returns CIDs]
You: What's the CID for index.html?
Claude: [calls ipfs_get] → QmXyz... — https://ipfs.ninja/ipfs/QmXyz...

NFT metadata pipeline:

You: Create a folder called "my-collection" and upload this metadata JSON
Claude: [calls ipfs_folders_create, then ipfs_upload_json]
        → Folder: my-collection
        → CID: QmAbc... — permanent metadata URL ready for your smart contract

Monitor usage without leaving the editor:

You: Am I close to my storage limit?
Claude: [calls ipfs_profile]
        → Plan: Bodhi, Storage: 45.2 MB / 100 GB (0.04%)
You: Show my bandwidth this week
Claude: [calls ipfs_analytics with days=7]
        → 2.3 MB bandwidth, 45 requests across 3 days

Pin existing content from the network:

You: Pin the IPFS readme at QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG
Claude: [calls ipfs_pin] → Pin initiated! Status: pinning
You: Is it done?
Claude: [calls ipfs_pin_status] → Status: pinned, Size: 0.008 MB

Troubleshooting (the three things that actually go wrong)

IPFS_NINJA_API_KEY environment variable is required — the env block in your MCP config is missing the key.
API error 402: not enough storage — you've hit your plan's storage limit. Upgrade or delete unused files.
Server not showing in /mcp — you forgot to restart the editor after adding the server. Also check node --version is ≥ 18.

Try it

MCP Server docs: ipfs.ninja/docs/api/mcp-server
npm package: @ipfs-ninja/mcp-server
Sign up free: ipfs.ninja (Dharma plan: 1 GB storage, 5 GB bandwidth/mo, all features)

If you build something cool with it (auto-pinning blog assets on commit, AI-driven NFT minting flows, etc.), I'd love to hear about it in the comments.

— Nacho, BWS team

Free On-the-Fly Image Optimization for IPFS Content (no node, no auth)

Nacho Coll — Sat, 25 Apr 2026 10:10:43 +0000

Hi everyone — Nacho here from the BWS (Blockchain Web Services) team. We just shipped IPFS.NINJA, a managed IPFS pinning service, and I want to walk through one of the features I think is genuinely under-discussed in the IPFS world: on-the-fly image optimization served straight from a public IPFS gateway.

Full disclosure: I work on this product. This is a transparent walkthrough from the team that built it.

The problem

IPFS is great at serving immutable content. But if you've ever tried to use IPFS for the image-heavy parts of a real product — NFT galleries, dApp avatars, marketplace thumbnails, blog covers — you've hit the same wall:

Your CID is the original 4 MB PNG. There is no ?w=400 to ask for a thumbnail.
You either pre-generate every variant at upload time (and now you're managing N CIDs per asset), or you serve the full-size file every time and watch your bandwidth quota burn.
Modern formats like AVIF and WebP? You'd need to encode them yourself before uploading.

This is why most production dApps end up putting a Cloudinary or Imgix in front of IPFS, which kind of defeats the point.

What we built

IPFS.NINJA exposes a public, no-auth image transform endpoint:

GET /image/:cid

Query parameters:

Param	Default	Description
`w`	—	Output width in pixels (max 4096)
`h`	—	Output height in pixels (max 4096)
`format`	—	`webp`, `jpeg`, `png`, or `avif`
`quality`	80	Compression quality 1-100 (only when `format` is set)
`fit`	`cover`	`cover`, `contain`, `fill`, `inside`, or `outside`

It's served from api.ipfs.ninja/image/:cid, available on all plans including the free Dharma tier (no API key required for the transform itself), and the responses ship with immutable cache headers — same CID + same params = same bytes forever, perfect for any CDN in front.

Quick examples

Resize to 400px wide as WebP:

curl "https://api.ipfs.ninja/image/QmXmCX9S6ANV...?w=400&format=webp"

200x200 JPEG thumbnail at 60% quality:

curl "https://api.ipfs.ninja/image/QmXmCX9S6ANV...?w=200&h=200&format=jpeg&quality=60&fit=cover"

Drop it into HTML

The whole point is that you can use it like any other image CDN. Here's a responsive <img>:

<img
  srcset="
    https://api.ipfs.ninja/image/QmXmCX9S6ANV...?w=400&format=webp 400w,
    https://api.ipfs.ninja/image/QmXmCX9S6ANV...?w=800&format=webp 800w,
    https://api.ipfs.ninja/image/QmXmCX9S6ANV...?w=1200&format=webp 1200w
  "
  sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
  src="https://api.ipfs.ninja/image/QmXmCX9S6ANV...?w=800&format=webp"
  alt="Responsive IPFS image"
/>

You store one CID. The browser asks for the size and format it actually needs. The bytes that come back are content-addressed back to your original via the CID in the URL.

Why this matters for NFTs

If you mint with the original artwork's CID as the canonical reference (and you should — that's what gives the asset provenance), you can still render efficient gallery views, thumbnails, and previews:

const tokenImage = `ipfs://${cid}`; // canonical, immutable
const thumb = `https://api.ipfs.ninja/image/${cid}?w=240&h=240&format=webp&quality=70`;
const preview = `https://api.ipfs.ninja/image/${cid}?w=800&format=avif`;

The original artwork stays untouched on IPFS. You just get cheap, on-demand variants for your UI.

A note on framework integration

Next.js <Image>, Nuxt <NuxtImg>, Astro <Image>, and most other framework image components let you plug in a custom loader. You can write a one-liner that maps (src, width, quality) → https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp&quality=${quality} and you've effectively connected your framework's responsive image pipeline to IPFS.

Caching

Responses include immutable cache headers. Because IPFS content is content-addressed, the same CID with the same query parameters always produces the same output. Browsers and CDNs (Cloudflare, Fastly, your own Varnish) can cache these responses indefinitely — no cache busting needed, ever.

Limits and honesty

A few things worth knowing:

Max output dimensions: 4096px on either axis.
The transform endpoint is public; if you don't want certain CIDs hot-reachable, don't pin them publicly (or use Nirvana's dedicated gateway with token-based access).
If you don't pass any params, the request just redirects to the original file.

Try it

Image Optimization docs: ipfs.ninja/docs/api/image-optimization
Sign up free (Dharma plan, image optimization included): ipfs.ninja

Questions or edge cases you'd like to see supported (focal point cropping, smart blur for placeholders, etc.) — drop them below. We're actively iterating.

— Nacho, BWS team

Drop-in S3 for IPFS: Pin to IPFS.NINJA with the AWS SDK You Already Use

Nacho Coll — Sat, 25 Apr 2026 10:09:22 +0000

Hi devs — I'm Nacho, part of the BWS (Blockchain Web Services) team. We just shipped IPFS.NINJA, a managed IPFS pinning service, and one of the features we're most excited about is the S3-compatible API: you can keep using the AWS SDK you already know and pin straight to IPFS, getting a permanent CID back as the ETag.

This post is a transparent walkthrough from the people who built it.

Why an S3 surface for IPFS?

Most teams already have working code that talks to S3 (or to S3-compatible services like Filebase, R2, MinIO). When you decide to move some of that storage to IPFS for verifiability, decentralization, or NFT use cases, you usually have to learn a new API, change your upload flow, and rewrite tooling.

We wanted to remove that friction. With IPFS.NINJA's S3 endpoint, you swap the endpoint and credentials and your existing PutObject / GetObject / ListObjectsV2 / DeleteObject calls keep working — but every upload also gets pinned on IPFS and returns a content-addressed CID.

The 30-second setup

Endpoint: https://s3.ipfs.ninja

Your IPFS.NINJA API key acts as both the access key and the secret key:

accessKeyId: first 12 chars of your key (e.g. bws_628bba35)
secretAccessKey: the full key (e.g. bws_628bba35e9e0079d9ff9c392b1b55a7b)
region: us-east-1 (always)
forcePathStyle: true

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  endpoint: "https://s3.ipfs.ninja",
  credentials: {
    accessKeyId: "bws_628bba35",
    secretAccessKey: "bws_628bba35e9e0079d9ff9c392b1b55a7b"
  },
  region: "us-east-1",
  forcePathStyle: true
});

const put = await s3.send(new PutObjectCommand({
  Bucket: "my-project",
  Key: "hello.json",
  Body: JSON.stringify({ hello: "IPFS" }),
  ContentType: "application/json"
}));

console.log("CID:", put.Metadata?.cid);
// CID: QmXnnyufdzAWL5CqZ2RnSNgPbvCc1ALT73s6epPrRnZ1Xy

That's the whole thing. The CID comes back in the response metadata (and in the ETag), and the file is immediately retrievable at https://ipfs.ninja/ipfs/<CID> — or from any public IPFS gateway, since the network is decentralized.

Buckets = Folders

S3 buckets map 1:1 to your IPFS.NINJA folders, so the mental model is exactly the same:

S3 Operation	IPFS.NINJA Equivalent
`CreateBucket`	Create a new folder
`ListBuckets`	List your folders
`PutObject`	Upload file into the folder
`ListObjectsV2`	List files in the folder
`DeleteBucket`	Delete a folder and all files

await s3.send(new CreateBucketCommand({ Bucket: "nft-metadata" }));

await s3.send(new PutObjectCommand({
  Bucket: "nft-metadata",
  Key: "token-42.json",
  Body: JSON.stringify({ name: "My NFT #42" })
}));

The folders you create from the S3 API show up in your dashboard and can be managed from the REST API too — same underlying storage.

Multipart uploads for big files

The standard AWS multipart flow works out of the box (up to 5 GB):

import { Upload } from "@aws-sdk/lib-storage";
import fs from "fs";

const upload = new Upload({
  client: s3,
  params: {
    Bucket: "my-project",
    Key: "large-dataset.tar.gz",
    Body: fs.createReadStream("large-dataset.tar.gz"),
    ContentType: "application/gzip"
  },
  partSize: 10 * 1024 * 1024
});

upload.on("httpUploadProgress", (p) =>
  console.log(`Uploaded ${p.loaded} of ${p.total} bytes`)
);

const result = await upload.done();
console.log("CID:", result.ETag);

Python / Go also work

Because it's plain S3, anything that speaks S3 works. Here's boto3:

import boto3

s3 = boto3.client(
    "s3",
    endpoint_url="https://s3.ipfs.ninja",
    aws_access_key_id="bws_628bba35",
    aws_secret_access_key="bws_628bba35e9e0079d9ff9c392b1b55a7b",
    region_name="us-east-1"
)

s3.put_object(
    Bucket="my-project",
    Key="data.json",
    Body=b'{"hello": "IPFS"}',
    ContentType="application/json"
)

Same for aws-sdk-go-v2, Rust S3 clients, s3cmd, rclone, etc.

Honest differences from Amazon S3

We want to be upfront about the parts that don't translate. Because IPFS is content-addressed and immutable:

Feature	Amazon S3	IPFS.NINJA S3
Storage model	Mutable objects	Content-addressed (immutable CIDs)
Overwrite behavior	Replaces in place	Creates a new CID; old CID still works
Versioning	Supported	Use CIDs as version pointers
Presigned URLs	Supported	Use signed upload tokens instead
Max object size	5 TB	5 GB (multipart), 100 MB (single PUT)
Regions	Multi-region	`us-east-1` only
`ETag`	MD5	IPFS CID

That last row is actually the magic: your ETag is a real IPFS CID you can hand to anyone, anywhere on the network.

Migrating from Amazon S3 or Filebase

For Amazon S3, the diff is just the endpoint and credentials:

const s3 = new S3Client({
+ endpoint: "https://s3.ipfs.ninja",
  credentials: {
-   accessKeyId: "AKIA...",
-   secretAccessKey: "wJalrX..."
+   accessKeyId: "bws_628bba35",
+   secretAccessKey: "bws_628bba35e9e0..."
  },
  region: "us-east-1",
+ forcePathStyle: true
});

For Filebase, only the endpoint changes:

- endpoint: "https://s3.filebase.com",
+ endpoint: "https://s3.ipfs.ninja",

Your existing PutObject, GetObject, ListObjectsV2, DeleteObject calls work unchanged.

Where to go next

If you're building NFT metadata pipelines, static site deploys to IPFS, or just want pinning that doesn't require running a node, this is the fastest way to wire it into existing infrastructure.

Free tier (Dharma): 1 GB storage, 5 GB bandwidth/month, all features included
Bodhi ($5/mo): 100 GB storage, 200 GB bandwidth, IPNS, dedicated gateways
Nirvana ($29/mo): 1 TB storage, 10 dedicated gateways, IP whitelist

Full S3 docs: ipfs.ninja/docs/api/s3-compatibility
Sign up free: ipfs.ninja

Happy to answer questions about the design, limits, or migration paths in the comments — we read everything.

— Nacho, BWS team

DEV Community: Nacho Coll

Verifieerbare digitale badges uitgeven met BADGES.ninja: Nederlandse gids voor developers en e-learning platforms

Waarom Open Badge v2.0?

De REST API in de praktijk

Bulk-uitgifte via CSV

IPFS-opslag: permanentie voor de afbeeldingen

Optionele blockchain-verankering

Ontvangerportaal en LinkedIn-integratie

Meertaligheid als onderscheidende factor

Gratis plan om te starten

Conclusie

Emettere certificazioni digitali verificabili con BADGES.ninja: guida in italiano per sviluppatori e piattaforme e-learning

Perché Open Badge v2.0?

La REST API in pratica

Emissione di massa via CSV

Archiviazione su IPFS: permanenza per le immagini

Ancoraggio blockchain opzionale

Portale destinatario e integrazione LinkedIn

Multilinguismo come fattore differenziante

Piano gratuito per iniziare

Conclusione

Verifizierbare digitale Zertifikate mit BADGES.ninja ausstellen: deutscher Leitfaden für Entwickler und Bildungsanbieter

Warum Open Badge v2.0?

Die REST-API in der Praxis

Massenausstellung per CSV

IPFS-Speicherung: Permanenz für die Bildlinks

Optionale Blockchain-Verankerung

Empfängerportal und LinkedIn-Integration

Mehrsprachigkeit als Differenzierungsmerkmal

Kostenloser Plan zum Starten

Fazit

Émettre des badges numériques vérifiables avec BADGES.ninja : guide en français pour développeurs et plateformes e-learning

1. API REST complète avec X-Api-Key sur tous les plans

2. Émission en masse par CSV avec pause, reprise et réessai

3. Stockage permanent sur IPFS

4. Ancrage blockchain optionnel (plan Pro)

5. Éditeur visuel avec plus de 80 modèles

6. Portail du destinataire et bouton « Ajouter à LinkedIn »

7. Open Badge v2.0 + plan gratuit de 100 credentials/mois

Le facteur multilingue

Conclusion

Emita credenciais digitais verificáveis com BADGES.ninja: guia em português para devs e plataformas EAD

1. REST API completa com X-Api-Key em todos os planos

2. Emissão em massa por CSV com pausa, retomada e nova tentativa

3. Armazenamento permanente em IPFS

4. Ancoragem opcional em blockchain (plano Pro)

5. Editor visual com mais de 80 templates

6. Portal do destinatário e botão "Adicionar ao LinkedIn"

7. Open Badge v2.0 + plano gratuito de 100 credenciais/mês

O fator multilíngue

Conclusão

Emite credenciales digitales verificables con BADGES.ninja: guía en español para desarrolladores y plataformas e-learning

1. REST API completa con X-Api-Key en todos los planes

2. Emisión masiva por CSV con pausa, reanudación y reintento

3. Almacenamiento permanente en IPFS

4. Anclaje opcional en blockchain (plan Pro)

5. Diseñador visual con más de 80 plantillas

6. Portal del destinatario y botón "Añadir a LinkedIn"

7. Open Badge v2.0 + plan gratuito de 100 credenciales/mes

El factor multilingüe

Conclusión

Pinea archivos en IPFS desde Claude Code, Cursor y Windsurf (Servidor MCP)

Qué te ofrece MCP

Setup en Claude Code (60 segundos)

Setup en Cursor / Windsurf

Cómo se siente en la práctica

Workflows reales que esto desbloquea

Troubleshooting (los tres problemas que de verdad ocurren)

Pruébalo

Faça pin de arquivos no IPFS direto do Claude Code, Cursor e Windsurf (Servidor MCP)

O que o MCP entrega

Setup no Claude Code (60 segundos)

Setup no Cursor / Windsurf

Como é na prática

Workflows reais que isso destrava

Troubleshooting (os três problemas que de fato acontecem)

Experimenta

Mutable Content on IPFS: A Practical Guide to IPNS (with Real Examples)

The problem IPNS solves

How it works (the short version)

1. API REST complète avec `X-Api-Key` sur tous les plans

1. REST API completa com `X-Api-Key` em todos os planos

1. REST API completa con `X-Api-Key` en todos los planes