Duplicate an email template

The copy's workspace-unique handle, and the stable alternative to the template ID when sending by template. It can contain lowercase letters, numbers, hyphens, and underscores. Omit it to derive one from the source (for example, welcome-email-copy), with a numeric suffix if that slug is already taken. Two prefixes are rejected: bird_, reserved for our built-in templates, and emt_, the template ID format, which a slug could never be distinguished from. If you supply a slug that is already in use in the workspace, the request returns a conflict.

Optional link to open the saved draft in the browser editor, in its default language. Absent for built-in templates.

Template ID.

The workspace that owns the template. Null for a built-in system template, which no workspace owns.

The name you send the template by. You can use either the slug or the id when you send. It never changes after the template is created. A built-in system template's slug always starts with bird_.

The template's display name, shown wherever the template is listed. You can change it any time. It defaults to the slug if you do not set one.

What the template is for, in your own words. Null if you have not set one.

Whether the template is one of our built-in templates (system) or one your workspace created (workspace).

Possible values: system, workspace

Where the template stands as a whole. The same five states on every channel.

• draft: nothing has ever gone live.
• pending: nothing is live and at least one language is in review.
• active: at least one language is live, so something can be sent.
• rejected: it was reviewed and every language was refused.
• inactive: nothing is live and nothing is in review, so content was withdrawn or was blocked before anything went live.

A template with one language live is active even while another is still drafted or refused. Read languages for the state of each language and its reason.

Which values a channel reports follows its review model. A channel whose content a third party reviews uses all five. On email and SMS, where content goes live on publish, a template is draft, active or inactive, and pending and rejected are reserved for the review stage coming to both, so a template reaching either is not a breaking change.

Possible values: draft, pending, active, rejected, inactive

Whether the template is for transactional email or marketing email.

Possible values: transactional, marketing

The authoring format the template is written in, fixed at creation. html is finished markup you provide, optionally personalized with Liquid.

Possible values (may grow over time): html

The visual theme a built-in template is designed in, or null for a template your workspace authored (which has no theme).

The current editable draft version. Null for a built-in system template, which has no draft.

The version a send resolves to, or null if the template has never been published.

Deprecated: use live_version_id instead, which carries the same value.

The draft's revision counter. Send it back on the next update to detect concurrent edits. Null for a built-in system template, which is unversioned.

Every language this template has, keyed by language tag in BCP-47 form such as en or pt-BR, each with its state. One read tells you which languages are live and which have unpublished edits, without fetching any content.

Content is not here: read a version's languages for that, one language at a time.

The language the draft defaults to. This is the language languages is keyed against while you edit, and it becomes the live version's default when you submit this draft.

Until then the live version keeps its own default, reported in live_default_language, so the two can differ. available_languages describes the live version for the same reason.

The live version's default language. While language_source_required is false, a send that names no language gets it, and a broadcast that selects no language gets the default of the published version it sends. A single send that names a language also gets it when on_missing_language is fallback and the live version stocks no form of that language, even one only the draft has added: a request for pt-BR is served by the live version's pt-BR, then by its pt or another pt variant, and only then by this default. Null if the template has never been published. A built-in system template is always published and reports the same language as default_language.

The languages this template currently supports for sending, as BCP-47 tags. Empty until the template is published, because sends serve published content. The set may shrink for reasons other than editing, so read it rather than assuming it matches what was published. A built-in system template has no publish step and always reports its one language.

What a send does when it asks for a language this template does not carry. Defaults to fallback on email.

Possible values: fallback, fail

Whether a send has to name a language. When true, a send that names none is rejected instead of being served the default language. A broadcast must select a template language when this is set.

When this template was last submitted. Null if it never has been. Submitting is the only thing that moves this timestamp: rolling back changes which version is live without counting as a submit, so this keeps reporting the last real submit. Read it alongside languages, which says where each language stands.

When the template was created. Null for a built-in system template.

When the template was last modified. Null for a built-in system template.