The usual fix is to reach for a transactional email SaaS and start templating in their dashboard, away from WordPress, with their own merge-tag syntax. I wanted the template to live where the form lives, and — more importantly as a developer — I wanted to iterate on it without sending half-finished emails to a real address.

Templating in the editor you already know

The approach that stuck: design the email as blocks in the native Gutenberg editor — headings, columns, buttons, images, spacers — and let the plugin compile that to email-safe HTML on save (CSS inlined so Gmail/Outlook/Apple Mail render it correctly). No separate editor, no hand-written table-based HTML, no inlining CSS by hand.

Personalisation is dynamic tags dropped into text blocks:

Hi {{email.first_name}},

Your booking at {{site.name}} is confirmed.

Check-in:  {{email.checkin_date}}
Check-out: {{email.checkout_date}}
Total:     {{email.price}} {{email.currency}}

{{site.*}} tags are always available; {{email.field_name}} tags resolve to whatever the user submitted in the named field (including calculated values exposed from the form). Tags work in the subject line too. They render as literal text while editing and get substituted at send time.

The part that matters: test against a sandbox, not a colleague's inbox

This is the workflow I actually came to recommend. Before a template touches a real address, point it at Mailtrap's free sandbox — a catch-all SMTP server that intercepts every send and shows you the full HTML render, raw source, headers, and a spam score in a browser inbox. Nothing escapes to a real recipient.

Add it as an SMTP server once:

Host:     sandbox.smtp.mailtrap.io
Port:     2525
Username: <your sandbox inbox username>
Password: <your sandbox inbox password>

Then submit the form as a visitor would. The email lands in Mailtrap in a couple of seconds, fully rendered. Layout wrong? Edit the template, save, submit again. Because every send is caught, you can iterate as many times as you like with zero risk of a "test 47" email reaching a customer. The free plan covers 1,000 test emails/month across five inboxes — far more than any template needs.

When the render is right, flip the SMTP server on that send action from the Mailtrap sandbox to your production sender. Same template, same tags — only the transport changes.

Confirm delivery instead of guessing

The last piece that closed the loop for me: an email log that records every outgoing message regardless of transport — date, which server sent it, success/failed status, the full body, and the error string on failure (wrong password, port blocked by the host firewall, rate limit). Diagnosing a bad send by reading the log row beats chasing a missing email with no trail.

I wrote the full walkthrough — building the template block by block, the complete Dynamic Data tag reference, wiring the Send Email Template action, and the Mailtrap setup with screenshots — on my blog:

👉 Build Branded Email Templates in WordPress (and Test Them with Mailtrap)

Disclosure: I build CraftForms, the plugin with the block-based email builder shown here. The Mailtrap-sandbox testing workflow applies to any WordPress mail setup.

They're not entirely wrong about the bloat. But they're wrong about the conclusion — at least for one specific use case.

Used as a form and data backend for web projects — not a CMS you expose to the public — a single WordPress install is genuinely hard to beat, especially when you're managing more than one site.

What you actually need to process a form submission

Building a backend to handle form submissions sounds simple. It isn't. Here's what you actually need:

• Somewhere to store submissions and query them later
• Transactional email that reliably arrives (not mail() on shared hosting)
• A file upload handler with storage management
• An admin interface to review, filter, and export data
• Spam protection
• User auth and roles if you need them
• A REST endpoint to receive POST data from your frontend

WordPress ships all of this. The database and schema, the SMTP-pluggable wp_mail() layer, the Media Library, the admin panel (including a full users and roles system), nonce-based CSRF protection, and the REST API — present, production-tested, on millions of sites.

Building this yourself gives you a cleaner architecture and full control. A form SaaS gives you an endpoint but your data lives on their servers. WordPress gives you the whole stack, pre-configured, for the cost of a cheap shared VPS.

The architecture

One WP install. Locked down to a single REST namespace. Shared as the backend for as many projects as you want.

Project A (static site)  ──┐
Project B (Next.js app)  ──┼──▶  WP REST API  ──▶  DB / Storage / Email
Project C (mobile app)   ──┘

Each project POSTs to the same endpoint. WordPress handles validation, storage, email, and file management. None of your frontends need to know it's PHP behind the wall — they just see a REST endpoint that returns JSON.

The lock-down is a must-use plugin: four filters, about 20 lines of PHP. It blocks the public frontend entirely, restricts the REST API to your one namespace (killing /wp/v2/users, route discovery, and the standard WP REST exploits), kills XML-RPC, and optionally relocates the login page to a non-guessable path. I posted the full mu-plugin in a previous article on dev.to if you want to copy it verbatim.

The embed option most people miss

Here's the part that took me a while to find useful: WordPress can also serve the form HTML to any frontend.

Your form plugin exposes an embed endpoint:

GET /wp-json/craftforms/v1/embed/YOUR_FORM_KEY

It returns the rendered form HTML, CSS, and initialisation JS as a single response. Your frontend drops in a <div> and a <script> tag. The form renders. Validation, file uploads, multi-step logic, CAPTCHA — all managed from the backend, all delivered to whatever site loads the snippet.

This means a static site with literally no server of its own can run a multi-step booking form, a product configurator with price calculation, or a payment-enabled order form. The backend does the work; the frontend just displays the output.

<!-- On any page, on any host -->
<div id="cf-form"></div>
<script src="https://your-backend.com/wp-json/craftforms/v1/embed/contact?target=cf-form"></script>

When this trade-off is worth making

This architecture wins when:

• You manage several sites and want one data layer instead of separate backends
• Your forms need file uploads, complex conditional logic, or WooCommerce integration
• You want to own your submission data and control the email infrastructure
• You don't want to build a backend from scratch or pay a per-submission SaaS fee

It's not the right call if you need a fully provider-agnostic API layer, if you're already running a Node/Go/Python server that handles this cleanly, or if submission volume makes a single-site WordPress instance a bottleneck.

For the common pattern — one to several sites, a small team, forms that need to do more than just email you — it's the most pragmatic stack I've settled on.

I wrote the full walkthrough — the lock-down mu-plugin in full, multi-project configuration, the embed setup, file upload handling, and SMTP routing — on my blog:

👉 How to Use WordPress as a Form Backend for Static Sites and Web Apps

Disclosure: I build CraftForms, the form plugin used in the examples. The lock-down pattern and REST architecture work with any plugin that exposes a consistent REST namespace.