Publish workflow

POST .../publish, inline CSS, and unpublish.

Publishing locks a template version for production use and prepares HTML for email clients.

Publish a version

POST /templates/{templateId}/versions/{versionId}/publish
Authorization: Bearer <accessToken>
X-Tenant-Id: clxxxxxxxx

Requires dashboard JWT (template management is not available via API key today).

What happens on publish

Inline CSS — external <style> blocks and linked stylesheets are inlined into HTML attributes where possible. This improves rendering in clients that strip <head> styles (Gmail, Outlook).
Status changes from Draft to Published. Any previously published version of the same template is archived automatically — there is always at most one published version.
The version ID becomes valid for templateVersionId in POST /emails/send and campaigns.

{
  "id": "clxversion...",
  "status": "PUBLISHED",
  "publishedAt": "2026-06-30T10:00:00.000Z"
}

Unpublish

Publishing is append-only: a published version is immutable — you can't edit it in place (the API returns VERSION_NOT_DRAFT). To change a live template, create a new draft version, edit it and publish; publishing archives the previous version.

Unpublishing moves a published version to Archived (not back to Draft), so it is no longer selectable for new sends:

POST /templates/{templateId}/versions/{versionId}/unpublish

Active sends already queued are not affected; new sends must use another published version or inline htmlBody.

Recommended workflow

Edit draft  →  Preview  →  Publish (archives the previous)  →  Send with templateVersionId
    ↑                                                              |
    └────────── Create a NEW draft version to change ─────────────┘

Inline CSS notes

Prefer simple, email-safe CSS (tables, inline-friendly properties).
Complex layouts (flexbox-heavy) may not inline perfectly — test with real clients.
MJML and Unlayer exports are supported via mjmlSource and unlayerDesign fields on the version.