# Templatical: a drag-and-drop email editor you mount with one function call

> Templatical is a Vue and TipTap based email editor that stores templates as portable JSON and outputs MJML, with a provider interface so that comments, saved blocks, version history, test email and media need no hosted service, plus an Agent Skill that lets a coding assistant build an email from a prompt. It suits a product team shipping transactional email, and its source-available licence converts to MIT after two years.

**templatical/sdk** — Drag-and-drop email editor. JSON templates, MJML rendering, framework-agnostic. Vue + TipTap inside. Source-available under FSL-1.1-MIT — free commercially, MIT after 2 years.

- Repository: https://github.com/templatical/sdk
- Website: https://templatical.com
- Stars: 527 · Forks: 52
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/templatical-sdk

## What it is, and the three decisions that shape it

Templatical is a production-ready drag-and-drop email editor that you can drop into any web app with a single function call, and the documentation sets out three properties that explain the design.

The first is that templates are portable JSON. A template is data, it can be stored anywhere, versioned anywhere and rendered anywhere, and it is not a proprietary blob that only the editor can read.

The second is that the output is MJML, which compiles to the table-based HTML that email clients expect. This is the part that decides whether a project adopts an editor at all, because a modern drag-and-drop editor usually produces a layout that no mail client renders properly, and the resulting emails then look broken in Gmail. Emitting MJML means the markup that leaves the editor is markup that a mail client can lay out.

The third is that the editor itself is framework-agnostic, with Vue under the hood, but you embed it in React, Svelte, Angular or vanilla JavaScript the same way. The examples directory in the repository makes that concrete, with first-class examples for Next.js, Nuxt, React Router, React Vite and SvelteKit.

And the part that decides the deployment question is that comments, saved blocks, version history, test email and media need no Cloud, because you pass providers to init(). An optional Cloud tier adds AI rewrite, real-time collaboration and hosted or managed storage.

That split is the whole architecture in one paragraph. The editor is the product, the data is yours, and the hosted tier is an option rather than a dependency.

## The Agent Skill, and what it does to the workflow

The most distinctive feature is a skill that lets a coding assistant build the email, and the documentation is careful about the boundaries of it.

You describe the email you want and your AI coding agent builds it, then you preview it in the real editor, hand-edit anything, and export send-ready MJML or HTML. The claim is that it is a free, open-source Agent Skill with no backend and no API key, that your agent is the inference, and that nothing is sent to the company. The consequence stated is that you can ship a one-off campaign, or generate branded starter templates for the @templatical/editor integration.

The skill is an Agent Skills folder, and the documentation names the tools that read it, Claude Code, Codex CLI, Cursor, Gemini CLI and GitHub Copilot among others, all of which read a SKILL.md file. Installing it is one command:

```bash
npx skills add templatical/sdk
```

and that detects which supported agents you have and installs into the directory each one reads.

The preview story is the part that makes it more than a generator. You can ask to show it live and the skill opens your template in the real Templatical editor in a browser, updating as you prompt and reconciling any edits you make by hand. The documentation stresses that it is local and installs nothing into your project, that it is a small CLI fetched on demand via npx, and that the editor itself loads from the CDN.

The same skill also covers the other half of the work, wiring the editor into your own application, including installing, mounting, configuring, theming and troubleshooting the @templatical/editor package, and you do it by asking rather than by running a separate install. The routing rule is worth understanding, because it is what stops an agent from mixing up the two concerns. A request to author or edit a template stays on the email side, a request to embed the SDK moves to the integration side, and a request that needs both, such as building a welcome email and wiring it into an application, gets both with the template first.

One migration note is included, and it is the kind of detail that saves a broken install. If you installed the earlier templatical-email skill, you should remove it before installing this one.

For an organisation that wants a hosted, managed experience instead, with AI chat inside the editor, tuned prompts and an MCP server run by the company, that is the Cloud tier rather than the skill.

## The features that commercial editors usually charge for

The project lists the power features with an unusual opening line, that things usually paid for in commercial editors are free in Templatical. The list is specific and the reasoning behind each item is worth following.

Custom blocks with API-backed data sources are the first. You register your own block types whose content is rendered from a static template or fetched live from your API at preview time, and the documentation says this is typically a paid-tier feature elsewhere.

