---
title: "openemail templates"
description: "Every command in this namespace, with its arguments, flags and examples."
url: "https://openemail.uk/docs/cli/reference/templates"
area: "CLI"
category: "Reference"
---

# openemail templates

Every command in this namespace, with its arguments, flags and examples.

## Commands

### `openemail templates list`

List templates, most recently updated first

```bash
openemail templates list [flags]
```

Returns one page of the workspace's templates, ordered by `updatedAt` descending. Each row carries the published version's `subject`, `engine`, `slots` and `props`, so you can see what a send needs without fetching every template. A template with nothing published omits those four fields and reports `publishedVersion` as null.

Paging is keyset on `updatedAt`, and the cursor is opaque: it holds the `sort` and where the last template on the page sat in it, so a template deleted while you page never breaks the walk. Editing a template moves it to the front, so a template changed while you page can show up twice.

`--status` narrows to one template status. `draft` is the status of a template created without `publish` and never published or activated since. It does not mean "has unpublished edits": check `latestVersion` against `publishedVersion` for that.

Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max <n>` stops after that many items.

- Scopes: `templates:read`.
- Needs a sign-in.
- Aliases: `ls`.

**Flags**

- `--status <value>`: Restricts the page to `draft`, `active` or `archived` templates. Omit it for all of them.
- `--search <value>`: Matches the name, the slug, the description, the published version's subject and the id, each word loosely, with close spellings when nothing matches exactly, as a substring. `%` and `_` are taken literally.
- `--sort <value>`: The order: `updated-newest` (the default), `updated-oldest`, `created-newest`, `created-oldest`, `name` or `name-reversed`. The cursor follows whichever you asked for.
- `--limit <n>`: Rows per page, a whole number from 1 to 100. The server defaults to 25.
- `--cursor <value>`: The `nextCursor` from the previous page. Never build one yourself.
- `--all`: Fetch every page and stream the items as they arrive.
- `--max <n>`: Stop after this many items. Implies `--all`.
- `--ndjson`: Print every item as one JSON object per line. Implies `--all`

**Examples**

```bash
openemail templates list
```

With optional flags

```bash
openemail templates list --status active --limit 50
```

Walk every page and stop after 100 items

```bash
openemail templates list --all --max 100
```

One JSON object per line when piped

```bash
openemail templates list --all > templates.ndjson
```

Also available in: API [`GET /templates`](https://openemail.uk/docs/api/reference/templates#get-templates); SDK [`templates.list()`](https://openemail.uk/docs/sdk/reference/templates#list).

### `openemail templates get`

Read a template with its head version in full

```bash
openemail templates get <id-or-slug> [flags]
```

Fetches one template by `tpl_` id or by slug. Every templates method accepts either, and the two cannot collide because ids carry the `tpl_` prefix while a slug has no underscores. Pin the slug in code: it is derived once at creation and never changes when the template is renamed.

`latest` is the head version, meaning the current draft, or the published version when nothing has been edited since. This is the only read that returns the body: `document` for the `blocks` engine, and `html` for the `html` engine exactly as submitted, before sanitising. The top level `subject`, `engine`, `slots` and `props` describe the published version, which is what a send uses, so they differ from `latest` while somebody has unpublished edits.

When nothing has been published yet, `publishedVersion` is null and the top level `subject`, `engine`, `slots` and `props` are absent. Read the draft from `latest` instead. Use `list` or `listVersions` to find out whether a template can actually be sent.

- Scopes: `templates:read`.
- Needs a sign-in.
- Aliases: `show`, `view`.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Examples**

```bash
openemail templates get order-shipped
```

Print the raw JSON

```bash
openemail templates get order-shipped --json
```

Also available in: API [`GET /templates/{id}`](https://openemail.uk/docs/api/reference/templates#get-templates-id); SDK [`templates.get()`](https://openemail.uk/docs/sdk/reference/templates#get).

### `openemail templates create`

Create a template and its first version

```bash
openemail templates create --name <value> [flags]
openemail templates create --data <json|@file|-> [flags]
```

Creates the template together with version 1. Without `publish: true` that version is a draft, and a draft cannot be sent: `send` answers 422 `template_not_published` until somebody calls `publish`. With `publish: true` the body is compiled straight away and the template starts `active`, so a body that fails to render is refused here instead of later.

The engine follows what you send. Posting `html` selects the `html` engine, anything else is `blocks`. A `blocks` template stores a `document` whose `body` is a tree of `@react-email/components` nodes (`Section`, `Row`, `Column`, `Container`, `Text`, `Heading`, `Button`, `Link`, `Img`, `Hr`, `Markdown`, `CodeBlock` and `CodeInline`), validated on the way in with a ceiling of 500 nodes nested 8 deep. An `html` template stores markup you rendered yourself, for example with `@react-email/render` in your own build, and it is sanitised when the version is compiled.

`{{key}}` placeholders are filled from declared slots and props. A slot has a default and belongs to whoever edits the template. A prop is supplied by the sender and can be `required`. Keys start with a letter and continue with letters, digits or underscores, and one key cannot be both. In a `blocks` template an undeclared placeholder is a 422 `invalid_template` naming its path. In `html` markup, any placeholder used inside an attribute such as `href` or `src` must be declared with kind `url` or `image`, or compiling fails.

- Scopes: `templates:write`.
- Needs a sign-in.
- Aliases: `new`, `add`.

**Flags**

- `--name <value>`: Display name, 1 to 100 characters after trimming and unique per workspace. Required, here or in `--data`.
- `--slug <value>`: Stable handle of lowercase letters, digits and hyphens, at most 64 characters. Derived from `name` when omitted.
- `--description <value>`: Free text note, at most 500 characters.
- `--publish` (default `false`): Compiles and publishes version 1 immediately. Defaults to false, which leaves a draft.
- `--starter <value>`: A starter slug from `listStarters`, which seeds the subject and the body. Anything you send yourself wins over the starter, and an unknown slug is a 404.
- `--engine <value>`: `blocks` or `html`. Inferred from whether `html` is present.
- `--subject <value>`: Subject line with optional `{{placeholders}}`, at most 998 characters and free of line breaks.
- `--document <json|@file|->`: The `blocks` body: `body` (the block tree) plus the page settings that travel with it, `preview`, `tailwind`, `fonts` and `style`. Defaults to an empty body. JSON shaped as `TemplateDocument`, inline or from a file with @path.
- `--html <value>`: Pre-rendered markup for the `html` engine. Required for it, at most 1,000,000 characters.
- `--slots <json|@file|->`: Up to 100 editor filled values, each with `key`, optional `label`, `kind` (default `text`) and `default` (default empty string). JSON shaped as `Array<Partial<TemplateSlot> & { key: string }>`, inline or from a file with @path.
- `--props <json|@file|->`: Up to 100 sender supplied values, each with `key`, optional `label`, `kind` (default `text`), `required` (default false) and `default` (default null). JSON shaped as `Array<Partial<TemplateProp> & { key: string }>`, inline or from a file with @path.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

The required values only

```bash
openemail templates create --name 'Order shipped'
```

With optional flags

```bash
openemail templates create --name 'Order shipped' --slug order-shipped --publish --engine html
```

Read the whole body from a JSON file

```bash
openemail templates create --data @template.json
```

Also available in: API [`POST /templates`](https://openemail.uk/docs/api/reference/templates#post-templates); SDK [`templates.create()`](https://openemail.uk/docs/sdk/reference/templates#create).

### `openemail templates update`

Edit template metadata or its draft body

```bash
openemail templates update <id-or-slug> [flags]
```

Changes a template in place. `name`, `description` and `status` are metadata and never create a version. Sending any of `subject`, `document`, `html`, `slots`, `props` or `engine` is a body edit: if the head version is still a draft it is overwritten, and if the head is published a new draft numbered one higher is minted. Body fields you leave out keep the head's values, so a patch carrying only `subject` keeps the existing document and declarations, while `slots` or `props` replace the whole list.

Nothing here changes what a live send resolves to. Sends keep using the published version until you call `publish`, which is what makes it safe to edit a template in production. The response's `latest` is the version this call wrote into.

Pass `--expected-version` with the `latestVersion` you read before editing. If another writer has moved the head since, the call fails with 409 `version_conflict` instead of overwriting their change. Without it the last write wins. Setting `status: 'archived'` is the reversible alternative to `delete`, but it does not block sends: an archived template with a published version still sends.

- Scopes: `templates:write`.
- Needs a sign-in.
- Aliases: `edit`.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Flags**

- `--name <value>`: Replacement name, 1 to 100 characters and unique per workspace. The slug does not follow it.
- `--slug <value>`: Replacement slug of lowercase letters, digits and hyphens, at most 64 characters. Anything pinning the old slug starts getting 404s, and taking another template's slug is a 409 `template_slug_taken`.
- `--description <value>`: Replacement note of at most 500 characters, or null to clear it.
- `--status <value>`: Archives or reactivates the template. It cannot be set back to `draft`.
- `--expected-version <n>`: The head version number you edited from. A mismatch is a 409 `version_conflict` and nothing is written.
- `--engine <value>`: Switches between `blocks` and `html`. Switching to `html` needs `html` supplied or already stored.
- `--subject <value>`: Replacement subject, at most 998 characters and free of line breaks.
- `--document <json|@file|->`: The `blocks` body: `body` (the block tree) plus the page settings that travel with it, `preview`, `tailwind`, `fonts` and `style`. It replaces the whole document, so read the current one before rebuilding part of it. Revalidated in full. JSON shaped as `TemplateDocument`, inline or from a file with @path.
- `--html <value>`: Replacement markup for the `html` engine, at most 1,000,000 characters.
- `--slots <json|@file|->`: Complete replacement slot list. JSON shaped as `Array<Partial<TemplateSlot> & { key: string }>`, inline or from a file with @path.
- `--props <json|@file|->`: Complete replacement prop list. JSON shaped as `Array<Partial<TemplateProp> & { key: string }>`, inline or from a file with @path.
- `--data <json|@file|->`: The whole `patch` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

With optional flags

```bash
openemail templates update order-shipped --subject 'Your order {{orderId}} has shipped'
```

Print the raw JSON

```bash
openemail templates update order-shipped --subject 'Your order {{orderId}} has shipped' --json
```

Also available in: API [`PATCH /templates/{id}`](https://openemail.uk/docs/api/reference/templates#patch-templates-id); SDK [`templates.update()`](https://openemail.uk/docs/sdk/reference/templates#update).

### `openemail templates duplicate`

Copy a template into a new one

```bash
openemail templates duplicate <id-or-slug> [flags]
```

Creates a new template from the HEAD version of an existing one: the same subject, body, slots and props, and the source's description. The copy starts at version 1 as a DRAFT, whatever the source had published, so a copy is never sendable by accident. Publish it when you mean to.

The copy is a separate template with its own id and slug. Nothing links it back to the source, so editing either one afterwards leaves the other alone. This is the safe way to try a redesign of a template that is sending in production.

`name` is optional. Left out, the source name is reused, and because a name is unique per workspace the server appends a number until one is free, up to twenty attempts. Sending a name that is already taken behaves the same way, so a script that copies nightly keeps working.

- Scopes: `templates:write`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): The template to copy, by `tpl_` id or slug.

**Flags**

- `--name <value>`: The name for the copy, 1 to 100 characters. Omit it to reuse the source name with a number appended.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

The required values only

```bash
openemail templates duplicate order-shipped
```

With optional flags

```bash
openemail templates duplicate order-shipped --name 'Order shipped, new design'
```

Also available in: API [`POST /templates/{id}/duplicate`](https://openemail.uk/docs/api/reference/templates#post-templates-id-duplicate); SDK [`templates.duplicate()`](https://openemail.uk/docs/sdk/reference/templates#duplicate).

### `openemail templates replace-content`

Swap a template's design for a starter or another template's

```bash
openemail templates replace-content <id-or-slug> [flags]
```

Replaces the whole body of a template with a starter design or with another template's body, keeping the template's own identity: its id, slug, name, description and status do not move, and neither does what a live send resolves to.

The write lands exactly where an `update` to the body lands. A draft head is overwritten in place; a published head mints version N+1 as a draft. Sends keep resolving the published version until you publish, so this is safe to call on a template that is sending.

Name exactly one source. `starter` takes a slug from `listStarters`; `--from-template-id` takes another template in the same workspace, whose published version is copied when it has one and whose draft is copied otherwise. Sending both, neither, or the target itself is a 422. A source in another workspace is a 404, like everything else here.

This discards the body it replaces. A version that was published is still in the version list and can be restored, but an unpublished draft body is gone.

- Scopes: `templates:write`.
- Needs a sign-in.
- Asks you to confirm.

**Arguments**

- `<id-or-slug>` (required): The template whose design is being replaced, by `tpl_` id or slug.

**Flags**

- `--starter <value>`: A starter slug from `listStarters`. Mutually exclusive with `--from-template-id`.
- `--from-template-id <value>`: Another template in this workspace to borrow the design from, by id or slug. Mutually exclusive with `starter`.
- `--expected-version <n>`: The head version you read before replacing. A mismatch is a 409 `version_conflict` and nothing is written.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

The required values only

```bash
openemail templates replace-content order-shipped
```

With optional flags

```bash
openemail templates replace-content order-shipped --starter order-shipped
```

Skip the confirmation, for scripts

```bash
openemail templates replace-content order-shipped --yes
```

Also available in: API [`POST /templates/{id}/content`](https://openemail.uk/docs/api/reference/templates#post-templates-id-content); SDK [`templates.replaceContent()`](https://openemail.uk/docs/sdk/reference/templates#replaceContent).

### `openemail templates delete`

Delete a template and every version

```bash
openemail templates delete <id-or-slug> [flags]
```

Permanently removes the template and all of its versions. There is no undo. Mail already accepted is unaffected, because each send stores the body it rendered, but any integration still sending against this id or slug starts receiving 404s.

If you might need the template again, archive it with `update(idOrSlug, { status: 'archived' })` instead. The response is a tombstone rather than an empty body, so a log line can record exactly what was removed.

- Scopes: `templates:write`.
- Needs a sign-in.
- Asks you to confirm.
- Aliases: `rm`, `del`, `remove`.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Examples**

```bash
openemail templates delete order-shipped
```

Skip the confirmation, for scripts

```bash
openemail templates delete order-shipped --yes
```

Also available in: API [`DELETE /templates/{id}`](https://openemail.uk/docs/api/reference/templates#delete-templates-id); SDK [`templates.delete()`](https://openemail.uk/docs/sdk/reference/templates#delete).

### `openemail templates list-versions`

List one page of a template's versions, newest first

```bash
openemail templates list-versions <id-or-slug> [flags]
```

Returns one page of a template's versions, newest first. At most one version is a draft and it is always the highest number. Every version below it has been published, and the highest published version is the one unpinned sends resolve to.

Bodies are left out, so `document` and `html` are absent on every row. What each version declares (`subject`, `slots` and `props`) is present, which makes this the call for checking what pinning a `version` on `send` would commit you to.

Pages are keyset on the version number, so a version deleted while you walk never breaks the walk: the next page starts at the first version below the cursor.

Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max <n>` stops after that many items.

