BuilderJS

An Embeddable, White-Label Email & Page Builder for Marketing Automation Platforms

If you build a marketing automation platform (MAP), you already own the hard parts — the sending infrastructure, the workflow engine, the segmentation, the CRM, the analytics. What your customers see first, though, is the content authoring surface: the drag-and-drop editor where they design the email or the landing page. That editor is what makes your product feel modern or dated, and it is the single most expensive piece to build well and keep maintained. BuilderJS is exactly that piece, and nothing more. It is an embeddable, framework-agnostic, vanilla-JavaScript drag-and-drop builder library — a roughly 140KB engine you mount inside your own application — that gives your users a visual editor for both HTML email and web/landing pages. It is the editor surface, not a platform: it produces the markup and the JSON, and your MAP keeps everything around it. BuilderJS does not send email, host or publish pages, run automation, manage lists, or do CRM — your platform already does all of that, and that is precisely why the fit is clean. You license the source once (a CodeCanyon one-time license, Regular $52 / Extended $99), self-host the bundle on your own origin, white-label the chrome so it looks like your product, and embed it in React, Vue, Angular, Svelte, or plain HTML. Designs round-trip as portable JSON through getData() and load(), so they live in your database, under your control — no third-party editor service sitting between your platform and your customers' content. This page explains where BuilderJS fits inside a MAP, why the editor-vs-platform split is the right boundary, and what you get versus building it yourself.

Get BuilderJS — $52 Try the builder

Mount it

import { useEffect, useRef } from 'react';
  
  // Self-owned wrapper: builder.js + builder.css are loaded from YOUR origin
  // (e.g. in index.html), which attaches window.Builder. There is NO npm import.
  // Mount this inside your MAP's campaign/page editor screen.
  export default function PlatformEditor({ savedDesign, onSave }) {
    const mounted = useRef(false);
    const builderRef = useRef(null);
  
    useEffect(() => {
      if (mounted.current) return; // guard React 18 Strict-Mode double-invoke
      mounted.current = true;
  
      builderRef.current = new window.Builder({
        mainContainer: '#bjs-canvas',       // REQUIRED — CSS selector string
        widgetsContainer: '#bjs-widgets',   // optional — your block palette
        settingsContainer: '#bjs-settings', // optional — element controls
      });
  
      // load(themeJson, themeTemplatesJson, themeConfigData, themeMediaUrl) — 4 args.
      // Pass a previously saved getData() snapshot back as the first argument.
      builderRef.current.load(savedDesign, window.THEME_TEMPLATES, window.THEME_CONFIG, window.MEDIA_URL);
      // No destroy()/cleanup — none exists; React discards the DOM on unmount.
    }, []);
  
    // Your platform owns persistence + sending + hosting.
    function handleSave() {
      const json = builderRef.current.getData(); // portable design JSON
      onSave(json); // POST to your backend; merge tokens + send/host downstream
    }
  
    return (
      <>
        <button onClick={handleSave}>Save</button>
        <div id="bjs-widgets" />
        <div id="bjs-canvas" />
        <div id="bjs-settings" />
      </>
    );
  }

Where BuilderJS fits inside a marketing automation platform

A MAP is a stack of owned systems: a sending pipeline (SMTP/ESP, deliverability, bounce handling), an automation engine (triggers, waits, branches), a data layer (contacts, lists, segments, custom fields), and reporting. The one layer that touches every customer on day one — and the one you can't get away with shipping rough — is the content editor. BuilderJS slots in as that layer and only that layer. Your users drag blocks onto a canvas to compose a campaign email or a landing page; BuilderJS hands you the design as JSON and the rendered markup as a string, and your platform takes it from there: it merges your personalization tokens, queues the send, hosts the page, or feeds the automation step. Because the boundary is a clean data handoff — getData() out, load() back in — you never have to fork your sending or automation logic to accommodate the editor. The editor is a pure authoring surface that produces content your existing systems already know how to consume. That is the whole integration: render three container divs, instantiate the engine, and read the JSON when the user saves.

