Mailing templates

Available on Starter, Basic, Professional, and Unlimited plans

Reusable email layouts — save once, send many. Templates store the subject, body (HTML or builder state), and a name; anyone with access can pick one from the compose picker or fire it via the API.

Where to manage them

/mailing/templates — sortable table with columns:

• Name
• Subject (default — overridable per send)
• Last used (most-recent first by default)
• Updated
• Actions — Use in compose / Edit / Delete

The Use in compose button links to /mailing/compose?templateId=<id>. The compose page pre-fills subject + body and bumps the template's LastUsedAt so frequently-used templates float to the top of the picker.

Creating a template

Two entry points:

From the templates list

/mailing/templates/create opens the dedicated editor. Choose between:

• Builder tab — drag-and-drop blocks (see Visual email builder)
• HTML tab — raw HTML editor

Fill in:

• Name (required, unique per scope)
• Description (optional — shown in the picker)
• Default subject (required)
• Body — Builder or HTML

Click Save. The template appears in the list immediately.

From compose

While composing, click Save as template in the message-card header. A modal asks for name + description; on save, the current draft (subject + body + Builder state) becomes a template. The user stays on the compose page so they can keep editing.

Using a template

On /mailing/compose:

1. Click the templates picker icon in the message-card header.
2. The dropdown shows all your templates sorted by LastUsedAt (most recent first).
3. Pick one — subject + body load instantly. If the template has Builder state, the Builder tab opens automatically.
4. Edit the loaded content as you would any draft.
5. Send.

The template's LastUsedAt is bumped on load so it floats to the top next time.

Sending via API

For automation — Zapier workflows, scheduled scripts, etc.:

POST /api/mailing/templates/{id}/send
X-Api-Key: fli_...
Content-Type: application/json

{
  "recipients": [
    { "email": "alice@example.com", "name": "Alice" }
  ],
  "segmentId": null,
  "groupIds": []
}

Recipient sources (any combination, deduped by email):

• recipients — explicit list
• segmentId — match list from a saved segment
• groupIds — members of one or more contact groups

Response:

{ "mailingId": "...", "totalRecipients": 142, "status": "queued" }

The mailing enters the queue with Status=queued; MailingSenderService picks it up on the next 10s sweep.

Builder state vs raw HTML

A template stores both:

• Rendered HTML — what the sender pipeline ships to recipients
• Builder state (optional, JSON) — the GrapesJS internal model that lets the canvas reopen with every block intact

Templates created via the Builder save both. Templates created in the HTML tab save only the HTML — re-opening shows them in the HTML tab, not the builder. You can later open an HTML-only template, paste the HTML into the Builder tab, restructure, and save again with the new builder state.

Worked example — newsletter five team members reuse

Goal: marketing builds a monthly newsletter; every team member can send the next issue from the same layout.

1. Marketing builds the layout with the Builder, saves as template Monthly newsletter.
2. Anyone on the team opens compose, picks the template from the dropdown, edits the headline and body blocks, sends.
3. Or fire it from a Zapier workflow with POST /api/mailing/templates/{id}/send.
4. Result: monthly newsletter takes 4 minutes instead of 40, brand stays consistent across senders.

Related

• Visual email builder — drag-and-drop templates
• Drip campaigns — sequences using templated steps
• Bulk APIs and subscribe widget — full API surface