Send email from JTL-Shop reliably by configuring its native SMTP delivery path to use Volanea. This is the appropriate integration for JTL-Shop’s built-in transactional messages: JTL-Shop renders the email, then Volanea handles authenticated delivery, sending infrastructure, and delivery visibility.

The supported JTL-Shop integration path

JTL-Shop does not need a native Volanea marketplace app to send transactional mail through Volanea. The relevant built-in capability is SMTP configuration: JTL-Shop creates messages from its own email templates and delivers them through the SMTP server configured for the shop.

That distinction matters. A checkout confirmation, password-reset email, contact-form response, or account-registration message is not ordinarily an outbound JSON webhook from JTL-Shop. It is an email assembled by the shop. The reliable integration is therefore:

A shopper performs an action that causes JTL-Shop to create an email.
JTL-Shop renders the applicable email template and recipient data.
JTL-Shop opens an authenticated SMTP connection to Volanea.
Volanea accepts the message and delivers it to the recipient’s mailbox provider.

This avoids pretending that JTL-Shop includes a standard outbound HTTP automation trigger, Zapier action, Make module, or Volanea app when it does not. It also keeps JTL-Shop responsible for the commerce event and template, while Volanea is responsible for the transport layer.

For developers who need a REST API rather than SMTP, use a server-side middleware service or a custom JTL-Shop extension. Do not try to call a sending API from storefront JavaScript. That would expose credentials to every visitor and would make email delivery dependent on a browser session.

What actually triggers an email in JTL-Shop

The trigger is the JTL-Shop event that causes one of its configured email templates to be sent. In practice, the exact event depends on the template category and the shopper’s action.

Common examples include:

A customer finishes checkout and JTL-Shop creates an order confirmation email.
A customer uses a password-reset flow and JTL-Shop sends the reset message.
A customer registers an account and the shop sends the relevant account email.
A customer submits the contact form and JTL-Shop sends the configured contact-form notification or response.
A customer receives a status-related or other template-driven shop notification, depending on the shop’s email-template configuration and connected JTL processes.

The key operational point is that the trigger belongs to JTL-Shop’s template and business-event system, not to Volanea. Volanea does not decide whether an order should generate a confirmation; it receives the already composed message after JTL-Shop decides to send it.

Why this is better than duplicating transactional logic

Putting order-email logic in a second automation system creates two sources of truth. One may know the paid amount while the other sees a stale order state; one may include the order number while the other does not; both may send after a retry.

Using JTL-Shop templates for shop-originated transactional mail means the data used to render the message remains close to the event that created it. Configure Volanea as the delivery provider, then use the same templates, variables, language settings, and recipient rules that the shop already uses.

If the business requirement is a separate lifecycle campaign—for example, a post-purchase educational sequence—that can be a distinct system. It should not replace the essential order confirmation, password reset, or customer-service notification that the shop itself must send promptly.

Before you configure SMTP

Prepare the sending identity and credentials before changing JTL-Shop. A clean setup has four components: a verified sender domain, DNS authentication, an SMTP credential, and a suitable from-address.

Use a domain you control

Send from an address on a domain that your organization controls, such as shop@example.com or orders@example.com. Do not use a shopper’s address in the From field. A shopper address is useful as a Reply-To value where appropriate, but using it as From can cause DMARC alignment problems and makes replies harder to manage safely.

The domain must be authenticated in Volanea using the DNS records shown for that domain. The exact record names and values are domain-specific, so copy them from Volanea rather than reusing values from a blog post, another sending provider, or an old domain configuration. SPF, DKIM, and—where your domain policy requires it—DMARC are what make a branded sender identity credible to receiving systems.

Create a dedicated SMTP credential

Create a Volanea API key or SMTP credential intended for this JTL-Shop installation. A dedicated credential gives you a clean revocation boundary: if the shop server is compromised, rotate that credential without disrupting another application.

