Managing Email Templates with the REST API

Email templates and their per-language versions are ordinary platform entities, so they are managed through the standard REST API v3 entity endpoints. A template holds the source-language Subject and Body; each translation is a child record.

There is no send-email endpoint in the REST API. The API writes template data; sends are triggered by automations, or by the Send Test action in the Setup UI. For how a template is localized when it is actually sent, see Email Template Localization at Send Time.

Entities

There is no child record for the source language - the parent is the source.

EmailTemplate fields

EmailTemplateLanguage fields

Endpoints

All standard entity operations apply. Entity names in the path are case-insensitive.

The same operations are available on /api/3.0/entity/emailtemplatelanguage/... for translation records.

Creating a Template with Translations

Translations can be supplied inline on create, as an embedded array:

POST /api/3.0/entity/emailtemplate
Content-Type: application/json

{
	"Name": "Welcome Email",
	"Type": "HTML",
	"Subject": "Welcome, {!Contact.FirstName}",
	"Body": "<p>Hello {!Contact.FirstName}</p>",
	"IsActive": true,
	"EmailTemplateLanguages": [
		{ "Language": "fr", "Subject": "Bienvenue", "Body": "<p>Bonjour</p>" },
		{ "Language": "de", "Subject": "Willkommen", "Body": "<p>Hallo</p>" }
	]
}

Querying templates

POST /api/3.0/query

SELECT Id, Name, Type, IsActive FROM EmailTemplate WHERE IsActive = true

MEQL string literals use double quotes. See MEQL Reference.

Validation

Two write-time transformations happen silently and are worth knowing about:

• HTML bodies are sanitized. Script, iframe, frameset and input elements and a fixed set of on* event-handler attributes are stripped; iframes are restricted to a host whitelist. This applies to the template and to every translation. Content you post back may therefore differ from what you sent.
• Tags are normalized. Split on semicolons, trimmed, first character capitalized, de-duplicated case-insensitively, and truncated to 50 characters per tag.

Permissions

• Standard per-entity Read / Create / Edit / Delete permission on EmailTemplate is enforced inside every action. Host users bypass the checks.
• Customer and Partner role types are denied outright on EmailTemplate - View, Create, Edit and Delete are all None. A token belonging to a portal user cannot read or write templates at all.
• Non-host callers cannot delete a template where IsStandard is true.
• Deleting a template cascades to all of its translations with no per-child confirmation. There is no soft delete.

Behavior to Design Around

• Type is immutable. To change a template from Text to HTML, create a new record.
• Name is not unique, but package deployment matches templates by name. Avoid duplicate names in any org you deploy to or from.
• No versioning. There is no version field or history table for templates or translations, and no staleness flag when a parent changes after its translations were written. If you need to detect drift, store your own hash of the source at translation time.
• Translations are not exposed to the chatbot tool surface. The UpsertEmailTemplate MCP tool and the generic entity tools operate on the parent EmailTemplate only, and AI-authored drafts are always written in the source language.

See More

• Email Template Localization at Send Time
• Merge Tokens and Functions Reference
• About Email Templates (Administrator documentation)

Email Template Localization at Send Time >>