Design ⇄ Code and the HTML block
When to drop into raw HTML, and what it costs you.
Two different things called 'code'
Sumezi has two separate features that both involve raw HTML, and it's easy to conflate them. The Design ⇄ Code toggle in the topbar switches the whole center panel between the visual canvas and a read-only view of the compiled HTML. The HTML block is a block type you drag into your document, with a text area where you write your own markup. Related, but not the same switch.
Code view: read it, copy it, don't type in it
Switching to Code shows a line-numbered, syntax-highlighted rendering of exactly what compile() produces from your current blocks — tags, attributes, strings, HTML comments and Outlook's MSO conditional comments each get their own color. A Copy button puts the whole thing on your clipboard. There's no textarea here: it's a <pre> block, not an editor, so changes still have to happen back in Design mode.
The filename bar above it shows a slugified name (e.g. mijn-template.html) and the live compiled size in KB, next to a fixed "Bulletproof · Outlook-tested" tag.
What "Bulletproof" means: every template you build from ordinary blocks already compiles with Outlook VML button fallbacks and color-scheme/supported-color-schemes meta tags for dark mode — automatically, with zero configuration.
The HTML block: your markup, unchecked
Find it in the block palette's Advanced group. Its properties panel is a single "Custom HTML" text area, with a visible warning right underneath: "Custom HTML is not validated by the compiler." Whatever you paste is inserted as-is into the compiled email's table row — no automatic Outlook-safing, no automatic dark-mode handling, no escaping. Past that point, you own the markup.
Both are Pro-plan features, enforced on the server
Two separate capabilities are checked: html_block — does your document contain a block of type html? — and code_mode — does the HTML you submitted differ from what the server's own compiler would produce from your blocks? The second check exists because a client could otherwise bypass the block model entirely by POSTing arbitrary HTML directly to the API, without ever touching an HTML block.
| Plan | code_mode | html_block |
|---|---|---|
| Free | ✗ | ✗ |
| Pro | ✓ | ✓ |
| Business | ✓ | ✓ |
On the Free plan, saving a template (creating or updating) that fails either check gets rejected with HTTP 402 and a JSON body identifying which limit you hit, for example:
{
"message": "HTML-blok is alleen beschikbaar op Pro en hoger.",
"code": "plan_limit",
"what": "html_block"
}
The same shape comes back with "what": "code_mode" if the block check passes but the submitted HTML itself doesn't match the compiler's own output.
On the Free plan, you won't even see the option
The editor checks /api/plan when it loads, and if code_mode is off it hides the Code button from the Design ⇄ Code toggle and removes the HTML tile from the block palette entirely. The 402 above is the enforcement layer behind that — it's what stops someone from getting the HTML block back by calling the API directly instead of using the UI.
If you get blocked
- 402 on save: upgrade to Pro or Business — the two flags are always equal: both on (Pro, Business) or both off (Free, Starter). Starter is a paid plan that has neither.
- Downgraded after building with an HTML block: further edits to that template will start failing with 402 until you remove the HTML block or upgrade again — the check runs on every save, not just the first one.
- Broken layout after pasting HTML: an unclosed tag in the HTML block can break everything rendered after it, since nothing validates it — send yourself a test email before a real send.