Embeddable editor

The email editor that runs from your infrastructure.

Your users build emails without leaving your product. You serve the bundle from your own origin, and the editor posts to the endpoints you configure. What the browser asks for falls into four classes: the bundled assets you host; the endpoints you configure; user-supplied media, which is any image URL a user pastes plus a Video block's thumbnail from YouTube; and requests to the editor vendor, of which the standard build makes none.

Early access. Try the editor right now — no account, no address, nothing to install.

Try the editor See the embed code Pricing

This is the real editor

Not a video and not a screenshot — the same editor the embed would ship, and finished enough to judge. Drag a block in from the left, click any text to edit it, then export the HTML. Nothing you type is saved or uploaded. Adding a Video block loads its thumbnail from YouTube, and an Image block loads whatever URL you paste.

The embed

One module and one mount call. No framework adapter, because there is nothing to adapt to — it is a DOM element and a function.

The snippet below is close to the interface as built. The mount call and the save endpoint are real; the block list is not, and passing it throws rather than dropping it in silence. 

<div id="editor"></div>

<script type="module">
  // Served from your own origin. There is no CDN to trust.
  import { mount } from "/vendor/editor/editor.js";

  mount("#editor", {
    // Your endpoint. The document is POSTed to the URL you configure.
    save: "/api/campaigns/42",

    blocks: ["heading", "text", "image", "button", "gallery"],
  });
</script>

  • Framework-agnostic

    An element and a function call. The demo above loads that way today — a module import and one call, from a plain HTML page. React, Vue, Rails, Django: the editor does not know or care what is around it.

  • Customer-hosted bundle

    The bundle loads by relative path, from whatever origin serves the page — that is how the demo above loads, with no vendor address baked in. Content would go to the endpoints you configure; the standard build has no path that sends it to us. Media a user supplies is a separate request class; the four classes are listed at the top of this page.

  • Built for email clients, not browsers

    Table-based HTML with VML buttons and the MSO head — the export above is the same code path your users would ship. That is the technique and not yet the result: this export has not been through Litmus or a real client, so there is no rendering matrix to show you.

The embed package is not available yet — that is what the form at the bottom of this page is for.

Images

An image in an email is an address, and that address has to resolve from wherever the recipient opens the mail — a different network from the one the author was on. That is the part of the job the editor does not do. It decides which image an author picked and writes that reference into the export; your system decides where the file actually lives and whether a recipient can reach it.

Today the editor takes the narrow end. An author picks one of the sample images the demo ships, or types a URL into the Image or Banner panel, and the export resolves it against the address the page was served from. The editor has no file picker, no upload path, and no asset library; dragging an image file in from the desktop does not add it. The export lists its image addresses in a comment at the top of the file and says to re-host them.

The wider end is open. A callback that hands the file to your storage, a picker that reads the asset library you already have, an import through a proxy you control, or an export that emits a manifest for your sending system to attach — those are different products for different systems, and which one is worth building is what we want to hear from you.

Pricing

There is nothing to buy yet, and no price list here. What is settled is the runtime: the standard build sends no telemetry to us, so there is no usage count arriving here to meter you on. What is not settled is the licensing structure — an annual production license, a monthly plan, a perpetual license plus maintenance — and that is a conversation to have with the first design partners rather than a number to publish ahead of them.

Request a design-partner build if you want to be part of that conversation.

Request a design-partner build

There is no build to hand out yet — that is what this is for. The questions below are the ones that decide what gets built and in what order: what you build emails with today, when a project would need this, and the constraints it would have to survive. Most of them are a choice from a list rather than something to type.

Where we would write back. A personal address is fine if it is the one you use for work.

The product is the useful half: it tells us what the editor would be sitting inside.

What you would be replacing, or working beside. If it is something else, name it in the last answer.

When would this go into a product?

Whether there is a real project, and roughly when, is what decides who we talk to first.

Where would documents and images have to live?

Different answers here are different products to build, not different settings. The Images section above is the longer version of why.

Is the editor allowed to make network calls to its vendor?

Which calls are prohibited, and by whom, changes what the standard build has to be.

Does authoring have to work without internet access?

A policy and an outage that cost you something are different requirements, so the options separate them.

A sentence is enough, and this is the one we read first. If you picked “Something else” above, this is a good place to name it.

Budget (optional)

Not a step toward a quote — the Pricing section above is where that stands. This tells us whether a paid pilot is a conversation you could have, and it is the one question here you can skip.

The form posts to this origin, like everything else on this page: no form service in the middle. We keep what you send for up to 400 days after your last submission, and use it to decide who to talk to and to write to you. Reply to anything we send and we will delete it.