Living Emails let you display product content that can be updated when an email image is requested. This is useful for e-commerce campaigns where prices, inventory, or recommendations may change after a message is sent.
This guide explains how to prepare your Living Email service, add product cards to a Mautic email, and test the result.
Before you begin
You’ll need:
- A Living Email rendering service with image and click-through endpoints
- A Mautic instance configured to send email
- Product data available to the rendering service, such as inventory, pricing, and product links
- At least one configured recommendation strategy and image template
- A safe way to identify the recipient to the service
The rendering service is responsible for selecting the product for each recipient and slot, creating the product-card image, and returning it to the email client. The click-through service records a click if configured to do so, then redirects the recipient to the relevant product page.
Protect recipient identifiers
Avoid putting a recipient’s raw email address in an image or link URL. Email addresses in URLs can be exposed in server logs, analytics systems, and other systems that handle the request. Use an opaque identifier or a signed, expiring token instead, and configure the service to resolve it securely to the appropriate Mautic contact.
The examples below use {recipient_token} as a placeholder. Replace it with the secure token or identifier supported by your implementation. Don’t assume that a value is hashed just because it appears in a URL; the service must actually implement that protection.
In Mautic you can use contact ID as a simplified approach:
{contactfield=id}1. Add date token to Mautic
You can use our helper plugin in for Mautic to add a feature that creates a token {date} which can be used as a {cache_key}. Snippets generated in the Living Emails service in Mautic are automatically populated with the {date} token.
You can download the plugin from here: Date token Mautic
Unzip it so the folder is docroot/plugins/DateTokenBundle/ in your Mautic root. The folder name must match the namespace docroot/plugins/DateTokenBundle/
Clear the cache:
php bin/console cache:clearReload plugins:
php bin/console mautic:plugins:reloadCheck that it shows up under Settings → Plugins. Then send a test email containing {date}.
2. Configure the Living Email service
In your Living Email service or Mautic plugin, configure:
- Image endpoint — accepts a request for a product-card image and returns an image, such as a JPEG or WebP.
- Click-through endpoint — accepts a product-card click, records any required attribution, and redirects to the product page.
- Templates — define the visual layouts available to marketers, such as a single-product card or a multi-column layout.
- Recommendation strategies — connect strategy names or IDs to the selection rules the service should use.
- Product data sources — provide access to the product information needed to render cards, including current price, availability, product image, title, and destination URL.
- Recipient resolution — configure how the service securely maps the token in a request to the right Mautic contact or customer profile.
Use HTTPS for both endpoints. Confirm that the rendering service can return a useful fallback image if it cannot select a product or retrieve product data.
3. Understand the URL structure
A typical Living Email uses one URL to display a product-card image and another to handle clicks:
https://im2.example.com/v2/img/{client_id}/{cache_key}/{recipient_token}/{template_id}/{strategy_id}/{slot}https://im2.example.com/v2/url/{client_id}/{cache_key}/{recipient_token}/{template_id}/{strategy_id}/{slot}The values identify the tenant, recipient, layout, recommendation strategy, and product position.
| Value | Purpose | Example |
|---|---|---|
{client_id} | Identifies the Mautic account or tenant | e8a2d2ff4a3b47e2 |
{cache_key} | Helps distinguish or version requests for caching | {date} |
{recipient_token} | Securely identifies the recipient | token-value |
{template_id} | Selects the card layout | template1 |
{strategy_id} | Selects the recommendation logic | 35506 |
{slot} | Selects a position in the product set | 0,1, 2, or 3 |
Use the exact parameter order and format required by your Living Email service. The example values above are illustrative; they are not built-in Mautic IDs.
Caching note: A cache key can help control how requests are cached, but it does not guarantee that an image will be fetched again every time someone opens an email. Email clients and image proxies may cache images. Configure caching behavior on your service, and test with the email clients your audience uses.
4. Add a product card to a Mautic email
In Mautic, open the email you want to edit and add an HTML or custom-code block where the product card should appear. Insert an image URL that points to your Living Email image endpoint.
Here is a single product-card example that is generated by Living Emails service. Copy and paste it into your email template.
<a href="https://im2.example.com/v2/url/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/1">
<img
src="https://im2.example.com/v2/img/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/1"
alt="Recommended product">
</a>Replace the example domain and values with those configured for your service. Replace {recipient_token} with the Mautic token or personalization mechanism your implementation uses. Check that Mautic recognizes and renders that token correctly in the final email.
The link and image URLs should use matching values for the recipient, template, strategy, and slot. The image URL displays the card; the link URL handles the click.
5. Show multiple products
To show several products, add one image-and-link pair for each slot. Keep the strategy and template consistent if the cards belong to the same product set, and increment the slot number.
<!-- Product slot 1 -->
<a href="https://im2.example.com/v2/url/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/1">
<img src="https://im2.example.com/v2/img/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/1"
alt="Recommended product 1">
</a>
<!-- Product slot 2 -->
<a href="https://im2.example.com/v2/url/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/2">
<img src="https://im2.example.com/v2/img/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/2"
alt="Recommended product 2">
</a>
<!-- Product slot 3 -->
<a href="https://im2.example.com/v2/url/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/3">
<img src="https://im2.example.com/v2/img/e8a2d2ff4a3b47e2/campaign-2026-10/{recipient_token}/template1/35506/3"
alt="Recommended product 3">
</a>Your service determines which product belongs in each slot. If a product is unavailable, it can apply the fallback rules configured for that strategy.
6. Choose a strategy and template
The strategy determines how products are selected. Examples include:
- Abandoned cart: products associated with an unfinished cart
- Next best offer: products selected using customer activity or purchase history
- Upsell or cross-sell: products related to a recent purchase or current selection
- Recommended for you: products selected for an individual recipient
- New arrivals or trending products: current products filtered by a category or preference
The template determines how each selected product is displayed—for example, a minimal product card, a card with a sale badge, or a layout designed to sit alongside other cards.
Use the strategy ID and template ID that your service administrator configured. A strategy name shown in a marketing brief may not match the ID required in the URL.
You can also use different strategies in one email by creating separate image-and-link pairs. For example, one row could show abandoned-cart items and another could show recommendations. Use the appropriate strategy ID for each row.
7. Test the email before sending
Send test emails to contacts that represent the situations you expect the campaign to handle. Check:
- The Mautic recipient token is replaced correctly.
- The image endpoint returns an image rather than an error page.
- Each product slot displays the intended card.
- Links go through the click-through endpoint and then reach the correct destination.
- Sold-out products trigger the expected fallback.
- Prices, product titles, badges, and availability are legible on mobile.
- The message remains understandable if images are blocked.
Use descriptive alt text for each image. Consider adding plain-text product names and links nearby, because some email clients block images or display them only after the recipient allows them.
Test with multiple email clients where possible. Image caching, proxy behavior, and support for email HTML can differ across clients.
8. Use Living Emails in campaigns
Once the email template is set up and tested, add it to your normal Mautic campaign workflow. For example, an abandoned-cart campaign might wait for a cart event, pause for a chosen period, and then send an email containing Living Email product cards.
The email content can be reused across campaigns, while the strategy and recipient data determine which products are selected. Confirm that the campaign passes the correct recipient identifier and that the service has access to the data required by its recommendation rules.
9. Review performance
Depending on your implementation, the Living Email service may report image requests, product selections, fallback use, and click-through activity. Use these measures to understand whether the cards are rendering and whether recipients engage with them.
Remember that image requests are not a perfect measure of email opens: some clients block images, while others may prefetch or cache them. Compare rendering data with Mautic campaign results and your commerce analytics rather than treating image requests as exact open counts.
Troubleshooting
The image is missing or broken. Check the image endpoint URL, HTTPS certificate, required parameters, and whether the service is returning a valid image response.
The product shown is wrong. Confirm that the strategy ID, slot number, and recipient identifier are correct, then check the service’s product-selection rules and recipient mapping.
The fallback does not appear. Verify that a fallback is configured for the strategy and that the service recognizes the product as unavailable.
The price or inventory looks stale. Check how often the service refreshes product data, its caching settings, and whether the email client is serving a cached image.
The click goes to the wrong destination. Confirm that the /v2/url/ request uses the same recipient, strategy, template, and slot values as its corresponding image URL, and check the redirect rules.
The recipient token appears literally in the email. Review the token syntax supported by your Mautic version and confirm the message is being sent to a real contact rather than previewed without a recipient context.
Living Emails work best when the rendering service, Mautic token handling, product data, and fallback rules are tested together. Once that setup is in place, marketers can reuse the email content and focus on campaign strategy and customer experience.