Skip to main content

Transactional Emails

Transactional emails are triggered programmatically for individual users—order confirmations, password resets, account notifications, and other time-sensitive communications.

Transactional vs Marketing

Examples of transactional emails:
  • Order confirmation
  • Shipping notification
  • Password reset
  • Account verification
  • Payment receipt
  • Security alert

Sending Modes

Create reusable templates in the dashboard, send via API using the template slug.
Benefits:
  • Non-developers can edit templates
  • Consistent branding
  • Version control in dashboard
  • Analytics per template
  • Template blocks can include conditional display rules based on recipient variables
  • Repeat blocks can render one child block set per item in an array variable

Dynamic Array Data

Transactional templates can repeat blocks over arrays passed in variables. For example, a repeat block with source items and item alias item renders its child blocks once per item. Inside those children, use scoped merge tags like {{item.title}}, {{item.description}}, and {{item.number}}.

Nested Repeats

Repeat blocks can be nested. Point the inner repeat block’s source at an array inside each parent item using the parent’s item alias - it does not need a separate top-level array. For example, with an outer repeat over orders (alias order), an inner repeat with source order.lineItems (alias line) renders once per line item of the current order, and its children can use merge tags like {{line.title}}.

Conditional Blocks

Conditional (if/else) blocks show one set of blocks when a rule matches and an optional fallback otherwise. In the editor, add a condition and pick the Custom variable field to branch on a value passed in your request variables or an automation event payload - not just stored subscriber data. The variable name is the same reference you would use in a {{merge tag}}, so nested paths work too (for example order.total or event.plan). You can match with equals, contains, numeric comparisons (>=, <=, >, <), or check whether the variable is present with “is empty” / “is not empty”. For example, sending with "variables": { "plan": "pro" } will render the IF branch of a condition like plan equals pro, and the OTHERWISE branch for any other value. Conditions can also target stored subscriber data - segment membership, custom events, tags, lists, status, engagement, and purchases. These rules are checked against the recipient’s subscriber profile at send time; if the recipient is not a stored subscriber, they see the OTHERWISE branch.

2. Direct Mode

Send email content directly without a pre-created template.
Use cases:
  • Dynamic content generated by your app
  • One-off emails that don’t need templates
  • Testing and development
  • React Email templates (see below)

3. React Email Mode

Build type-safe, responsive email templates using React Email components and render them to HTML.
Benefits:
  • Type-safe templates with TypeScript
  • Reusable components
  • Responsive design built-in
  • Preview emails during development

4. SMTP Template Payloads

If another product can send through SMTP but lets you control the message body, you can point it at Sequenzy SMTP and send a JSON payload that references one of your existing transactional emails. This is useful for products such as Supabase Auth, where Supabase still triggers the email but Sequenzy renders and sends the final template. Requirements:
  • A Sequenzy API key for SMTP authentication
  • At least one sender profile on a verified sending domain
  • A transactional email with a sender profile assigned
You can also use transactionalId instead of slug. If Sequenzy receives a JSON body in this format over SMTP, it ignores the raw email subject/body and sends the saved transactional template instead. For the full Supabase setup, including variable mapping, see the Supabase integration guide.

Framework Quickstarts

See our quickstart guides for Bun, Next.js, and Express.

Creating Templates

In the Dashboard

  1. Go to Transactional in your dashboard
  2. Click Create Template
  3. Enter a slug (URL-friendly identifier)
  4. Design your email with the visual editor
  5. Add variable placeholders where needed
  6. Save and activate

Template Slugs

Slugs are unique identifiers for your templates:
Slugs are auto-generated from the template name but can be customized. They cannot be changed after creation.

Variables

Variables let you personalize transactional emails.

Syntax

With Defaults

Provide fallback values for missing variables:
If FIRST_NAME or firstName is empty, “Customer” is used. If a variable has no default and no value is provided, it renders as an empty string. The transactional email is still sent.

Conditional HTML Sections

Use {{#if variable}}, {{else}}, and {{/if}} to render simple conditional sections in raw HTML. This is most useful with subscriber custom attributes:
{{#unless variable}}...{{/unless}} is also supported. Conditions check whether the resolved variable is present and truthy. Nested if/unless sections are supported, but helpers, comparisons, loops, and arbitrary Handlebars expressions are not.

System Variables

These variables are resolved at send time:
For REST API sends, pass name values in variables when you want to use them. Saved subscriber names are not automatically backfilled into FIRST_NAME, LAST_NAME, or NAME.

Custom Attributes

Any subscriber custom attributes are available:

Passed Variables

Variables passed in the API request:

API Reference

Send Email

Template mode:
Direct mode:
The REST API keeps slug and body as the canonical fields. For compatibility with MCP-style callers, templateId is accepted as an alias for the transactional API slug and html is accepted as an alias for body. If both a canonical field and its alias are provided, their values must match. Response:

List Templates

Response:

Get Template Details

Response:

Auto-Creation

When you send to an email that doesn’t exist:
  1. A new subscriber is created automatically
  2. Status is set to active
  3. Custom attributes from variables are saved (if applicable)
This makes integration seamless—no need to create subscribers first.

Error Handling

Common Errors

Response Codes

Best Practices

1. Use Templates

Templates are easier to maintain and update:

2. Handle Variables Gracefully

Always provide defaults for optional variables, or guard larger optional sections with conditionals:
Conditional sections support if, unless, and else. They do not support comparisons or custom helpers.

3. Log Job IDs

Save the returned job ID for debugging:

4. Use Meaningful Slugs

5. Test in Development

Use test emails before production:

Integration Examples

Order Confirmation

Password Reset

Welcome Email

API Reference

Full API documentation

Subscribers

Auto-creation and attributes

Campaigns

Broadcast marketing emails

Sequences

Automated email workflows