- Scopes: `templates:read`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Flags**

- `--limit <n>` (default `25`): Versions per page, a whole number from 1 to 100. The server defaults to 25.
- `--cursor <value>`: The `nextCursor` of the previous page, passed back as it came. It is opaque, so never build one yourself.
- `--all`: Fetch every page and stream the items as they arrive.
- `--max <n>`: Stop after this many items. Implies `--all`.
- `--ndjson`: Print every item as one JSON object per line. Implies `--all`

**Examples**

The required values only

```bash
openemail templates list-versions order-shipped
```

With optional flags

```bash
openemail templates list-versions order-shipped --limit 10
```

Walk every page and stop after 100 items

```bash
openemail templates list-versions order-shipped --all --max 100
```

One JSON object per line when piped

```bash
openemail templates list-versions order-shipped --all > templates.ndjson
```

Also available in: API [`GET /templates/{id}/versions`](https://openemail.uk/docs/api/reference/templates#get-templates-id-versions); SDK [`templates.listVersions()`](https://openemail.uk/docs/sdk/reference/templates#listVersions).

### `openemail templates get-version`

Read one version of a template, body included

```bash
openemail templates get-version <id-or-slug> <version> [flags]
```

One frozen revision with its body. `document` carries the block tree for the `blocks` engine and `html` carries the submitted markup for the `html` engine, alongside the `subject`, `slots` and `props` that were declared at the time.

This is what `listVersions` leaves out. It is the only way to read an old version without changing anything: `restoreVersion` also shows you the body, but it moves the head to get there, so reading version 3 used to cost you your draft.

Reach for it to diff a regression against the revision that worked, to lift a block out of a design you have since replaced, or to record what a campaign actually said.

- Scopes: `templates:read`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.
- `<version>` (required): The version number to read, as `listVersions` reports it. Not a `tplv_` id.

**Examples**

```bash
openemail templates get-version order-shipped 1
```

Print the raw JSON

```bash
openemail templates get-version order-shipped 1 --json
```

Also available in: API [`GET /templates/{id}/versions/{version}`](https://openemail.uk/docs/api/reference/templates#get-templates-id-versions-version); SDK [`templates.getVersion()`](https://openemail.uk/docs/sdk/reference/templates#getVersion).

### `openemail templates publish`

Publish the draft so sends resolve to it

```bash
openemail templates publish <id-or-slug> [flags]
```

Freezes the head version and makes it the one unpinned sends resolve to. Compiling happens here: a `blocks` tree is rendered through react-email and `html` markup is sanitised, so a body that does not render fails with 422 `invalid_template` for the person publishing rather than for a recipient. Nothing is published when that happens.

The call is idempotent. If the head is already the published version it comes back unchanged, so a deploy script can publish on every run. Publishing also sets the template's `status` to `active`, which reactivates an archived template.

Only the head can be published, and there is no call to republish an older version. To keep production on an earlier version while a new one is prepared, pin that `version` on `send`. The response is the published version with the updated parent attached as `template`.

- Scopes: `templates:write`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Examples**

```bash
openemail templates publish order-shipped
```

Print the raw JSON

```bash
openemail templates publish order-shipped --json
```

Also available in: API [`POST /templates/{id}/versions`](https://openemail.uk/docs/api/reference/templates#post-templates-id-versions); SDK [`templates.publish()`](https://openemail.uk/docs/sdk/reference/templates#publish).

### `openemail templates restore-version`

Bring an older version's body back as the draft

```bash
openemail templates restore-version <id-or-slug> <version> [flags]
```

Copies an older version's subject, body, slots and props forward into the head, which is how you undo a design you regret. Nothing is rolled back in place: the old version stays where it is in the list and the restored copy becomes the current draft.

Where it lands follows the usual rule. A published head mints version N+1 as a draft; a draft head is overwritten, so restoring twice does not pile up versions. Live sends do not move until you publish, so a restore is reversible until then: restore something else, or publish to commit.

Restoring the head itself is a 422, because there is nothing to bring back. An unknown version is a 404. `--expected-version` makes the call safe against a concurrent editor, the same as on `update`.

- Scopes: `templates:write`.
- Needs a sign-in.
- Asks you to confirm.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.
- `<version>` (required): The version whose body you want back, as `listVersions` reports it.

**Flags**

- `--expected-version <n>`: The head version you read before restoring. A mismatch is a 409 `version_conflict` and nothing is written.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

```bash
openemail templates restore-version order-shipped 1
```

Skip the confirmation, for scripts

```bash
openemail templates restore-version order-shipped 1 --yes
```

Also available in: API [`POST /templates/{id}/versions/{version}/restore`](https://openemail.uk/docs/api/reference/templates#post-templates-id-versions-version-restore); SDK [`templates.restoreVersion()`](https://openemail.uk/docs/sdk/reference/templates#restoreVersion).

### `openemail templates delete-version`

Delete one version of a template

```bash
openemail templates delete-version <id-or-slug> <version> [flags]
```

Removes a single revision and leaves the template itself alone. It is for tidying a long version list, not for changing what sends.

Three versions cannot be deleted, and each refusal is a 422 rather than a silent success: the LIVE version, because sends resolve it; the HEAD, because that is the one being edited, and restoring an older version first is how you move off it; and the only version a template has, because a template with no versions could not be read at all, so delete the template instead.

Everything else is fair game. Mail already sent from a deleted version is untouched, since a send stores the body it rendered, but a send that pins a deleted `version` starts failing with `template_version_not_found`.

- Scopes: `templates:write`.
- Needs a sign-in.
- Asks you to confirm.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.
- `<version>` (required): The version number to delete, as `listVersions` reports it.

**Examples**

```bash
openemail templates delete-version order-shipped 1
```

Skip the confirmation, for scripts

```bash
openemail templates delete-version order-shipped 1 --yes
```

Also available in: API [`DELETE /templates/{id}/versions/{version}`](https://openemail.uk/docs/api/reference/templates#delete-templates-id-versions-version); SDK [`templates.deleteVersion()`](https://openemail.uk/docs/sdk/reference/templates#deleteVersion).

### `openemail templates list-starters`

List the built-in starter designs

```bash
openemail templates list-starters [flags]
```

The starter designs the web editor offers, as a plain array. A starter is a ready-made block document with a subject and its declared slots and props, and it is the same catalogue the console shows, so an integration and a person building a template by hand start from the same place.

Bodies are left out here. `slug` is the handle to pass as `starter` to `create` or `replaceContent`, and `getStarter` returns one in full with its block tree and a rendered preview.

Starters are static: they are part of the product rather than workspace data, so this answer is the same for every key and changes only when a release adds one.

- Scopes: `templates:read`.
- Needs a sign-in.

**Examples**

```bash
openemail templates list-starters
```

Print the raw JSON

```bash
openemail templates list-starters --json
```

Also available in: API [`GET /templates/starters`](https://openemail.uk/docs/api/reference/templates#get-templates-starters); SDK [`templates.listStarters()`](https://openemail.uk/docs/sdk/reference/templates#listStarters).

### `openemail templates get-starter`

Retrieve one starter design, body and preview included

```bash
openemail templates get-starter <slug> [flags]
```

One starter in full: everything the list carries, plus `document`, the block tree itself, and `preview`, the starter rendered to HTML with each undefaulted prop left visible as `{{key}}`.

The preview is what the console shows in its starter picker, so a client can display the same thing without rendering anything itself. The document is there so you can seed a template from a starter and edit the tree before creating it, rather than creating from the starter and patching afterwards.

An unknown slug is a 404. Pass the slug exactly as `listStarters` reports it.

- Scopes: `templates:read`.
- Needs a sign-in.

**Arguments**

- `<slug>` (required): A starter slug from `listStarters`, such as `welcome`.

**Examples**

```bash
openemail templates get-starter welcome
```

Print the raw JSON

```bash
openemail templates get-starter welcome --json
```

Also available in: API [`GET /templates/starters/{slug}`](https://openemail.uk/docs/api/reference/templates#get-templates-starters-slug); SDK [`templates.getStarter()`](https://openemail.uk/docs/sdk/reference/templates#getStarter).

### `openemail templates list-fonts`

List the web fonts a template can load

```bash
openemail templates list-fonts [flags]
```

Every web font a template may load, as a plain array, in the order the web editor offers them. Each row names a `family`, the full CSS `stack` to write, the `fallback` a mail client shows when it cannot load the font, the `weight` range the file covers, and the `url` the file is served from.

The list is closed on purpose. A font file is fetched by the reader's mail client the moment the message is opened, so a font loaded from anywhere else would tell whoever runs that host when the message was read, whatever the workspace has open tracking set to. A template whose `webFont.url` is not the one listed here for its family is refused with 422 `invalid_template`.

Fonts are static: they are part of the product rather than workspace data, so this answer is the same for every key and changes only when a release adds one.

- Scopes: `templates:read`.
- Needs a sign-in.

**Examples**

```bash
openemail templates list-fonts
```

Print the raw JSON

```bash
openemail templates list-fonts --json
```

Also available in: API [`GET /templates/fonts`](https://openemail.uk/docs/api/reference/templates#get-templates-fonts); SDK [`templates.listFonts()`](https://openemail.uk/docs/sdk/reference/templates#listFonts).

### `openemail templates render`

Render a body that is not stored anywhere

```bash
openemail templates render [flags]
```

Compiles and renders content you pass in, without creating a template or touching one. This is what the web editor calls while somebody types, and it is the call for checking a design in CI before it becomes a template.

Everything `create` accepts as content is accepted here: `document` for the blocks engine, `html` for the html engine, plus `subject`, `slots` and `props`. `values.props` and `values.slots` fill the placeholders; anything left unfilled is rendered blank and reported in `warnings`, exactly as `preview` does for a stored template.

`mark: true` leaves every placeholder visible as `{{key}}` instead of substituting it, which is how an editor shows an author what is a variable.

- Scopes: `templates:read`.
- Needs a sign-in.

**Flags**

- `--engine <value>`: Defaults to `html` when `html` is sent and `blocks` otherwise.
- `--subject <value>`: The subject to render, at most 998 characters.
- `--document <json|@file|->`: The `blocks` body for the `blocks` engine, validated in full: `body` plus `preview`, `tailwind`, `fonts` and `style`. JSON shaped as `TemplateDocument`, inline or from a file with @path.
- `--html <value>`: The markup for the `html` engine, at most 1,000,000 characters.
- `--slots <json|@file|->`: The slots this body declares. JSON shaped as `Array<Partial<TemplateSlot> & { key: string }>`, inline or from a file with @path.
- `--props <json|@file|->`: The props this body declares. JSON shaped as `Array<Partial<TemplateProp> & { key: string }>`, inline or from a file with @path.
- `--values-props <json|@file|->`: Values for the declared props. A missing one renders blank and is reported. JSON shaped as `Record<string, unknown>`, inline or from a file with @path.
- `--values-slots <json|@file|->`: Values for the declared slots, overriding their defaults. JSON shaped as `Record<string, unknown>`, inline or from a file with @path.
- `--mark`: Leaves placeholders as `{{key}}` rather than substituting them.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

```bash
openemail templates render
```

With optional flags

```bash
openemail templates render --subject 'Order {{orderId}} is on its way' --html '<p>Hello {{customer}}, {{orderId}} left the warehouse.</p>'
```

Also available in: API [`POST /templates/render`](https://openemail.uk/docs/api/reference/templates#post-templates-render); SDK [`templates.render()`](https://openemail.uk/docs/sdk/reference/templates#render).

### `openemail templates preview`

Render a template without sending it

```bash
openemail templates preview <id-or-slug> [flags]
```

Renders a version with the values you pass and returns the subject, HTML and plain text a send with the same values would produce. Nothing is sent or recorded. Point CI at it so a broken template is caught by a test rather than by a customer.

It renders the published version unless `version` names another one, and unlike `send` it can render a draft, which is compiled on the fly. A template with nothing published needs an explicit `version`, otherwise the call is a 422 `template_not_published`. Required props are relaxed here: a missing one renders its default or an empty string, and every placeholder that ends up blank is listed in `warnings` as `unfilled_placeholder`.

The other value checks still apply. A key the version does not declare is a 422 `unknown_template_prop` or `unknown_template_slot`, and a value that is not a string, number or boolean is a 422 `invalid_template_prop`. Values of kind `url` or `image` are parsed, and anything outside http, https, mailto, tel and cid renders as `#`.

- Scopes: `templates:read`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Flags**

- `--template-version <n>`: Version to render, drafts included. Defaults to the published version.
- `--props <json|@file|->`: Values for declared props, keyed by prop key. Strings, numbers and booleans only. JSON shaped as `Record<string, unknown>`, inline or from a file with @path.
- `--slots <json|@file|->`: Overrides for slot defaults, keyed by slot key. JSON shaped as `Record<string, unknown>`, inline or from a file with @path.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

```bash
openemail templates preview order-shipped
```

Print the raw JSON

```bash
openemail templates preview order-shipped --json
```

Also available in: API [`POST /templates/{id}/preview`](https://openemail.uk/docs/api/reference/templates#post-templates-id-preview); SDK [`templates.preview()`](https://openemail.uk/docs/sdk/reference/templates#preview).

### `openemail templates get-analytics`

How one template has performed

```bash
openemail templates get-analytics <id-or-slug> [flags]
```

The engagement report the console shows on a template: how many messages it rendered in the window, how many of those were tracked, how many were opened and clicked, and the same numbers broken down by day, by source and by version.

Rates are computed against what was TRACKED, not against everything sent, because a message sent with tracking off can never report an open and counting it would quietly lower every rate. `trackedForOpens` and `trackedForClicks` are the denominators, and they are in the response so you can recompute anything yourself.

`lifetime` ignores the window: it is every live send this template has ever made, the test sends counted separately, and the first and last time it sent. `recent` previews the twelve newest sends in the window with their own open and click counts, which is the fastest way to see whether a template that was just published is behaving. It is a preview, not the list: `listSends` returns every send in the window, a page at a time.

Only live sends are in the windowed figures. A message sent with a test key counts in `lifetime.testSends` and nowhere else.

- Scopes: `templates:read`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Flags**

- `--days <n>`: How far back to look, 1 to 365. Defaults to 30. The window starts at the beginning of that day and ends now.
- `--minutes <n>`: The window in minutes, which wins over `days`. For the last hour of a send in flight.
- `--grain <value>`: How wide one `byDay` bucket is: `day`, `hour` or `minute`. The bucket keys change shape with it.
- `--offset-minutes <n>`: The reader's UTC offset in minutes, -840 to 840, so days are bucketed in their own timezone.

**Examples**

The required values only

```bash
openemail templates get-analytics order-shipped
```

With optional flags

```bash
openemail templates get-analytics order-shipped --days 7 --grain day
```

Print the raw JSON

```bash
openemail templates get-analytics order-shipped --json
```

Also available in: API [`GET /templates/{id}/analytics`](https://openemail.uk/docs/api/reference/templates#get-templates-id-analytics); SDK [`templates.getAnalytics()`](https://openemail.uk/docs/sdk/reference/templates#getAnalytics).

### `openemail templates list-sends`

The individual messages a template sent

```bash
openemail templates list-sends <id-or-slug> [flags]
```

One row per message this template rendered, newest first, with the subject as it went out, who it went to, and whether it was opened or clicked. It is the list behind the numbers `getAnalytics` reports, and the place to answer "did this person get it".

Paging here is by page number rather than by cursor, because the console shows a table with a total, and `total` is the count matching the filters rather than the size of the page. Pages are 25 rows by default and at most 100.

The filters narrow by window (`days` or `minutes`), by `version`, by `source`, and by engagement: `opened`, `clicked` and `tracked` each take a boolean. `search` matches the subject and the recipient addresses. A row whose message carried no tracking reports `matched: false` and zero counts, which is not the same as nobody opening it.

- Scopes: `templates:read`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Flags**

- `--page <n>`: Which page, from 1. Defaults to 1.
- `--page-size <n>`: Rows per page, 1 to 100. Defaults to 25.
- `--search <value>`: Matches the subject that went out and the recipient addresses.
- `--source <value>`: Only sends from one source, such as `api` or `console`.
- `--template-version <n>`: Only sends that rendered this version number.
- `--opened`: True for sends with at least one counted open, false for none.
- `--clicked`: True for sends with at least one counted click, false for none.
- `--tracked`: True for sends that carried tracking at all, false for the ones that could never report.
- `--days <n>`: How far back to look, 1 to 365. Defaults to 30.
- `--minutes <n>`: The window in minutes, which wins over `days`.
- `--grain <value>`: Only floors the start of the window, so this list can cover the same window as `getAnalytics`.
- `--offset-minutes <n>`: The reader's UTC offset in minutes, -840 to 840.

**Examples**

The required values only

```bash
openemail templates list-sends order-shipped
```

With optional flags

```bash
openemail templates list-sends order-shipped --page-size 50 --no-opened --tracked
```

Also available in: API [`GET /templates/{id}/sends`](https://openemail.uk/docs/api/reference/templates#get-templates-id-sends); SDK [`templates.listSends()`](https://openemail.uk/docs/sdk/reference/templates#listSends).

### `openemail templates send`

Send an email rendered from a template

```bash
openemail templates send <id-or-slug> --from <value> --to <a,b> [flags]
openemail templates send <id-or-slug> --data <json|@file|-> [flags]
```

Resolves the published version, or the one `version` pins, fills its placeholders from `props` and `slots`, and queues the message. Values are checked strictly here. An undeclared key is a 422 `unknown_template_prop` or `unknown_template_slot`, a missing required prop is a 422 `missing_template_prop`, and a value that is not a string, number or boolean is a 422 `invalid_template_prop`, each with `param` set to `template.props.<key>`. A template with nothing published, or a pinned version that is still a draft, is a 422 `template_not_published`. No mail leaves when any of these fail.

Pin `version` in production code. Without it every send resolves whatever is published at that moment, which changes the morning somebody publishes a rewrite. `subject` replaces the version's subject for this message only and is used exactly as written, with no placeholder filling. `--scheduled-at` takes a `Date`, an ISO 8601 instant or an ISO 8601 duration such as `PT30M`, up to 365 days out, and cannot be combined with a non zero `--cancellable-for-seconds`.

The SDK attaches an `Idempotency-Key` generated once per call and reuses it on that call's retries, so a retry replays the original message instead of sending a second one. Pass `--idempotency-key` to deduplicate across processes and restarts, and derive it from what caused the send, never from a clock. A replay resolves with `replayed: true` and the original message, while reusing a key with a different body is a 422 `idempotency_key_reuse`.

- Scopes: `templates:write`, `emails:send`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): A `tpl_` id or the template's slug.

**Flags**

- `--from <value>`: Sender as `address`, `Name <address>` or `{ email, name }`. The key must be allowed to send as it, otherwise 403 `from_address_forbidden`. Required, here or in `--data`.
- `--to <a,b>` (repeatable): 1 to 50 recipients. The SDK wraps a single value in an array. Required, here or in `--data`.
- `--cc <a,b>` (repeatable, default `[]`): Up to 50 copied recipients.
- `--bcc <a,b>` (repeatable, default `[]`): Up to 50 blind copied recipients.
- `--reply-to <value>`: Sets the Reply-To header.
- `--template-version <n>`: Published version to send. Defaults to the currently published one.
- `--props <json|@file|->`: Values for the declared props: strings, numbers or booleans, keyed by prop key. JSON shaped as `Record<string, unknown>`, inline or from a file with @path.
- `--slots <json|@file|->`: Overrides for slot defaults, keyed by slot key. JSON shaped as `Record<string, unknown>`, inline or from a file with @path.
- `--subject <value>`: Replaces the version's subject for this message, sent verbatim, at most 998 characters.
- `--scheduled-at <when>`: When to send: a `Date`, an ISO 8601 instant or a duration like `PT2H`. Must be in the future and at most 365 days out.
- `--cancellable-for-seconds <n>` (default `0`): Holds the message 0 to 900 seconds so it can still be cancelled. Defaults to 0 and is refused alongside `--scheduled-at`.
- `--tracking <json|@file|->`: Per message `opens` and `clicks` switches for open and click tracking. JSON shaped as `TrackingRequest`, inline or from a file with @path.
- `--tags <json|@file|->` (repeatable, default `{}`): Your own labels for the send, keys up to 64 and values up to 256 characters.
- `--translate <json|@file|->`: Translates the rendered message into `to` before sending, with optional `from`, `includeOriginal` (default true) and `subject` (default true). JSON shaped as `SendTranslateOptions`, inline or from a file with @path.
- `--idempotency-key <value>`: Your own key in place of the generated one: 1 to 255 characters of letters, digits, `_`, `.`, `:` or `-`.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

The required values only

```bash
openemail templates send order-shipped --from hello@example.com --to ada@example.com
```

With optional flags

```bash
openemail templates send order-shipped --from hello@example.com --to ada@example.com --template-version 5 --idempotency-key order-shipped:AC-4192
```

Read the whole body from a JSON file

```bash
openemail templates send order-shipped --data @template.json
```

Also available in: API [`POST /templates/{id}/send`](https://openemail.uk/docs/api/reference/templates#post-templates-id-send); SDK [`templates.send()`](https://openemail.uk/docs/sdk/reference/templates#send).

### `openemail templates list-images`

List one page of template images

```bash
openemail templates list-images [flags]
```

Resolves one page of the images uploaded for templates, newest first: the library the template editor offers when you add an image.

Template images belong to the workspace: every template in it can use them, and they stay at their address after the template that first used them is deleted.

Add `--all` to walk every page: a table on a terminal, one JSON object per line when piped or with `--ndjson`, and one `{ items, hasMore, nextCursor }` document with `--json`. `--max <n>` stops after that many items.

- Scopes: `templates:read`.
- Needs a sign-in.

**Flags**

- `--limit <n>` (default `24`): Page size, from 1 to 120. The server defaults to 24.
- `--cursor <value>`: The `nextCursor` of the previous page. Leave it out for the first page.
- `--all`: Fetch every page and stream the items as they arrive.
- `--max <n>`: Stop after this many items. Implies `--all`.
- `--ndjson`: Print every item as one JSON object per line. Implies `--all`

**Examples**

```bash
openemail templates list-images
```

With optional flags

```bash
openemail templates list-images --limit 10
```

Walk every page and stop after 100 items

```bash
openemail templates list-images --all --max 100
```

One JSON object per line when piped

```bash
openemail templates list-images --all > templates.ndjson
```

Also available in: API [`GET /templates/images`](https://openemail.uk/docs/api/reference/templates#get-templates-images); SDK [`templates.listImages()`](https://openemail.uk/docs/sdk/reference/templates#listImages).

### `openemail templates upload-image`

Upload an image for templates

```bash
openemail templates upload-image <data> [flags]
```

Sends the image bytes as the request body and resolves with its public `url`, ready to put in a template. It is the upload of the template editor.

PNG, JPEG, WebP, GIF or SVG, up to 5 MB, fitted into 1200 by 1800 pixels and stored in a form every mail client shows. The type is read from `--content-type`, or from a `Blob`'s own type when that is left out, and without either the server refuses the bytes with 422 `invalid_image`.

Template images belong to the workspace: every template in it can use them, and they stay at their address after the template that first used them is deleted.

- Scopes: `templates:write`.
- Needs a sign-in.

**Arguments**

- `<data>` (required): The image: a `Blob`, `ArrayBuffer` or `Uint8Array`.

**Flags**

- `--content-type <value>`: `image/png`, `image/jpeg`, `image/webp`, `image/gif` or `image/svg+xml`. Required unless `data` is a `Blob` with a type.

**Examples**

The required values only

```bash
openemail templates upload-image ./photo.jpg
```

With optional flags

```bash
openemail templates upload-image ./photo.jpg --content-type image/png
```

Also available in: API [`POST /templates/images`](https://openemail.uk/docs/api/reference/templates#post-templates-images); SDK [`templates.uploadImage()`](https://openemail.uk/docs/sdk/reference/templates#uploadImage).

### `openemail templates design`

Design a new template from a brief

```bash
openemail templates design --name <value> --brief <value> [flags]
openemail templates design --data <json|@file|-> [flags]
```

A designer builds a new block template from a written brief, the way the assistant in the app does, and saves it, as a draft unless `publish` is true. It uses every block the editor has, with a palette, type and spacing, and the result opens in the visual editor fully editable.

Put everything the design must hold in `brief`: what it is for, the sections in order, the words, the colours and fonts, and which values change per recipient. `starter` builds on a starter design, and `--image-file-ids` places up to ten uploaded or received images. It spends one AI action and can take up to a minute.

- Scopes: `templates:write`.
- Needs a sign-in.

**Flags**

- `--name <value>`: A short name for the template. When the name is taken, a free one is chosen and returned. Required, here or in `--data`.
- `--brief <value>`: Everything the design must hold and look like, up to 8,000 characters. Required, here or in `--data`.
- `--description <value>`: One line about what it is for.
- `--starter <value>`: The slug of a starter design to build on, from `listStarters`.
- `--image-file-ids <a,b>` (repeatable): Up to ten file ids of images to place in the design.
- `--publish`: Publish it at once so it can be sent. Defaults to false.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

```bash
openemail templates design --name 'Spring launch' --brief 'A launch email for our spring collection: a hero image, three product cards and a button to the shop. Green and cream, friendly tone.'
```

Read the whole body from a JSON file

```bash
openemail templates design --data @template.json
```

Also available in: API [`POST /templates/design`](https://openemail.uk/docs/api/reference/templates#post-templates-design); SDK [`templates.design()`](https://openemail.uk/docs/sdk/reference/templates#design).

### `openemail templates redesign`

Change a template’s design from instructions

```bash
openemail templates redesign <id-or-slug> --instructions <value> [flags]
openemail templates redesign <id-or-slug> --data <json|@file|-> [flags]
```

A designer applies written instructions to a block template and leaves everything else alone: restyle it, change colours, fonts or spacing, rewrite or translate its copy, add, move or remove sections, swap an image. The change lands in the draft, so live sends keep the published version until you publish.

A raw HTML template cannot be redesigned and is refused with 422 `invalid_template`. It spends one AI action.

- Scopes: `templates:write`.
- Needs a sign-in.

**Arguments**

- `<id-or-slug>` (required): The template's id or slug.

**Flags**

- `--instructions <value>`: What to change, with every detail: the words, colours and which section. Up to 8,000 characters. Required, here or in `--data`.
- `--image-file-ids <a,b>` (repeatable): Up to ten file ids of images to use.
- `--expected-version <n>`: The version you based the change on. A newer one is refused with 409 `version_conflict`.
- `--data <json|@file|->`: The whole `body` as JSON, inline, from a file with @path, or - for standard input. Flags override its keys.

**Examples**

```bash
openemail templates redesign spring-launch --instructions 'Make the button orange and translate the copy into Spanish.'
```

Read the whole body from a JSON file

```bash
openemail templates redesign spring-launch --data @template.json
```

Also available in: API [`POST /templates/{id}/redesign`](https://openemail.uk/docs/api/reference/templates#post-templates-id-redesign); SDK [`templates.redesign()`](https://openemail.uk/docs/sdk/reference/templates#redesign).
