How is this different from a marketing-tool template editor?

Marketing-tool editors assume a single broadcast, a sender identity that matches your brand, and an audience you sync. The transactional-email CMS assumes the same template will render millions of times against different payloads, with tenant-specific branding resolved at render time. The data flow is the opposite direction.

Do I keep the MJML, or is this proprietary?

The output is standard MJML at every step. You can export any template as MJML and ship it elsewhere. The else.events-specific surface is the editor, the block system, the version history and the rendering pipeline — not the output format.

How does versioning work?

Every save is a version, scoped to the template (or block, or variant). The dashboard shows a diff and a one-click rollback. Versions are immutable; rolling back creates a new version pointing at the older content, so the audit trail stays linear.

What about locale fallback?

Locale is resolved per send. Missing translations follow a fixed chain (locale → workspace default → empty), so you will never ship an email with a literal placeholder. The fallback is deterministic and visible in the editor during dry-run.

Content management for product emails

A CMS for transactional emails

Manage MJML templates, reusable blocks, versions, locales and tenant branding outside your app — while your product keeps sending emails from events.

Get your API key See the editor model

Why transactional email templates outgrow your codebase

Templates in /emails turn into a maintenance load

Thirty MJML files, a shared header that nobody refactored, copy changes that need a deploy. Familiar.

Marketing tools are campaign-first

Mailchimp-style editors assume a one-off broadcast. They are not built to render the same template millions of times against different payloads.

Email APIs are send-first

Postmark, Resend and SES focus on delivery. Template versioning, locale fallback and block inheritance are usually left to you.

Drift between code, design and copy

Designers want previews. Marketing wants to edit copy. Engineering wants a deploy story. Everyone wants the audit trail.

else.events is content-first, rules-first, render-first

Templates, blocks, variants and locales live behind a content API. Your app posts events, the renderer assembles the right MJML at request time.

Visual MJML editor

Outline tree, live preview, property pane. Compiles to MJML on save — renders consistently across Outlook, Gmail and Apple Mail.

Reusable blocks with live inheritance

Headers, footers, CTAs as first-class blocks. Edit one, every template that references it updates the next time you POST an event.

Versions, variants and locales

Every save is a version with diff and rollback. Variants for seasonal copy. Deterministic locale fallback so you never ship an empty body.

Migration from existing MJML

Drop your existing /emails files into the editor source view, then refactor shared parts into blocks one at a time. No big-bang migration.

Frequently asked questions

How is this different from a marketing-tool template editor?: Marketing-tool editors assume a single broadcast, a sender identity that matches your brand, and an audience you sync. The transactional-email CMS assumes the same template will render millions of times against different payloads, with tenant-specific branding resolved at render time. The data flow is the opposite direction.
Do I keep the MJML, or is this proprietary?: The output is standard MJML at every step. You can export any template as MJML and ship it elsewhere. The else.events-specific surface is the editor, the block system, the version history and the rendering pipeline — not the output format.
How does versioning work?: Every save is a version, scoped to the template (or block, or variant). The dashboard shows a diff and a one-click rollback. Versions are immutable; rolling back creates a new version pointing at the older content, so the audit trail stays linear.
What about locale fallback?: Locale is resolved per send. Missing translations follow a fixed chain (locale → workspace default → empty), so you will never ship an email with a literal placeholder. The fallback is deterministic and visible in the editor during dry-run.

A CMS sized for transactional traffic

Drop a few templates into the editor, refactor the shared parts into blocks, ship a footer change in one place. See if the model fits before you commit.

Free during public beta
Standard MJML output
Versions and locale fallback included