An embeddable email builder for your ESP or email marketing platform
If you run an email service provider or an email marketing platform, the campaign editor is the part of your product your customers touch every day — and the part you least want to build from scratch or rent forever. BuilderJS is the drag-and-drop email builder you embed inside your own dashboard. It is a framework-agnostic, vanilla-JavaScript library (roughly 140KB gzipped) that mounts in any DOM node, in React, Vue, Svelte, Angular, Next.js, Laravel, or plain HTML. Crucially, it is the editor, not a competing platform: BuilderJS does not send email, manage lists or subscribers, run automations, track opens and clicks, or handle deliverability. That whole layer — the actual product you sell — stays yours. Your customers design a campaign on the embedded canvas, you call getData() to capture lossless JSON, and you render Outlook-safe HTML through the export pipeline to hand to your own sending engine. You buy it once under a one-time CodeCanyon license (item 27146783), receive the source, and self-host the bundle from your own origin. No SaaS subscription, no per-seat fee, no usage metering, and nothing phoning a vendor — so the editor cost never scales with your customer count the way an SDK-by-subscription would.
Mount it
// BuilderJS ships as a global window.Builder script (dist/builder.js +
// dist/builder.css self-hosted from your origin) — there is NO npm package.
// A thin, self-owned React wrapper for your ESP dashboard:
import { useEffect, useRef } from 'react';
export default function CampaignEditor({ themeJson, themeTemplates, themeConfig, mediaUrl, onSave }) {
const mounted = useRef(false);
const builderRef = useRef(null);
useEffect(() => {
if (mounted.current || !window.Builder) return; // React 18 Strict-Mode guard
mounted.current = true;
builderRef.current = new window.Builder({
mainContainer: '#bjs-canvas', // REQUIRED — CSS selector string
widgetsContainer: '#bjs-widgets', // optional
settingsContainer: '#bjs-settings', // optional
});
// load(themeJson, themeTemplatesJson, themeConfigData, mediaUrl) — 4 positional args
builderRef.current.load(themeJson, themeTemplates, themeConfig, mediaUrl);
// No destroy()/dispose() exists — React discards the DOM on unmount.
}, []);
// Persist: capture lossless JSON, POST to YOUR backend. BuilderJS never sends.
const handleSave = () => onSave(builderRef.current.getData());
return (
<>
<div id="bjs-widgets" />
<div id="bjs-canvas" />
<div id="bjs-settings" />
<button onClick={handleSave}>Save campaign</button>
</>
);
}
The editor, not a second platform inside your platform
This is the distinction that matters most for an ESP. An embeddable email builder should give your users a place to design — and stop there. BuilderJS does exactly that: a visual canvas with 42 element types, 59 property controls, and 31 editing overlays so a marketer can lay out a newsletter, a promo, or a re-engagement email without touching a table cell. It does not send the campaign, schedule it, segment a list, suppress a bounce, or measure a click. Those are your product. A clean way to picture the split: BuilderJS is where the email is born; your platform is where it is targeted, sent, and measured. Keeping the editor a pure design surface means it never duplicates or fights the features you already sell, and it never tries to own your subscriber data. You embed a builder, not a rival dashboard.
Outlook-safe campaign HTML your sending engine can trust
Bulk campaign mail lives or dies on rendering across fussy inboxes, so the editor your platform embeds has to emit HTML that survives them. BuilderJS ships a dedicated EmailExportPipeline that turns the modern editor canvas into email-client-safe HTML: flexbox and grid layouts are rewritten to nested tables with role=presentation, SVG icons rasterize to PNG, @media rules drive mobile stacking, MSO conditional comments and ghost tables handle Windows Outlook, fluid images get max-width:100%;height:auto, and a CSS inliner pushes every safe declaration onto its element. The bundled 30+ templates and 200+ samples have been Litmus-tested across 22 email clients, so your customers start from layouts already proven to render. The same canvas can also emit clean, standalone page HTML when your platform needs a hosted landing page or a browser-view version of a campaign — one editor covering both jobs. Final-mile rendering still depends on your sending path and the recipient's client, so test your own templates as part of your pipeline.
JSON-first campaigns are data your platform already knows how to store
Every design round-trips through getData() and load() with no loss, so a saved campaign is just JSON your backend stores, versions, and diffs like any other record. For an ESP that is exactly the right shape: keep a template per brand or per locale, branch a variant for an A/B test that your own engine runs, snapshot the design at send time for audit, or roll back a bad edit — all in your database, with the JSON as the system of record. You merge personalization tokens, merge tags, and per-recipient variables into the exported HTML inside your own sending code, where your subscriber data and auth already live, not in the editor. Because the schema is plain JSON and the export step is deterministic, you can regenerate every customer's campaign HTML in a batch when you ship a new footer or compliance block, without re-opening a single design by hand.
Embed it once in the stack you already run — and white-label it
BuilderJS is a DOM-mount bundle — dist/builder.js plus dist/builder.css — not a published npm component, so it drops into any framework identically. You self-host the two files from your own origin and the script attaches a global window.Builder; you instantiate it client-side inside your framework's mount hook (useEffect in React, onMounted in Vue) by passing CSS selector strings to the containers — mainContainer is required, widgetsContainer and settingsContainer are optional. Persist by calling getData() and POSTing the JSON to your own route; the download ships reference PHP backends for save, upload, and auth against MySQL, SQLite, or S3 — code you copy and own, portable to Node, Go, or Python. Because you own the source you can theme the chrome to look like your product, not a third party's, and localize with 20+ bundled locales including RTL. The architecture is multi-tenant capable through closure-captured configuration, so a fresh instance per customer or per workspace is straightforward — but your platform keeps owning tenant isolation, seats, and billing. BuilderJS imposes none of its own.
Own the editor outright — no per-seat tax on your growth
For a platform business, the editor's pricing model is a margin decision. A subscription email-SDK charges you monthly, often scaling with seats, sends, or active editors — a recurring tax that grows with your own success. BuilderJS is sold under a one-time CodeCanyon license (item 27146783) in Regular ($52) and Extended ($99) tiers. You receive the source, self-host it, and there is no SaaS subscription, no monthly fee, no per-seat charge, no usage metering, and no phone-home — your customers can author unlimited campaigns without a counter ticking against your costs. Compared with assembling your own from parts: MJML is excellent and MIT-licensed for free commercial use (github.com/mjmlio/mjml, as of June 2026), but it is a markup compiler, not a finished visual editor — you would still build the drag-drop UI, the controls, and the round-trip JSON layer around it. BuilderJS gives you that finished editor for email and pages in one supported library. Note author support is time-boxed (roughly 6 to 12 months). Try the live demo at builder.emotsy.com before you buy.
Frequently asked questions
-
Does BuilderJS compete with my ESP — does it send or track campaigns?
No. BuilderJS is the embedded editor only. It builds the campaign and exports Outlook-safe HTML, but it does not send mail, manage lists or subscribers, run automations, schedule sends, or track opens and clicks. That entire layer — the product you actually sell — stays yours. Your customers design in the embedded canvas; your platform handles targeting, delivery, and analytics. You embed a builder, not a rival platform.
-
How do I handle merge tags and personalization for bulk sends?
Design templates with your placeholder syntax, then merge real values into the exported HTML inside your own sending code, where your subscriber data and auth already live. BuilderJS round-trips the design as lossless JSON via getData() and load(), so you store each campaign as data, regenerate HTML deterministically, and inject per-recipient variables at render time in your backend — never in the editor itself.
-
Is there a per-seat or per-send fee as my customer base grows?
No. BuilderJS is a one-time CodeCanyon purchase (item 27146783) in Regular ($52) and Extended ($99) tiers. You own the source, self-host the bundle, and there is no monthly fee, no per-seat charge, no usage metering, and no phone-home. The editor cost does not scale with how many customers or campaigns you have. Any per-email cost in your stack comes from your own sending infrastructure, not from BuilderJS. Author support is time-boxed (roughly 6 to 12 months).
-
Will campaigns render correctly across Outlook, Gmail, and Apple Mail?
That is the job of the EmailExportPipeline: it rewrites flexbox and grid to nested tables, rasterizes SVG to PNG, adds @media mobile stacking, emits MSO conditional comments and ghost tables for Outlook, and inlines CSS. The bundled 30+ templates and 200+ samples were Litmus-tested across 22 email clients. Your final-mile rendering still depends on your sending path and the recipient's client, so test your specific templates as part of your pipeline.
-
Can I white-label the editor and run it per customer?
Yes. You own the source, so you can theme the chrome to match your product and localize it with 20+ bundled locales including RTL. The architecture is multi-tenant capable through closure-captured configuration, so spinning up a separate instance per customer or workspace is straightforward. Your platform keeps owning tenant isolation, seats, and billing — BuilderJS does not impose its own.