ReachBellDocs

Email templates

Templates let you save an email layout once and reuse it across many campaigns or transactional sends, with per-recipient variable substitution at send time. They're how you keep your brand voice consistent without rebuilding the same boilerplate on every send.

A template is a piece of HTML + a plain-text fallback + a list of merge-tag variables. When you send, the server renders the template with the subscriber's data and dispatches the result.

Why use templates?

  • Consistency. Brand colours, header, footer, button styles — defined once, applied everywhere.
  • Speed. Pick a template at the start of a campaign and skip straight to the per-send content.
  • Maintainability. Update the layout in one place and every future send picks up the change. Past sends are unaffected — the rendered HTML was stored at send time.
  • Composable. Transactional emails (POST /transactional/email) accept templateId + variables in place of htmlContent, so your application code stays clean.

Categories

When you create a template, pick a category:

  • Marketing — promotional broadcasts, newsletters, re-engagement. These respect the subscriber's preferences.channels.email opt-in and the marketing suppression list.
  • Transactional — receipts, password resets, account alerts. These bypass marketing preferences (a password reset has to go through even if the user opted out of marketing email) but still respect the dead-token and hard-bounce lists.

The category is enforced on the wire. Sending a marketing-category template to a subscriber who opted out of marketing email returns { ok: false, reason: 'opted_out' } without dispatching.

Variables

Anywhere inside the subject, HTML body, or plain-text body, write {{variable_name}} to mark a substitution point. ReachBell scans the template after every save and stores the unique variable names in variables: string[] on the template document.

Example template body:

<h1>Hi {{first_name}},</h1>
<p>Your order {{order_id}} has shipped.</p>
<p>Estimated delivery: {{eta}}.</p>
<a href="https://vedhoroscope.com/orders/{{order_id}}/track">Track it live</a>

The dashboard shows you the detected variables in a panel as you type. When you click Preview, it asks for sample values for each variable and renders the template inline with the substitutions applied.

Variable resolution happens at send time, not save time. That means you can edit a subscriber's stored attributes after launching a campaign and the next send picks up the new value. It also means an unset variable renders as an empty string — guard against this by setting a sensible default in your application code before calling the API.

Pre-built starters

Every project starts with six system-provided templates you can clone and edit:

  • Welcome — first email after subscriber signup.
  • Newsletter — clean weekly newsletter layout.
  • Order confirmation — e-commerce receipt with line items.
  • Password reset — security-flow email with a magic link.
  • Abandoned cart — single-CTA reminder with a checkout link.
  • Re-engagement — "we miss you" win-back for dormant subscribers.

Each starter is opinionated: mobile-first responsive HTML, dark-mode aware where it matters, plain-text fallback included.

Authoring a template

In the dashboard, go to Email → Templates → New template.

  1. Pick the category (marketing or transactional).
  2. Optionally load a starter as your base.
  3. Edit the subject, preheader, HTML, and plain-text. The editor highlights merge tags and lets you click any variable to insert it at the cursor.
  4. Click Preview and step through sample variable values to confirm rendering.
  5. Save.

The saved template gets a stable templateId like tmpl_welcome_v1. Use that ID to reference it from a campaign or the transactional API.

Using a template in a campaign

In the Email → Campaigns → New campaign flow, Step 1 offers a Load from template option. Pick a saved template and the subject + body get populated. Any per-campaign edits you make from that point are tracked on the campaign — the underlying template is untouched.

Using a template via the API

curl -X POST https://api.reachbell.com/transactional/email \
  -H "x-api-key: rb_live_yourkey" \
  -H "Content-Type: application/json" \
  -d '{
    "to":         "user@example.com",
    "templateId": "tmpl_welcome_v1",
    "variables":  {
      "first_name": "Mukesh",
      "order_id":   "ORD-12345",
      "eta":        "Tuesday, June 17"
    }
  }'

The server validates that every required variable in the template appears in the variables payload. Missing required variables return { ok: false, reason: 'missing_variable_<name>' } rather than rendering an empty string.

Optional template variables — ones declared with a ? suffix during authoring like {{discount?}} — are allowed to be absent.

Versioning

Templates aren't strictly versioned, but every send stores the rendered HTML on the campaign or email_events row. That means past analytics are accurate even after you edit the template — the bytes that went out are preserved.

If you need explicit versioning (legal or regulated industries often do), append a version suffix to the template name: welcome_v1, welcome_v2. Update the suffix any time you make a substantive change and reference the new ID from your application code.

What's next?