Merge tags in your ESP's syntax come next, with the examples {{handlebars}}, {liquid}, ${js} or your own, and with automatic human-readable label replacement directly in the editor canvas, so a template shows a readable name where the raw tag will go. The point of the label replacement is that an editor full of raw syntax is not usable by the people who write the emails.

Display conditions let you show or hide blocks based on recipient attributes, with a live preview in the editor, so the conditional logic is visible rather than inferred from the output.

Reusable saved blocks let users save a group of blocks and re-insert it across templates, with search, preview, rename and delete. Storage is supplied through a small provider interface, or you can use the bundled browser-local one, and the editor owns the whole interface.

Version history lets you browse, preview and restore a template's past versions from the header. The storage here is a four-method provider you implement, and the editor owns the control, the preview and the restore flow.

Full theming through design tokens covers colour tokens, custom fonts, dark mode and complete theme overrides, with the claim that there is no CSS hacking and no paid tier.

And template and block defaults let you define your brand once, with new templates and new blocks picking it up automatically.

The pattern across all seven is the same, and it is the reason the project is worth reading. The editor implements the interaction, the workflow and the user interface, and the application supplies the data. The parts a commercial product would charge for are the parts that require infrastructure, and infrastructure is exactly what the provider interface replaces.

## Mounting it, and keeping the styles apart

The integration story is deliberately short. There is a drop-in mount with one init() call and one unmount(), and no framework lock-in, and the point of the design is that the editor does not care what surrounds it.

The styling isolation is the part that deserves attention, because it is where embedded editors usually cause trouble. Shadow DOM by default keeps host CSS out of the editor, and on the other side a tpl: Tailwind prefix and no preflight reset keep the editor's styles out of your application. The documentation describes it as isolation in both directions, and the consequence is that it drops into any page, any framework and any CMS with no resets and no conflicts.

That is a real engineering claim and it is the one thing a host application will notice on day one. An editor that injects a global stylesheet resets your type scale and your buttons, and the fix is usually a wrapper of custom properties and a lot of specific rules. Not having to do that is the reason to look at this library.

The built-in block list is the other part of the surface area, and it is a sensible catalogue: Title, Paragraph, Image, Button, Section, Divider, Spacer, Social Icons, Menu, Table, HTML, Video, Countdown and Custom.

The HTML block is worth noting on its own, because it is the escape hatch. It lets a user put arbitrary markup into an email, which is what a marketing team needs for a hand-built section that the editor has no block for, and it is also the block that most needs sanitising on the way out, because the content comes from a person in a browser and ends up in mail clients.

The Video and Countdown blocks are the more unusual ones. Both are things that most email editors leave to images or to nothing, and both are the kind of detail that shows the project is aimed at real campaign email rather than at a template library.

## The repository, and the import packages that tell you about it

The repository is a pnpm workspace, and its shape is informative.

The root package is private and holds the workspace dependencies, with Vue at 3.5.44, liquidjs for template evaluation, @vueuse/core for the composables and vue-advanced-cropper for the image cropping that an image block needs. The dev dependencies carry the bulk of the toolchain, with the TipTap extensions for colour, font family and text style, which are what make the rich text editing work, plus Playwright with a separate MCP package, Vitest with coverage, Tailwind through the Vite plugin, Vite 8, TypeScript 6, tsdown for the build, the API extractor for the public type surface, and the usual linting and formatting set.

The workspace packages are where the real structure is. There is @templatical/editor, the SDK itself, and then a family of import packages, one per competing tool: import-beefree, import-chamaileon, import-easy-email-pro, import-html, import-mjml, import-stripo, import-topol and import-unlayer, plus @templatical/quality and the types and core packages the build script names.

That list of importers is the most useful single fact in the repository for an adopter. It means a team that already has templates in Beefree, Chamaileon, Easy Email Pro, Stripo, Topol, Unlayer, or plain HTML or MJML, can bring them across rather than rebuild a library of email templates by hand, and it means the project takes the existing ecosystem seriously enough to have written eight adapters for it.

There are also apps/ for the applications, examples/ for the framework examples, and a skills/ directory holding the Agent Skill, alongside a .mcp.json for the Model Context Protocol, a context7.json, three separate Playwright configurations for the consumer, the examples and the main suite, a .changeset/ directory for the release notes, renovate for dependency updates and syncpack for dependency version consistency across the workspace.