Give the credential only the permissions it needs for sending. Store its creation date, owner, and intended environment in your operational notes. Production and staging should use different credentials and, ideally, different sender identities or subdomains so test mail cannot be confused with customer mail.

Volanea’s email API reference and setup guides are the source of truth for the current SMTP hostname, ports, username convention, TLS requirements, and available API key types. SMTP hostnames and authentication formats are infrastructure details; do not guess them from a provider you used previously.

Decide on sender and reply handling

Set a stable, human-readable sender such as Example Store <orders@example.com>. Make the local part meaningful to customers and make sure replies are handled. If customers should reply to a support mailbox, configure that mailbox as the reply destination in the relevant JTL-Shop template or sender settings.

For a contact-form notification, it may be appropriate to set Reply-To to the address supplied by the customer. Validate that address before placing it in an email header, and never allow raw form input to create additional headers. Header injection is a security issue, not merely a formatting problem.

Configure Volanea as JTL-Shop’s SMTP server

In JTL-Shop’s administration area, find the shop’s email or mail-server settings and select SMTP delivery rather than relying on the server’s local mail transport. The labels can differ between JTL-Shop releases and language installations, so use the current JTL-Shop administration documentation for the exact navigation in your version.

Enter the SMTP connection details issued in Volanea:

SMTP server hostname
Port appropriate for the selected encryption mode
Encryption or TLS setting required by that endpoint
SMTP username, if Volanea’s credential format uses one
SMTP password or API key, if Volanea uses the key as the SMTP secret
Sender address and sender name used by the shop

Do not place these values in a theme setting, browser-accessible JavaScript configuration, product attribute, repository, or a public environment-file endpoint. The SMTP secret is equivalent to a sending credential. Anyone who obtains it may be able to send mail as your authenticated domain until you revoke it.

Test deliberately, not with a live customer journey

First, use the shop’s available mail test function if your installed version provides one. If it does not, run a controlled event using a test account: request a password reset or submit a contact form to a mailbox your team controls. Avoid repeatedly creating live orders merely to test mail.

Check each layer separately:

Did JTL-Shop report that it created or handed off the message?
Did Volanea show an accepted send attempt for the sender identity?
Did the message arrive in the intended inbox?
Did it land in inbox, spam, or a quarantine area?
Do the From, Reply-To, subject, language, links, and template variables look correct?

A successful SMTP login proves only that the shop can authenticate. It does not prove that the domain has valid DNS authentication, that the selected sender is authorized, or that a recipient provider will place the message in the inbox.

The data JTL-Shop sends: SMTP message, not a webhook payload

A direct JTL-Shop-to-Volanea SMTP configuration does not produce a JTL-Shop JSON payload. JTL-Shop sends an SMTP email message containing headers and a rendered body. It is important to state this plainly because an invented order.created JSON schema would be unsafe to build against.

Conceptually, the message JTL-Shop hands to the configured SMTP server looks like this:

From: Example Store <orders@example.com>
To: customer@example.net
Reply-To: support@example.com
Subject: Your order confirmation
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="..."

--...
Content-Type: text/plain; charset=UTF-8

Hello Maria, thank you for your order 12345.

--...
Content-Type: text/html; charset=UTF-8

<p>Hello Maria, thank you for your order <strong>12345</strong>.</p>
--...--

The fields are produced by the JTL-Shop email template and its available template data. The shop’s SMTP layer supplies the recipients, headers, plain-text and/or HTML parts, and any configured sender identity. Volanea receives those standard SMTP components, rather than an HTTP object such as { "event": "order.created" }.

This is why template mapping belongs in JTL-Shop for the SMTP route. If the order number, customer name, or line items are missing, inspect the template and the event data available to that template. Changing Volanea credentials cannot repair a template variable that JTL-Shop did not provide.

When you need Volanea’s REST API instead

