Welcome to Topol Landing Page Editor

The Landing Page Editor is in beta

Features and configuration options may still change, and you may run into rough edges. If something doesn't work as documented, contact us; feedback at this stage directly shapes the editor.

Topol Landing Page Editor is an embeddable, white-label landing page builder that drops into your application with a script tag and a configuration object. It gives your users a drag-and-drop page builder inside your product and returns the resulting page as JSON and HTML, ready to store wherever your application keeps it.

The Landing Page Editor is one of the two editors that make up Topol Plugin, alongside the Email Editor. One Topol account and API token covers both. Email Editor vs. Landing Page Editor explains how the two differ.

Topol never stores your pages. The editor loads a template you provide and returns the edited result through callbacks. Where that data lives, who may access it, and how it is versioned stays entirely on your side.

How it works

The editor ships as a loader script that renders it inside an iframe. The iframe keeps the editor's CSS and JavaScript fully separate from your application, so neither can interfere with the other.

Setup is a container element, the loader script, and a call to the LandingPageEditor() factory:

<div id="landing-page-editor" style="width: 100%; height: 100vh;"></div>

<script src="https://v1.page-assets.topol.io/topol-lpe.js"></script>
<script>
  const LPE = LandingPageEditor({
    config: {
      authorize: {
        apiKey: "YOUR_API_KEY",
        userId: "user-123",
      },
    },
    onSave(json, html) {
      // Persist the page in your own system
    },
  });

  LPE.render("#landing-page-editor");
</script>

The full walkthrough lives in Getting Started.

Authentication uses an API key restricted to the domains you register. The key is created in your Topol account and works only on the domains listed alongside it, so a copied key is useless elsewhere. See Authorization.

Embedding the editor needs no backend work. Features that persist data do: autosaves, comments, saved blocks, and image uploads to your own storage each read and write through endpoints you implement. Working with API lists them and covers the CORS configuration they need.

Controlling the editor

Two mechanisms connect the editor to your application, in a props down, callbacks up arrangement.

Options and methods send information in. Everything the editor does is configured through the config object, and the instance returned by LandingPageEditor() exposes methods for driving it at runtime: load and save for template data, plus focused calls like togglePreview, setTemplateName, refreshComments, and refreshSyncedSections. The complete list is in the methods reference.

Callbacks send information back out. Callbacks are passed as top-level properties next to config, not inside a callbacks object as in the Email Editor. onSave and onSaveAndClose deliver the page as JSON and HTML, onInit and onLoaded report editor readiness, and onAlert surfaces notifications when the built-in alerts are disabled.

Customization and white-labeling

The editor is meant to look like part of your product rather than a third-party embed. Through the configuration you can:

• Rebrand the interface with your own theme, colors, and title and fonts, and strip or trim the top bar and window bar.
• Enable or disable content blocks, and register custom blocks of your own.
• Control who may lock content through roles.
• Translate the interface or replace individual UI labels using the localization options.

Collaboration features

The editor supplies the interface for collaboration; your backend supplies the storage. Each of these features is built in and enabled through options, and each reads and writes through endpoints you implement:

• Comments add threads to sections and blocks, enabled with enableComments. The editor renders the threads and calls your conversation and comment endpoints to store them.
• Autosaves capture drafts on a timer, enabled with enableAutosaves (60 seconds by default, minimum 30). Drafts are posted to your autosave endpoint, so page history accumulates in your storage and you control how far back it goes.
• Synced sections keep a shared section (a header, a footer, a promo banner) identical across every page that uses it, stored through your saved-sections endpoint.

Storage

Pages are always yours. Page JSON and HTML are never stored, logged, or indexed by us. Saving a page renders it through Topol's API, where the template is processed in memory and the HTML returned without being retained.

Images work differently, which is worth settling before you commit to a data policy. Assets uploaded through the File Manager are stored in Topol's storage by default, under a monthly data traffic allowance. To keep them on your own infrastructure instead, point the file management endpoints at your own backend, or replace the file manager entirely with customFileManager and connect your own cloud storage, CDN, or DAM.

Who uses it

The editor suits products that need landing page design as a feature rather than as their core business:

• SaaS platforms that would otherwise build a page builder from scratch. The userId option gives each user a separate asset bucket, which fits multi-tenant applications.
• CMS and website builders where users design and publish landing pages without leaving the platform.
• Marketing tools that produce campaign pages alongside the emails that point to them.
• Enterprises and agencies producing pages at volume, using comments, synced sections, and content locking to manage review.

Next steps

Getting Started covers creating an API key and embedding the editor. Email Editor vs. Landing Page Editor explains how the two Topol Plugin editors differ.

To try it, sign up for a free trial. For questions about a specific integration, contact our team.