A template is a logical definition owned by an application. Callers address it by a template key. Display names can change. Keys should not, because send requests name the key and not a version.

A template version is the content that can be published. An email version carries a subject, preheader, HTML body, plain-text body, locale, a model-schema snapshot, and a brand binding. Bodies are Fluid templates. A model value is written as {{ orderNumber }}.

Lifecycle

Production send uses a published version.

  1. Draft. Editable. Not used by production send.
  2. In review. Submitted and waiting for approval.
  3. Approved. Allowed to be published when the key requires review.
  4. Published. The version production send selects.
  5. Archived. Kept for history. Not selected for new sends.

A published version can be paused and later resumed. A paused version is not selected.

In the portal

Open Templates. The page lists templates for the signed-in scope. Select a row to see the key, variables, and versions.

From a selected template you can:

  • Preview a render against a model JSON document.
  • Lint the template.
  • Test-send to one recipient. The test recipient and model are on the General tab.
  • Compare two version numbers.
  • Pause or resume a version.
  • Import the starter catalog, or export and import a template bundle.

Import catalog loads the product’s starter set. Export bundle downloads one template. Import bundle writes a bundle you already have. These actions call the template API. They do not replace a published version until that bundle’s publish step says so.

Creating and publishing also exist on the API if you keep templates in source control. See HTTP API for the routes. The push route, POST /api/v1/mursil/templates/push, upserts a draft from a template key, locale, subject, HTML, text, and model schema. Publishing remains a separate call.

What send selects

POST /api/v1/mursil/messages/email names templateKey and an optional locale. Mursil selects the published version for that locale. When allowLocaleFallback is true (the default), a missing locale can fall back to the template default. Set it to false when a missing translation must fail the request.

The model is validated against the schema stored on that version. A schema failure rejects the request. It does not dispatch a half-rendered body.

Locale coverage

GET /api/v1/mursil/templates/{templateId}/locale-coverage reports which locales exist. POST /api/v1/mursil/templates/{templateId}/locale-preview renders more than one locale in one call. Use those when a template must ship in several languages before you publish.