Some teams need to call the REST API for centralized message construction, idempotency controls, custom event logging, or a service architecture that does not use JTL-Shop’s native templates. JTL-Shop does not provide a standard outbound HTTP webhook payload for that purpose on its normal shop configuration, so insert trusted server-side middleware.

The middleware must receive an event from a custom extension or another server-side integration point, normalize it, validate it, and then make the REST request. Zapier or Make cannot create a direct event by themselves when JTL-Shop has not emitted an outbound HTTP event; they need a real source event. If your workflow is based in JTL-Wawi rather than JTL-Shop, verify the capabilities and licensing of that separate product before designing around it.

A safe middleware contract

Have the custom server-side integration post a small, documented event to your middleware. This is an example of your own middleware contract, not a payload claimed to be sent natively by JTL-Shop:

{
  "event_id": "jtlshop-order-12345-confirmation-v1",
  "event_type": "order_confirmation_requested",
  "order_number": "12345",
  "customer": {
    "email": "customer@example.net",
    "first_name": "Maria"
  },
  "order": {
    "currency": "EUR",
    "total": "49.90"
  }
}

The event_id is essential. It should identify one logical email, not one delivery attempt. A good format combines the JTL-Shop order identifier, the message purpose, and a template revision. Store it in your middleware database with a unique constraint before sending. That creates an idempotency boundary even if the upstream extension retries.

REST request and field mapping

The following server-side Node.js example maps the normalized event into a Volanea REST email request. Use the current endpoint and authentication syntax from Volanea’s documentation if your account’s API version differs; do not expose VOLANEA_API_KEY to the storefront.

import express from "express";

const app = express();
app.use(express.json());

app.post("/events/jtl-shop", async (req, res) => {
  const input = req.body;

  // Field mapping from the middleware event to the email request:
  // input.customer.email      -> to
  // input.customer.first_name -> HTML/text greeting
  // input.order_number        -> subject and message body
  // input.event_id            -> local idempotency record
  const to = input?.customer?.email;
  const firstName = input?.customer?.first_name || "there";
  const orderNumber = input?.order_number;

  if (!input?.event_id || !to || !orderNumber) {
    return res.status(400).json({ error: "Missing event_id, customer.email, or order_number" });
  }

  // Replace this with an INSERT protected by a UNIQUE(event_id) constraint.
  const alreadyProcessed = await wasProcessed(input.event_id);
  if (alreadyProcessed) {
    return res.status(200).json({ status: "duplicate_ignored" });
  }

  const email = {
    from: "Example Store <orders@example.com>",
    to: [to],
    subject: `Order confirmation ${orderNumber}`,
    html: `<p>Hello ${escapeHtml(firstName)},</p><p>Thank you for your order <strong>${escapeHtml(orderNumber)}</strong>.</p>`,
    text: `Hello ${firstName},\n\nThank you for your order ${orderNumber}.`
  };

  const response = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(email)
  });

  if (!response.ok) {
    const detail = await response.text();
    console.error("Volanea send failed", response.status, detail);
    return res.status(502).json({ error: "Email provider rejected the request" });
  }

  await markProcessed(input.event_id);
  return res.status(202).json({ status: "accepted" });
});

The example deliberately keeps the Volanea key in process.env.VOLANEA_API_KEY, which is populated by the middleware host’s secret manager or protected server environment. The browser receives neither the key nor the provider response credentials. The custom JTL-Shop extension should similarly authenticate to the middleware using a separate signed secret, not the Volanea key itself.

In a production implementation, replace the illustrative wasProcessed, markProcessed, and escapeHtml functions with real implementations. Also validate the event signature, constrain accepted source IPs where practical, apply rate limits, and log only the minimum personal data needed for troubleshooting.

Auth handling and secret boundaries

There are two valid credential locations, depending on the route.

For the native SMTP route, the Volanea SMTP credential belongs in JTL-Shop’s server-side mail configuration. It must be readable by the shop process and protected by the application’s administrative access controls and server filesystem or database security. Restrict access to administrators who genuinely need to edit mail settings.