Why "editor, not platform" is the right boundary for a MAP

It would be a mistake to buy an editor that tries to be a marketing platform too — you already are one, and overlap means conflict. BuilderJS is deliberately the builder component and refuses to be more. It does not send email (no SMTP, no ESP, no deliverability) — your platform does that. It does not host or publish pages (no CDN, no managed hosting) — your platform does that. It does not run funnels, automation logic, A/B orchestration, payments, or CRM — your platform does that. That restraint is the feature. You don't inherit a competing sending stack you have to disable, or a hosting layer that fights your own, or list management that duplicates your contacts table. You get a focused canvas and an export pipeline, wired into your systems through plain JSON and HTML. The result is that BuilderJS disappears into your product. Your customers experience it as your email designer and your page builder, not as a third-party widget bolted on — which is exactly what a white-label editor inside a MAP should feel like.

White-label the chrome so it's your editor, not ours

For a MAP, the editor has to wear your brand, not a vendor's. BuilderJS is built for that. You self-host builder.js and builder.css from your own origin, so there is no external runtime call to a vendor service and no logo or upsell injected into your users' workflow. The editor chrome is themeable — you control the look of the widget palette, the settings panel, and the canvas to match your product's design system, including dark mode. It ships with i18n locale packs (20+ locales, including RTL) so a multi-region MAP can present the editor in the user's language, and it is multi-tenant capable via closure-captured instances, so a single deployment can serve many of your customers with isolated editor state. Extensibility is real and done through documented registration: you register a custom Element with Builder.registerElement, and you subclass BaseWidget and BaseControl to add a palette block for your own dynamic-content tokens or a control for your merge fields — an element that maps to a feature unique to your platform. Because you extend through these APIs rather than patching the bundle, you can take library updates without re-applying a fork, and the editor becomes a genuine extension of your product rather than a generic embed.

Dual output: email HTML for the send pipeline, page HTML for hosting

Most MAPs need two kinds of content from the same authoring tool: email that survives Gmail and Outlook, and landing pages that render in a real browser. BuilderJS produces both from one editor, with the right CSS strategy for each destination. For email, the EmailExportPipeline emits Outlook-safe HTML — it converts modern flexbox/grid layouts to nested role="presentation" tables, adds MSO conditional comments and ghost tables for Windows Outlook, generates @media (max-width:600px) rules for mobile stacking, makes images fluid (max-width:100%; height:auto), rasterizes SVG to PNG, and runs a CSS inliner that pushes every safe declaration onto its element so head and external styles being stripped doesn't break the layout. The library's 30+ templates and 200+ samples are Litmus-tested across 22 email clients. For landing pages, you get clean standalone page HTML with normal cascading CSS — no pointless inlining. Your platform decides what to do with each: pipe the email HTML into your sender after merging tokens, or push the page HTML to your hosting layer. The editor handles the rendering correctness; you handle delivery.

One-time license, self-hosted source — no per-seat SaaS editor fee

The commercial model matters for a platform business. Embeddable editor SDKs that bill monthly turn your editor — a core, always-on part of your product — into a recurring cost that scales with your own growth and your own seat count. BuilderJS is sold under a one-time CodeCanyon license (item 27146783): Regular $52 or Extended $99. It is genuinely one-time — no SaaS, no monthly fee, no per-seat charge, no usage metering, and no phone-home. You own the source, self-host the bundle, and embed it in your platform under the terms of your license tier. For a MAP serving many customers, that means the editor's cost is fixed and decoupled from how many of your users design emails this month. You also keep full control of privacy and uptime: because the bundle is served from your origin and stores nothing externally, the editor has no third-party runtime dependency that could slow your app, leak your customers' content, or go down independently of your own infrastructure.

Frequently asked questions

Explore