The engine requirement is Node 24.22.0 or newer with pnpm 12.14.0 as the package manager, and the recent releases are v0.48.0 from 2026-10-17, v0.47.0 from 2026-10-16 and v0.46.0 from 2026-10-15, with the last push to the repository on 2026-10-20. Three releases in three days is the rhythm of an active project, and the calendar-style version numbers follow the Ansible dev tools convention.

## The licence, and what source-available means here

The licence is the part of this project that needs a paragraph of its own, because the terms are unusual and they are stated in the project description rather than buried.

The package is source-available under the FSL with an MIT conversion, and the description spells out what that means in a few words: free commercially, MIT after two years. The badge in the readme says the same thing in licence terms, and the repository carries both a LICENSE file and a LICENSE-MIT file.

The Functional Source Licence is a source-available compromise that has been used for a number of commercial products. The general shape is that the code is made available under terms that forbid competing use, and after a period, usually two years, it converts automatically to an open source licence, in this case MIT. The practical effect for a user is that you can use it commercially from day one, and that the project is not a permissively licensed dependency in the ordinary sense, so a legal review is part of adopting it.

That is a real difference from the MIT or Apache terms that most editor libraries carry, and it is worth being explicit about rather than describing the project as open source without qualification. The documentation also frames the free tier as the durable one, with the Cloud tier as the paid option, so the commercial relationship is with the hosted service rather than with the source.

The rest of the project is conventional. There is a CONTRIBUTING guide, a CODE_OF_CONDUCT, a SECURITY policy, a SPONSORS file, and the repository is on the main branch with a CI workflow and codecov coverage reporting.

The playground at play.templatical.com and the documentation site at docs.templatical.com are both public, and the project keeps a changelog there, which is where a team tracking the editor's changes would look given the release cadence.

## Conclusion

Templatical is worth evaluating if you are building an application that sends email and want a real editor for it, because the output is MJML, which compiles to the table-based HTML that mail clients actually render, because the template format is JSON that you can store and diff like any other data, and because the editor is framework-agnostic despite being Vue underneath, so it mounts in a React application without a rewrite. It is the wrong tool if you want a hosted product. Before you adopt it, check three things: that the licence suits you, since the project is source-available under the FSL with an MIT conversion after two years, which is a different legal position from a permissively licensed dependency and is worth reading rather than assuming; that the provider interfaces cover what you need, because comments, saved blocks, version history, test email and media are all things you implement rather than things you get, and the editor owns the interface and the flow while you own the storage; and that you look at the import packages, because the repository carries adapters for other editors such as Beefree, Chamaileon, Easy Email Pro, Stripo, Topol, Unlayer and MJML, which is the fastest way to judge how much of an existing template set you could bring with you.

## FAQ

### How do I add the Templatical editor to my application?

You mount it with a single init() call and unmount it with a single unmount() call, and the editor is framework-agnostic even though Vue is used under the hood, with first-class examples for Next.js, Nuxt, React Router, React Vite and SvelteKit. Styling is isolated in both directions through Shadow DOM, a tpl: Tailwind prefix and no preflight reset, so the editor's styles do not leak into your app and yours do not leak into the editor.

### What do I have to provide for Templatical to work without a hosted service?

You pass providers to init(). Comments, saved blocks, version history, test email and media all need no Cloud, and each of those is a small interface you implement, with the editor owning the user interface and the flow. A browser-local storage implementation is bundled for saved blocks. The optional Cloud tier adds AI rewrite, real-time collaboration and hosted or managed storage.

### What licence is Templatical under?

It is source-available under the Functional Source Licence with an MIT conversion, which the project describes as free commercially and MIT after two years. The repository carries both a LICENSE file and a LICENSE-MIT file, so it is not the same legal position as an MIT or Apache licensed dependency and is worth a legal review before you depend on it.

## Sources

- [Issues](https://github.com/templatical/sdk/issues)
- [Project website](https://templatical.com)
- [README](https://github.com/templatical/sdk/blob/main/README.md)
- [Releases](https://github.com/templatical/sdk/releases)
- [templatical/sdk on GitHub](https://github.com/templatical/sdk)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/templatical-sdk