For the REST middleware route, the Volanea API key belongs only in the middleware’s server-side secret store or protected environment. JTL-Shop receives a different credential for authenticating to your middleware, ideally a signed request mechanism or a narrowly scoped shared secret that can be rotated independently.

Never put either secret in:

Storefront JavaScript, HTML, or a browser network request
A public Git repository or a theme repository
A client-side tag manager
A customer-facing form field or URL parameter
A screenshot, support ticket, or unredacted log

This separation gives you practical incident response. If a JTL-Shop admin password is exposed, rotate the SMTP credential. If middleware logs leak, rotate the middleware signing secret and the Volanea key separately. If a storefront has an XSS issue, the sending key remains outside the browser.

When this breaks

Every email integration needs a failure model. With SMTP, the break can occur before Volanea accepts the message, at Volanea acceptance, during receiving-provider delivery, or in the JTL-Shop event/template layer. With middleware, there is an additional hop and therefore more retry behavior to control.

SMTP authentication or TLS failures

A failed SMTP authentication attempt usually points to a wrong credential, a credential that was revoked, a copied whitespace character, or an unsupported username/password format. A TLS failure often points to a hostname, port, or encryption-mode mismatch.

Do not solve this by disabling encryption or switching randomly between ports. Compare every setting with the current Volanea SMTP setup instructions, confirm the server can make outbound SMTP connections, then test again. Record the exact error without logging the secret.

A message is accepted but does not arrive

First distinguish acceptance from mailbox delivery. Check Volanea’s event or message information for the message identifier, recipient, timestamp, and delivery outcome. Then inspect spam, quarantines, recipient typos, suppression behavior, and domain authentication.

A test sent to the same domain as the sender is not enough. Test at least a controlled mailbox on a major external provider and check both inbox placement and rendering. The inbox result can vary by recipient history and provider policy, but SPF/DKIM alignment, a valid From domain, and useful transactional content are baseline requirements.

Missing fields in a JTL-Shop template

A missing order number, blank customer name, or empty line-item table is usually a template-data issue. Different template types have different data available because they are triggered at different points in the shop process. A field that exists in an order confirmation may not exist in a password-reset message or a contact-form notification.

Do not patch the output by guessing a variable name or adding unescaped raw data. Identify the exact template type, inspect the variables documented for that template and JTL-Shop version, then test with representative orders. If a required business field is unavailable at that stage, move the message to a stage where the data exists or use a server-side integration that retrieves it safely.

Retries and duplicate sends in the middleware route

This is the most important failure case for an HTTP design. An upstream extension may time out after posting an event even though the middleware received it. It retries. The middleware may send to Volanea successfully but time out before responding. It retries again. Without idempotency, one order confirmation becomes two or three emails.

Use event_id as a unique database key before the provider call. Mark processing states explicitly, such as received, sending, accepted, and failed. Decide how to recover a record stuck in sending: use a lease timeout, inspect the provider result where possible, and favor a manual review path for ambiguous sends rather than blindly sending again.

A short webhook timeout does not mean the send failed. Respond quickly after durable event storage, then process the send asynchronously when your architecture permits it. The upstream gets a successful acknowledgement only after the event is stored, not after a fragile chain of template rendering, provider request, and downstream delivery has completed.

Plan, version, and extension differences

Do not assume a field, hook, workflow action, or template variable exists across every JTL-Shop version, edition, installed plugin set, or related JTL product. JTL-Shop and JTL-Wawi are separate products; a capability found in one should not be described as a capability of the other.

Before committing to the REST route, prove the server-side event point in a non-production environment. Confirm what data it provides, whether it runs synchronously during checkout, what happens on an exception, and whether it survives upgrades. If that proof is not available, choose the SMTP route for essential transactional mail.

Deliverability practices for shop email

