> ## Documentation Index
> Fetch the complete documentation index at: https://docs.senderkit.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Templates
> Dashboard-editable message definitions your code references by slug.
Your transactional copy usually lives in the codebase — a React Email component, an
MJML file, a string literal in a route handler. Every wording change is a pull
request and a redeploy, with a developer in the loop for a comma. A **template**
moves that copy out of the repo and into the SenderKit dashboard. Your code
references the template by name; the subject, layout, and copy live in the
dashboard, where anyone on the team can edit them without touching code.
## What a template is
A template is a named, channel-bound definition of a message. It carries:
* A **slug** — the stable identifier your code sends to (`"welcome"`,
`"password-reset"`). Unique within your workspace.
* A **channel** — `email`, `sms`, `push`, or `web-push`. Fixed when the template is
created; a template targets exactly one channel.
* A **stack of versions** — the actual subject, layout, and copy live in
[versions](/concepts/versioning), not on the template itself. The template just
points at whichever version is currently published.
* A **status** — `draft` until you publish a version, then `active`. Templates can
also be `archived`. Archiving is a hard stop: any API or SDK send to an archived
template's slug returns `422 template_archived`.
The template is identity and routing; the content lives in its versions. That
separation is what makes copy edits safe — every change is a new version you can
publish or roll back independently.
## Referencing a template from a send
Your code names the template by slug and supplies the recipient and
[variables](/concepts/variables). It never names a version or a channel — the
channel comes from the template, and SenderKit picks the version for you (see
[Versioning](/concepts/versioning) and [Environments](/concepts/environments)).
```ts theme={null}
await senderkit.send({
template: "welcome",
to: "user@example.com",
vars: { name: "Ada" },
});
```
If the slug doesn't exist you get a `404`; in live mode, a template with no
published version is also a `404` until you publish one.
## Why this decouples copy from deploys
You wire up `send({ template: "welcome" })` once. After that, changing the welcome
email's wording is a dashboard edit and a publish — not a code change, not a
redeploy, not your time. The send call is a stable contract; everything that can
change without engineering (the words, the layout, the subject line) lives on the
other side of that contract.
## Managing a template
The template editor's **Settings** tab exposes lifecycle actions beyond the content
editor:
* **Description** — a free-text label visible in the dashboard.
* **Provider override** — pin this template to a specific provider connection instead
of the workspace default for the channel.
* **Slug** — rename the template's identifier. Slugs are always stored in lowercase
(`"Welcome-Email"` saves as `"welcome-email"`), so your code must reference them
in lowercase. Changing the slug breaks any code or integrations that reference the
old name, so a warning is shown.
* **Duplicate** — clones the latest version's content and variables as a new `draft`
template (the duplicate button also appears in the editor toolbar). The plan's
template cap applies.
* **Archive / Unarchive** (Danger zone) — archiving marks the template `archived`
and immediately stops all new sends to it (`422 template_archived`). The action is
reversible — unarchiving restores the template to `draft` — but consequential: any
integration still calling the slug will start getting errors. Scheduled messages
already queued before archiving are not retroactively cancelled.
Archiving is the delete-equivalent for templates. Hard deletion is not available
by design — archived templates remain visible in the dashboard when you switch the
status filter to include `Archived`.
## Previewing and testing (email only)
The template editor's **Preview** tab renders the current editor content —
including unsaved edits — through the same engine used at send time. Variable
placeholders are filled with sample values derived from the template's declared
variables, so you can verify layout and substitution before publishing.
A **Send test** button in the preview panel dispatches the rendered email to
your own account address immediately, through the normal delivery path. The test
send appears in the message log like any other send.
## Synced blocks
A **synced block** is a named HTML fragment you define once in the dashboard
(**Blocks** in the sidebar) and insert into any email template via the editor's
slash menu (**Synced blocks** group). Typical uses: a branded header, a shared
footer, a legal disclaimer.
When you insert a synced block into a template the editor records a reference, not a
copy. At send time SenderKit resolves each reference to the block's **current
content**, so editing a synced block propagates to every email that uses it
automatically — including already-published templates — without republishing.
Synced blocks share the host template's variable namespace, so `{{vars}}` inside a
block resolve against the send's variables just like the rest of the template.
```ts theme={null}
// Synced blocks are transparent to your code — the send call is unchanged.
await senderkit.send({
template: "receipt",
to: "user@example.com",
vars: { amount: "$42.00", companyName: "Acme" },
});
```
Per-block variable declarations are not yet supported. Declare all variables
used inside a synced block on the parent template.
Fill the dynamic holes in a template at send time.
How edits become versions and how a send picks one.
What a template's channel means and who delivers it.
How a template reference turns into a delivered message.