> For the complete documentation index, see [llms.txt](https://docs.learncard.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.learncard.com/understand/verifiable-credentials-vcs/boost-credentials.md).

# 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:

```json
{
    "@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." }
        }
    }
}
```

{% hint style="warning" %}
Include the LearnCard Boost context and the `BoostCredential` type. When the network signs from a template — a `send()` with `templateUri`, or [issuing on consent](/understand/consentflow-overview/auto-boosts.md) — it stamps `boostId` on the credential, and signing fails with `undefined JSON-LD term` if nothing defines it.
{% endhint %}

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

```json
{
    "name": "Course Completion Template",
    "category": "Achievement",
    "type": "Course",
    "status": "DRAFT"
}
```

`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](/understand/verifiable-credentials-vcs/building-verifiable-credentials.md) 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.

{% hint style="info" %}
Missing `templateData` variables render as empty strings; check required values before sending. Templates without variables work unchanged, and unused template data is ignored.
{% endhint %}

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](/reference/learncard-core/achievement-types-and-categories.md) 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

* [Send & Issue Credentials — issue at scale with templates](/build/send-credentials.md#issue-at-scale-with-templates)
* [Who Signs](/build/send-credentials/create-signing-authority.md)
* [Revoke or Update a Credential](/build/send-credentials/revoke-or-update-a-credential.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.learncard.com/understand/verifiable-credentials-vcs/boost-credentials.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.