Infrastructure is only one part of deliverability. Transactional mail should be recognizable, timely, and expected. An order confirmation should have a stable sender, a clear subject, an order reference, and content matching the action the customer just performed.

Keep transactional and promotional traffic logically separate where possible. A customer waiting for a password reset should not have its delivery reputation tied unnecessarily to a high-volume marketing blast. Use distinct streams, sender identities, or subdomains according to your broader deliverability plan and the configuration available in Volanea.

Also protect your recipient quality. Obvious checkout typos such as gmal.com can produce hard bounces and customer-support work. Validate addresses at appropriate points in the customer journey, but do not turn validation into a reason to block a legitimate customer without a useful recovery path. Volanea’s free email address verification tool can help check an address during operational review or form-design testing.

Monitor more than a single success metric. Useful signals include SMTP acceptance failures, bounces, complaints, delayed delivery, suppression activity, and unusual changes in volume. A sudden spike in password-reset mail may indicate customer confusion, a broken login flow, or abuse—not merely a sending issue.

A practical rollout checklist

Use a staged rollout rather than changing production email settings during a busy sales period.

Authenticate the intended sender domain in Volanea and verify DNS records have propagated.
Create a dedicated SMTP credential for the JTL-Shop production environment.
Document the existing JTL-Shop mail settings so they can be restored if necessary.
Configure the Volanea SMTP endpoint, encryption mode, and credential in JTL-Shop’s server-side mail settings.
Send controlled test messages for an order-related email, password reset, and contact form where those flows are enabled.
Verify sender identity, reply handling, language, template variables, links, and inbox placement.
Watch Volanea delivery activity and JTL-Shop/server logs during the first production period.
Keep a rollback procedure: restore the previous SMTP configuration only if you have confirmed it remains operational.

For a REST middleware design, add an integration test that deliberately posts the same event_id twice and confirms only one provider request is made. Add another test for an invalid recipient, a provider 5xx response, and an upstream timeout. These are not edge cases; retries and malformed data happen in normal operations.

Choosing SMTP or middleware

Choose SMTP when JTL-Shop is already creating the email you need. It is the smallest operational surface area, preserves native templates, requires no duplicated order-email logic, and avoids an unnecessary web request during checkout.

Choose middleware plus REST only when there is a clear requirement that SMTP cannot satisfy: centralized cross-application templates, a custom event pipeline, detailed application-level idempotency, external data enrichment, or a message that JTL-Shop does not create itself. Treat it as a software integration project, with version control, secrets management, observability, queues, and tests.

The mistake is not choosing one route over the other. The mistake is assuming a marketplace plugin, direct webhook, or browser-side API call exists without verifying it. For core commerce messages, a correctly configured server-side SMTP connection is usually the dependable baseline.

FAQ

Can I install a native Volanea plugin from the JTL-Shop marketplace?

No native Volanea JTL-Shop app or marketplace plugin should be assumed for this integration. Use JTL-Shop’s SMTP configuration for native transactional messages, or build and maintain a server-side custom integration when REST behavior is required.

Does JTL-Shop send a JSON webhook to Volanea?

Not through the standard SMTP email route. JTL-Shop renders an email and delivers it over SMTP. If you require JSON events, a custom server-side extension or another verified integration point must send them to your middleware.

Where should the Volanea API key be stored?

For REST, store it only in server-side middleware secrets or protected environment variables. For SMTP, store the SMTP credential only in JTL-Shop’s protected server-side mail configuration. Never expose either credential in storefront code.

How do I prevent duplicate confirmation emails with middleware?

Assign every logical message a stable event_id, store it under a unique database constraint before sending, and treat retries as the same event. Do not use a new random ID for every attempt.

Why is an email accepted but not visible in the inbox?

Acceptance means the provider received the message; it does not guarantee inbox placement. Check the recipient address, spam and quarantine folders, sender-domain authentication, suppression status, and delivery events before changing the JTL-Shop configuration.

How to Send Email from JTL-Shop with Volanea