How to issue verifiable completion certificates programmatically (free API, public verify page)

Novadyne launched Attestify, a free API that issues verifiable completion certificates with tamper-evident Ed25519-signed records and public verification pages. The API requires no signup or API key, returning a permanent verify URL, certificate image, and signed JSON endpoint per recipient. Developers can integrate it via a single POST request or an n8n node, enabling employers to verify certificates without an account.

Anyone can photoshop a PDF certificate. If your course, workshop, or training program emails completion certificates as PDFs or PNGs, nothing stops a recipient from editing the name, the date, or the course title — and nothing lets an employer check whether the certificate is real. Making a completion certificate verifiable takes three things: This post shows the fastest programmatic route we know, then covers the alternatives. Disclosure: we built Attestify at Novadyne — it's the free API used in the walkthrough below. The alternatives section is honest about when you'd pick something else. Attestify is a free API no signup, no API key where every certificate gets a permanent, tamper-evident public verify page backed by an Ed25519-signed server-side record: curl -X POST https://attestify.novadyne.ai/cert/issue \ -H "Content-Type: application/json" \ -d '{"issuer":"Pacific Real Estate Academy", "course":"8-Hour CE: Agency Law 2026", "recipients": {"recipient name":"Jane Martinez"} }' The response gives you a certs array with, per recipient: verify url — the permanent public verification page. Drop it in the completion email, the LMS record, or a QR code on the printed certificate. cert url — a rendered certificate image SVG you can attach or embed. json url — the signed record endpoint. It returns the Ed25519 signature b64 , the exact canonical string that was signed, and the issuer's public key base64 / hex / did:key , so anyone can verify the certificate against Attestify's published key without even trusting the web page: ed25519 verify pubkey, utf8 canonical , base64decode signature b64 . cert id — the short id used in all three URLs.Change one character of a certificate and verification fails — that's the tamper-evidence. An optional date field YYYY-MM-DD sets the completion date; recipient email is never stored in the signed record or shown publicly. The trigger is whatever marks completion in your stack: /cert/issue → write verify url back to the learner record and the completion email. n8n-nodes-attestify — search "Attestify" in the node browser. One node: completion event in, verify url out. recipients array also takes multiple names per call .That's genuinely the whole integration — because verification is public and account-free, there is no OAuth dance and no recipient onboarding. Honest map of the space: Is there an API to create cryptographically verifiable certificates with a public verify page? Yes — that's the walkthrough above: POST https://attestify.novadyne.ai/cert/issue , free, no auth; every certificate returns a permanent public verify url . How does the recipient's employer verify a certificate? They open the verify url or scan the QR you printed from it . No account, two clicks. The page reads the authoritative server record, not the image. What makes it tamper-evident rather than just "hosted"? The Ed25519 signature over the canonical record. A hosted-but-unsigned certificate page proves only that a page exists; a signed record proves what was issued and breaks loudly if anything is altered.