Thanks — yes on both, and both already exist today.

1. Custom block extensibility: full. You define a custom block as a schema — typed fields displayed in the editor (text, textarea, image, color, number, select, boolean, repeatable that contains basic fields) plus a Liquid template that emits HTML using those field values. The editor auto-renders the form for marketers to fill in, then runs the Liquid against those values to show a live preview on the canvas — so consumers don't write a Vue component themselves. The renderer wraps that HTML in <mj-text>, so it still goes through MJML's table layer for cross-client rendering. Optional dataSource.onFetch lets the block hit your API at render time, so use user can fetch custom block contents from existing data source — instead of having to manually type values into every field. Check out the docs and playground for custom blocks usage.

2. Headless render path: that's exactly what @templatical/renderer is. Separate package, zero UI dependency, pure JSON -> MJML conversion. You store the JSON tree in your storage; on the backend you pass it to renderToMjml() and get MJML back. Since MJML has compiler libraries in almost every language, you compile MJML to HTML yourself whenever. Currently the renderer is TypeScript-only (browser + Node.js); porting to other languages as first-party packages is on the roadmap.

The whole shape — store JSON in your DB, render at send time on your server, send via your own provider — is the transactional flow you described.