Issue credentials
Issue verifiable Open Badges 3.0 credentials — your recipients only need an email.
One call issues a W3C Verifiable Credential 2.0 / Open Badges 3.0 credential: signed (VC-JWT), selectively disclosable (SD-JWT) and anchored. If the recipient is an email address, Glemo delivers it with a public verification link — no wallet, no account, no crypto on their side.
Get a key with issue:write
Issuance needs an API key with the issue:write scope. Sandbox keys from
the quickstart are verify-only — ask us for an issuer key,
or use your live key if your organization is onboarded.
Issue your first credential
The response carries the credentialId, the signed jwt, the selectively
disclosable sdJwt and the publicUrl your recipient received by email.
Close the loop: verify it
The credential you just issued verifies like any other — by anyone:
Or just open the publicUrl — the same verification, human-readable.
Selective disclosure is on by default
Every credential ships as an SD-JWT too: the holder can present only a subset of its claims (say, the achievement name without the description) and it still verifies. No premium tier, no flag — it's the default. See concepts for how disclosure works.
Issuing is not idempotent
Two identical issue() calls create two credentials. The SDK therefore does
not retry issuance by default — opt in with glemo.issue(input, { retries: 1 })
only if your side deduplicates.
Bulk issuance (CSV, queued, idempotent per row) and visual templates are available from the issuer dashboard.
Export
Every issued credential is a signed W3C Verifiable Credential 2.0 / Open Badges 3.0. From the credential detail in the issuer dashboard you can download it as a VC-JWT or an Open Badges 3.0 JSON and verify it in any conformant tool, with no dependency on Glemo. That is what "no lock-in" means in practice.