For the complete documentation index, see llms.txt. This page is also available as Markdown.

Credential Templates (Boosts)

Understand Boosts as reusable credential templates: their structure, lifecycle, and permissions on the LearnCard Network.

A Boost is a credential template stored on the LearnCard Network. Create it once; every send() from it produces a new signed credential for that recipient. Sending a signedCredential without an existing template also saves a template automatically; its URI is returned as result.uri.

Template URIs look like lc:network:<host>/trpc:boost:<id>. Always use the returned value; never construct a URI yourself. The template URI identifies the reusable template, not an individual recipient's credential.

What a template gives you

  • Reuse the same credential structure across recipients.

  • Personalize {{variables}} for each send through templateData.

  • Track recipients with learnCard.invoke.getPaginatedBoostRecipients().

  • Revoke issued credentials through a credential status list.

  • Let LearnCard sign for you through a signing authority, so your server needn't hold the signing key.

  • Build visually in the Developer Portal's credential template builder.

Anatomy

learnCard.invoke.createBoost(credential, metadata) takes an unsigned credential and a separate metadata object, and returns the template URI. Here is an Open Badges v3 (OBv3) credential template, before recipient assignment and signing:

{
    "@context": [
        "https://www.w3.org/ns/credentials/v2",
        "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
        "https://ctx.learncard.com/boosts/1.0.1.json"
    ],
    "type": ["VerifiableCredential", "OpenBadgeCredential", "BoostCredential"],
    "name": "Course Completion",
    "credentialSubject": {
        "type": ["AchievementSubject"],
        "achievement": {
            "id": "https://example.com/achievements/course-completion",
            "type": ["Achievement"],
            "achievementType": "Course",
            "name": "{{courseName}}",
            "description": "Completed {{courseName}}.",
            "criteria": { "narrative": "Complete all course requirements." }
        }
    }
}

The metadata argument describes the template in the network, not the claims in the credential:

name, category, and type are optional strings; status is an optional enum. The metadata type is separate from the credential's JSON-LD type array. The recipient and signing details are supplied during issuance, not fixed to one learner in the template.

Optional display metadata controls appearance; BoostID fields support digital ID layouts. Use credential evidence for proof of an achievement and attachments for other supporting resources. See Building Verifiable Credentials for credential fields.

Lifecycle

The usual progression is DRAFT β†’ LIVE; PROVISIONAL is available when you need to issue while iterating.

Status
Edit template fields?
Send credentials?

DRAFT

Yes

No; claim links cannot be generated either

PROVISIONAL

Yes

Yes

LIVE

No; only meta and defaultPermissions remain editable

Yes

Publish a draft with learnCard.invoke.updateBoost(boostUri, { status: 'LIVE' }) once it is ready. Sending requires permission to issue from the template, regardless of its status. Changes to a template do not rewrite credentials already signed and delivered.

For template-based sends, configure a signing authority before relying on hosted signing. Providing a signedCredential instead preserves your existing proof rather than signing it again.

Missing templateData variables render as empty strings; check required values before sending. Templates without variables work unchanged, and unused template data is ignored.

Sending again to the same recipient creates another issuance; send() is not idempotent. Reconcile recipient records before retrying bulk sends to avoid duplicates.

Older code uses sendBoost(profileId, boostUri); prefer send().

Categories & types

Categories organize credentials in LearnCard, while achievement types describe what was earned. They are not the same as the credential's JSON-LD types or its display layout. See Schemas, Types, & Categories for the supported conventions.

Hierarchy & permissions

Templates can have parent/child relationships and per-role permissions, as ScoutPass uses for NSO β†’ Troop β†’ Scout IDs. Inspect them with learnCard.invoke.getBoostChildren() and learnCard.invoke.getBoostPermissions(). Permissions can be assigned directly, inherited, or granted on claim; defaultPermissions apply to all authenticated users and combine with explicit permissions, so grant them carefully.

Next steps

Last updated

Was this helpful?