How to Test Transactional Emails with React Email or MJML

1. Choose fixtures for the branches that can go wrong

A template can render successfully while containing the wrong total, account role or expiration message. Start with a small matrix of synthetic input data. Name each variation with a stable ID, such as standard, admin or short-expiry. Avoid names, addresses and other real customer data in fixture IDs.

Include the branch that omits optional content as well as the one that includes it. When a rule applies to a named scenario, require that scenario in coverage. Deleting the failing fixture should produce a missing-coverage failure.

2. Render the actual source template into HTML

Use your existing React Email, MJML or other renderer. InlinerAPI accepts rendered HTML; it does not run your source components or replace your renderer. Keep rendering in your repository so dependencies, fixtures and changes can be reviewed together.

For a complete example, download a renderer starter from the scenario matrix. Its pinned dependencies, template source and synthetic fixtures include a passing version and a reminder branch with a missing signing button. Review the README and extract into a new folder before running:

npm ci
npm run render:react-email:broken
# Or use the MJML example:
npm run render:mjml:broken

These are example package scripts, not universal React Email or MJML commands. Your own repository needs its own render script and output paths. For the repaired starter, run render:react-email or render:mjml without the :broken suffix.

3. Define the expected content and preview every variation

Open email requirements for one rendered email, or the scenario matrix for several variations. Require the expected text in a selected element, require or forbid a section, constrain action links to approved destinations, and check for supported unresolved template-token patterns.

Use synthetic expected values. A receipt total check proves that the selected HTML contains your configured total; it does not calculate tax or compare the amount with your billing database. Likewise, an approved-link check evaluates the URL in the HTML, not the destination's availability or access controls.

The public matrix preview supports up to three scenarios and 500 KiB of combined HTML. Preview does not save a shared release or record an approval. Review the named scenario, rule and selector for each failure rather than treating a successful HTTP request as a passed check.

4. Repair the source and compare the next render

A browser edit can help diagnose a missing element, but update the actual template source before release. Render again, use Update rendered output to review the new matrix, then preview under the same requirements. Check new findings, resolved findings and required coverage.

If an expectation changes, review that as a rule change. Changing the expected amount to match an incorrect output does not repair the receipt. Export a repair checklist or readable evidence for review; inspect configured policy values before sharing exported files.

5. Repeat the checks in GitHub Actions

The matrix page can generate a setup ZIP for three workflows: render HTML and assemble a matrix, use an existing matrix-producing package script, or check a committed rendered matrix. Configure the package manager, script and repository-relative paths to match your build.

For a renderer workflow, run the included local setup checker before adding credentials. It checks folders, package scripts and lockfile presence without installing packages or making an API request. It does not prove that the renderer or remote CI job will succeed.

node inliner-ci/check-setup.cjs

Shared project rules, saved matrix releases and CI gates require an eligible Pro or Enterprise plan and available checkout. Add your owned project's ID as INLINER_PROJECT_ID and its API key as the GitHub repository secret INLINER_API_KEY. Keep the key out of templates, fixtures and commits. Follow the generated README and the API and integration reference.

The workflow retains check evidence when requirements block release. Downloading a setup ZIP does not connect your repository. Run the workflow on an actual commit, inspect its result and confirm that a deliberately broken branch closes the gate.

Start with a reproducible example

Try the failing and repaired scenario examples, then adapt the fixtures and requirements to your own workflow. Free previews do not require an account. Review plan limits and checkout availability before planning a paid rollout.

Renderer references: React Email rendering and MJML documentation. The starter README records the tested dependency versions.