How to Embed an Email Editor in Your SaaS

Adding an email editor to your SaaS starts with a screen. Making that screen useful requires a complete journey: open a draft, change it, leave, return and send the intended version.

Treat the integration as a document workflow. The canvas is where users work, but the surrounding decisions determine whether they trust the result.

Start with one complete user journey

Choose a real message your customers already create, such as a monthly product update. Write down who creates it, where its starting content comes from, where it is saved and who can send it. Keep audience selection and sending approval visible in that map.

Define three distinct artifacts: the editable document, a saved revision and the exported message. HTML is useful for sending; the structured document is what you reopen for editing. Saving only the export throws away the workflow you are trying to provide.

For the first integration, use one known template and one internal recipient. A small complete journey reveals more than a large block palette with no persistence.

Mount the editor with explicit context

Give the editor container a usable height and initialize it after its SDK loads. With Weavour, the documented entry point is Weavour.mount. Supply editorKey, userId, an optional organizationId, and the interface locale. Supply a saved document when reopening existing work.

Those user and organization values are declarative namespaces within the customer workspace resolved by the editor key. They are not verified identities. Your application still owns user authentication and must choose the appropriate context; the public editor key is not an administrative credential.

Use the SDK bridge rather than writing an unrelated message channel. For any custom iframe communication, validate the sender and payload and specify the intended destination origin. The HTML messaging standard describes these checks.

Save documents as a real application operation

Weavour’s onChange(document) callback gives the host structured content to persist. Connect it to a save operation with a document identifier and an expected revision. That revision contract belongs to your application; it is not an additional SDK option.

For example, your monthly update might be stored as draft update-october, revision 12. A successful save advances it to revision 13. If another tab has already saved revision 13, ask the user to resolve the conflict instead of silently replacing that work.

Show saving, saved and failed states based on persistence results. A callback firing does not mean the server has accepted the draft. Retain the current content after a failed save, and make retry possible without recreating the editor. When leaving the screen, clean up the SDK instance with destroy().

Export before entering the sending workflow

The documented exportHTML() method returns a promise containing html, text and document. Handle rejection before offering the result to your delivery path. Rendering itself is separate from transmission, as the React Email render documentation illustrates.

Keep sending credentials on your backend. The backend should validate the requested audience, resolve recipient data and handle sending permissions. Do not make a successful export appear as a successful delivery.

Include the saved revision in your host’s send request so support can identify which content was used. If sending requires the latest saved version, make that rule explicit and wait for the save before exporting.

Verify the journey users will repeat

Before expanding the integration, complete this acceptance pass:

• Edit a heading, save, leave and reopen the same document.
• Disconnect the network and confirm the unsaved text remains recoverable.
• Open two tabs and exercise your revision-conflict policy.
• Switch interface language without changing the authored message.
• Export, inspect links and send to an internal mailbox.
• Leave the editor and return without duplicate event handlers.

The useful milestone is a draft that survives the entire journey. Start with that one reliable path, then add the templates and controls your customers actually need. Explore Weavour with your own document lifecycle in mind.