Jira can trigger useful customer and internal notifications at the moment work changes state—but a reliable setup to send email from Jira needs more than dropping a webhook URL into an automation rule. The safest pattern is Jira Automation for the trigger, a small server-side middleware endpoint for control and security, and Volanea for delivery.

This guide shows that pattern end to end. It does not assume a Volanea Jira Marketplace app or a native Jira plugin, because Volanea does not require one for this integration. Instead, Jira sends an outbound HTTP request when an issue changes status, your server validates and transforms that request, and the server calls Volanea’s REST email API.

What the Jira-to-Volanea integration looks like

The integration has three distinct hops:

A Jira Automation rule detects an issue event, such as an issue moving to a selected workflow status.
Jira Automation uses its Send web request action to POST selected issue data to a private middleware endpoint.
The middleware authenticates Jira’s request, applies business rules and deduplication, then sends the finished message through Volanea.

That middle layer matters. Jira is a workflow system, not an email-delivery control plane. A server-side endpoint gives you a safe place to store the Volanea API key, choose recipients, render HTML, record delivery attempts, prevent duplicates, and handle errors without exposing credentials in a browser or in Jira issue content.

For a simple example, imagine a support or implementation project. When an issue transitions to Ready for customer review, Jira triggers an email telling the customer that work is available, including the issue key, summary, current status, and a direct link back to Jira.

The same structure works for many operational emails:

Alert an account owner when a high-priority bug enters Escalated.
Notify a customer when a request moves to Waiting for customer.
Send an internal handoff message when an issue moves from Sales to Implementation.
Confirm that a Jira Service Management request has reached a review stage.
Send a campaign-style operational update only after a carefully defined workflow transition.

The important distinction is that Jira decides when an event is meaningful, while your middleware and Volanea decide whether and how an email should be delivered.

The real Jira trigger: Issue transitioned

For this implementation, use Jira Automation’s Issue transitioned trigger. In Jira terminology, an issue is transitioned when it moves through a workflow from one status to another—for example, In Progress to Ready for customer review.

This trigger is better than polling Jira for changed issues. Polling creates delay, can miss context about the transition, and forces your application to decide whether an update was important. An automation rule evaluates the workflow event as it happens and can filter it before an outbound request is created.

Recommended rule design

Create a project-level automation rule when the email applies to one project, or a global/multi-project rule when the workflow and recipient policy are shared. A practical rule has four parts:

Trigger: Issue transitioned.
Condition: The destination status equals the workflow status that should cause an email.
Optional conditions: Restrict by issue type, request type, priority, organization, component, label, or a custom field that explicitly permits notification.
Action: Send web request to your middleware endpoint.

Do not use every status change as an email trigger by default. Jira issues often move back and forth during normal work. Emailing on every transition quickly becomes noisy, produces duplicate-looking messages, and makes customers distrust operational notifications.

A targeted condition is more defensible. For example, send only when the issue transitions to Ready for customer review, when the issue type is Customer request, and when a custom checkbox called Send customer update is checked.

Why a transition is more reliable than “issue updated”

An Issue updated trigger can fire for a broad set of events: a comment, description edit, field update, assignment change, automation update, or transition. That may be correct for internal alerts, but it is usually too broad for customer-facing email.

A transition gives you a meaningful business event with a clearer audit trail. Your recipients can understand why they were contacted: the request reached a specific workflow stage. It also makes idempotency easier, because the middleware can store a record for a particular issue and resulting status.

Why Jira should call middleware instead of Volanea directly

Jira Automation can make outbound web requests, so a direct POST from the rule to an email API may look attractive. In practice, direct delivery removes controls you will want as soon as the workflow is used by more than one person or project.

The most important issue is credential handling. A Volanea API key grants the ability to send email from your configured sender identity. It is a server credential, not a value that belongs in a client-side application, a public repository, a Jira description, an issue comment, or a user-editable field.

A Jira automation rule is configured in Jira’s administration context, not in a browser bundle, but it is still not an ideal long-term secrets vault for a powerful email-sending credential. Rule editors and administrators may be able to view or modify request configuration. Audit logs can also make troubleshooting sensitive if teams put secrets into request bodies, URLs, or diagnostic messages.

Use this division of responsibility instead:

Store VOLANEA_API_KEY in your middleware platform’s encrypted environment-variable or secrets manager facility.
Store a separate, limited shared secret for the Jira-to-middleware hop, such as JIRA_WEBHOOK_SECRET.
Put that Jira shared secret in the Jira Automation request header only if your Jira administration and rule-editing access model permits it; otherwise use a gateway that can verify Jira-originated traffic another way.
Never put the Volanea key in the Jira request body, an issue custom field, frontend JavaScript, or a Jira Automation smart value.

This separation limits blast radius. If a Jira rule needs to be replaced, you rotate the small inbound secret without rotating the credential that can send email. If the middleware needs to change providers or message logic, Jira’s workflow rule remains stable.

For email API request fields, sender-domain setup, and the current request schema, use the email API reference and setup guides as the source of truth before deploying. API contracts can evolve, while the middleware boundary lets you update one server-side integration rather than editing many Jira rules.

Configure the Jira Automation web request

After creating the Issue transitioned trigger and your conditions, add Jira Automation’s Send web request action. Point it at an HTTPS endpoint that you control, such as:

https://jira-email.example.com/hooks/jira/issue-transitioned

Choose the POST method and configure the request as JSON. Add these headers:

Content-Type: application/json
X-Jira-Email-Secret: YOUR_JIRA_TO_MIDDLEWARE_SHARED_SECRET

The second header is not the Volanea API key. It only authenticates Jira to your middleware. Treat it as sensitive anyway: do not paste it into tickets, screenshots, rule descriptions, or documentation that people outside the automation-admin group can access.

Payload Jira sends in this implementation

Jira Automation’s Send web request action lets you define the JSON body and substitute Jira smart values. Use the following request body. The jsonEncode calls are deliberate: summaries, descriptions, names, and URLs can contain quotes, line breaks, emoji, or other characters that would otherwise produce invalid JSON.

{
  "eventType": "jira.issue.transitioned",
  "issue": {
    "id": "{{issue.id}}",
    "key": "{{issue.key}}",
    "summary": {{issue.summary.jsonEncode}},
    "description": {{issue.description.jsonEncode}},
    "status": {
      "id": "{{issue.status.id}}",
      "name": {{issue.status.name.jsonEncode}}
    },
    "priority": {{issue.priority.name.jsonEncode}},
    "reporter": {
      "displayName": {{issue.reporter.displayName.jsonEncode}},
      "emailAddress": {{issue.reporter.emailAddress.jsonEncode}}
    },
    "assignee": {
      "displayName": {{issue.assignee.displayName.jsonEncode}},
      "emailAddress": {{issue.assignee.emailAddress.jsonEncode}}
    },
    "url": "{{baseUrl}}/browse/{{issue.key}}",
    "updated": "{{issue.updated}}"
  },
  "notification": {
    "recipient": {{issue.Customer Email.jsonEncode}},
    "allowed": "{{issue.Send customer update}}"
  }
}

This is the actual payload shape your rule will POST after Jira expands its smart values. Replace Customer Email and Send customer update with the exact custom-field names used in your Jira project. If your field names differ, the smart values must differ too.

Do not assume that every Jira issue has every field. An assignee may be empty, a reporter email address may be unavailable based on Jira privacy settings, and a custom field may not exist on all issue types or request forms. The middleware should treat missing optional data as normal input, not as a reason to send a malformed email.

A safer recipient policy

The sample maps a custom Customer Email field into notification.recipient. That is suitable only if the field is controlled, validated, and intended for outbound notification.

For higher-risk workflows, avoid accepting a destination address directly from a Jira issue. Instead, send a stable customer or organization identifier to middleware, then look up approved recipients in your CRM, application database, or customer-notification preferences service. That prevents an accidental issue edit from redirecting an automated email to an unapproved address.

Before accepting any recipient, normalize it, validate it, and apply suppression or consent rules appropriate to the email’s purpose. For a quick preflight check during development, you can use the email address verification tool, but production systems should still enforce their own recipient and subscription policies.

Middleware code: validate Jira, map fields, send through Volanea

The following Node.js example shows the logic for a small server-side endpoint. It intentionally keeps Volanea credentials in environment variables. It also accepts a configurable VOLANEA_EMAIL_API_URL so the deployment can use the precise current send-email endpoint documented for the account rather than hard-coding an unverified route in Jira.

The expected Volanea request body is mapped in one place: sender, recipient, subject, HTML, text, and tags. Set VOLANEA_EMAIL_API_URL and any account-specific authorization header requirements from Volanea’s current API documentation in your server environment.

import express from "express";
import crypto from "node:crypto";

const app = express();
app.use(express.json({ limit: "256kb" }));

const {
  JIRA_WEBHOOK_SECRET,
  VOLANEA_API_KEY,
  VOLANEA_EMAIL_API_URL,
  VOLANEA_FROM_EMAIL = "updates@example.com"
} = process.env;

// Replace with Redis, Postgres, DynamoDB, or another durable store in production.
const processedTransitions = new Map();

function escapeHtml(value = "") {
  return String(value)
    .replaceAll("&", "&amp;")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#39;");
}

function safeEqual(left = "", right = "") {
  const a = Buffer.from(left);
  const b = Buffer.from(right);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

app.post("/hooks/jira/issue-transitioned", async (req, res) => {
  const providedSecret = req.get("X-Jira-Email-Secret") || "";
  if (!safeEqual(providedSecret, JIRA_WEBHOOK_SECRET || "")) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  const { eventType, issue = {}, notification = {} } = req.body || {};
  if (eventType !== "jira.issue.transitioned") {
    return res.status(400).json({ error: "Unsupported event type" });
  }

  const recipient = String(notification.recipient || "").trim();
  const allowed = String(notification.allowed || "").toLowerCase() === "true";
  const issueKey = String(issue.key || "");
  const statusId = String(issue.status?.id || "");
  const updated = String(issue.updated || "");

  if (!allowed) {
    return res.status(202).json({ skipped: "Notification not permitted" });
  }

  if (!issueKey || !statusId || !updated || !recipient) {
    return res.status(422).json({
      error: "Required Jira fields are missing",
      required: ["issue.key", "issue.status.id", "issue.updated", "notification.recipient"]
    });
  }

  // A retry of the same transition keeps the same key and is not sent twice.
  const idempotencyKey = `jira:${issue.id}:${statusId}:${updated}`;
  if (processedTransitions.has(idempotencyKey)) {
    return res.status(200).json({ duplicate: true, idempotencyKey });
  }

  const subject = `[${issueKey}] ${issue.status?.name || "Status updated"}: ${issue.summary || ""}`;
  const issueUrl = String(issue.url || "");
  const description = String(issue.description || "No additional details were provided.");

  const emailPayload = {
    from: VOLANEA_FROM_EMAIL,
    to: [recipient],
    subject,
    html: `
      <h1>Update for ${escapeHtml(issueKey)}</h1>
      <p><strong>Status:</strong> ${escapeHtml(issue.status?.name || "Updated")}</p>
      <p><strong>Summary:</strong> ${escapeHtml(issue.summary || "")}</p>
      <p>${escapeHtml(description).replaceAll("\n", "<br>")}</p>
      <p><a href="${escapeHtml(issueUrl)}">Open ${escapeHtml(issueKey)} in Jira</a></p>
    `,
    text: `${issueKey} is now ${issue.status?.name || "updated"}.\n\n${issue.summary || ""}\n\n${description}\n\n${issueUrl}`,
    tags: [
      { name: "source", value: "jira" },
      { name: "issue_key", value: issueKey },
      { name: "status", value: String(issue.status?.name || "unknown") }
    ]
  };

  const volaneaResponse = await fetch(VOLANEA_EMAIL_API_URL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify(emailPayload)
  });

  const responseText = await volaneaResponse.text();
  if (!volaneaResponse.ok) {
    console.error("Volanea send failed", {
      status: volaneaResponse.status,
      body: responseText,
      issueKey,
      idempotencyKey
    });
    return res.status(502).json({ error: "Email provider request failed" });
  }

  processedTransitions.set(idempotencyKey, Date.now());
  return res.status(202).json({ accepted: true, idempotencyKey });
});

app.listen(process.env.PORT || 3000);

Field mapping explained

The mapping is intentionally explicit:

issue.key becomes a human-recognizable support or work reference in the subject and message.
issue.status.name tells the recipient why the email was sent.
issue.summary becomes the primary plain-language description.
issue.description provides useful detail but is HTML-escaped before inclusion in the HTML body.
issue.url becomes a link back to Jira for authorized recipients.
notification.recipient becomes the email destination only after the middleware verifies the notification is allowed.
issue.id, status.id, and updated build the idempotency key.

If you use a template system, do not interpolate Jira descriptions as raw HTML. Jira issue descriptions can include text you did not author, links, pasted markup-like content, or user-generated details. Treat the input as untrusted and escape it, as the example does.

Sender identity, deliverability, and message design

A Jira-triggered notification is only useful if recipients recognize and trust it. Use a verified sender domain and a mailbox or subdomain that clearly reflects the purpose, such as updates@notifications.example.com or support@example.com.

Do not send customer updates from an arbitrary employee mailbox. Operational email benefits from a stable identity, predictable reply handling, and authentication aligned with the organization’s domain. Configure the sender identity and domain authentication before enabling the Jira rule for real recipients.

Keep transactional and promotional intent separate

A status update for a customer’s active request is generally transactional or operational. A broad announcement about product changes, upgrades, or marketing offers is different. Do not repurpose a workflow transition as a reason to send promotional content to everyone connected to an issue.

This distinction affects recipient expectations, consent, suppression handling, and inbox placement. Your middleware should make the message class explicit. A clean operational template has a specific trigger, an understandable subject, a reference to the recipient’s request, and a direct way to get help.

Design for replies and support ownership

Before launch, decide what happens if someone replies. If the From address is not monitored, use a Reply-To address that reaches a support queue, or explain how to respond through the issue portal. A customer should not need to guess whether an update email is a dead end.

Also avoid placing sensitive Jira data into an email. Jira URLs, issue summaries, descriptions, reporter names, and internal comments may reveal information that the recipient should not see. Send the minimum necessary detail, and link to Jira only when the recipient is authorized to access that project.

When this breaks: Jira-to-email failure modes

Every integration should be designed around the ways it can fail. The key is to make failures observable and safe rather than silently losing a message or sending it twice.

Jira retries can create duplicate sends

Jira may retry an outbound web request when it does not receive a successful response. A network interruption can produce the most dangerous version of this problem: your middleware sends the email successfully, but Jira never receives the response and sends the request again.

That is why the middleware creates and stores an idempotency key. The example uses issue ID, destination status ID, and issue updated time. In production, persist that key in a database before or alongside the provider request, and enforce uniqueness at the data-store level. An in-memory map is only illustrative; it resets when a server restarts and will not coordinate multiple instances.

If Volanea supports idempotency keys on the send endpoint for your account and API version, pass the same key downstream as well. That gives you protection at two layers: your own integration and the provider’s API.

Webhook timeouts can turn success into uncertainty

Jira’s outbound request waits for your endpoint to respond. If your server spends too long rendering templates, querying multiple systems, or waiting on an email API, Jira can time out. A timeout does not always mean the email failed; it may mean Jira could not confirm the result.

Respond quickly. A robust architecture writes the validated event to a durable queue or database, returns a success response, then processes delivery asynchronously. If immediate sends are sufficient at your volume, keep the request path short and set conservative HTTP timeouts for the Volanea call.

Do not return 200 OK before persisting the event somewhere durable. Otherwise a process crash after the response can cause a quiet lost message. The correct order is: authenticate, validate, record an idempotent job, then acknowledge Jira.

Payload fields may be missing or unavailable

Jira fields are not universally present. An assignee can be absent. A custom field may not appear on a particular issue type, screen, request type, or Jira plan configuration. User email addresses can be unavailable depending on privacy settings and product configuration.

Build the middleware to validate only fields that are truly required. In the example, the recipient, issue key, status ID, and updated timestamp are required. Reporter and assignee email addresses are optional and should not control the send path unless your workflow explicitly depends on them.

When a required field is absent, return a clear error to Jira and log the issue key plus the missing field names—never the full recipient address or API key. Then use the Jira Automation audit log to identify whether the automation rule, field context, or issue data caused the failure.

Automation loops can create mail storms

A common loop occurs when the automation rule adds a comment, edits a field, or transitions an issue after sending an email, while another rule listens for that update. The result can be repeated execution that looks like a delivery problem but is actually a workflow design problem.

Use narrow triggers and conditions. Mark processed events with a dedicated field only if that field update cannot retrigger the same rule unexpectedly. More often, durable middleware idempotency is safer than relying on an issue edit to prevent another send.

Recipient data can be unsafe or wrong

Custom email fields are convenient, but they can contain typos, stale addresses, multiple addresses, or values copied from untrusted sources. Validate format, apply your recipient policy, and consider allowlisting domains for internal-only workflows.

For sensitive notifications, do not include the full issue description. Send a brief notification and require authenticated access to Jira or your customer portal for the underlying details.

Testing the integration before production

Test with a dedicated Jira project, a non-production sender identity where appropriate, and inboxes controlled by your team. Do not start by connecting a live service desk workflow to a customer list.

Use this test sequence:

Transition a test issue to the chosen status with a valid recipient field.
Confirm the Jira Automation audit log shows a successful web request.
Inspect middleware logs for the issue key, idempotency key, and provider response status.
Confirm the email renders correctly in a real inbox and links to the expected Jira issue.
Repeat the same request or simulate a retry and confirm only one email is delivered.
Test an issue with no assignee, no description, and an empty optional field.
Test a missing recipient and confirm the rule fails safely without calling Volanea.
Test a transition out of and back into the target status to verify your intended resend behavior.

Keep test logs structured. At minimum, record a request correlation ID, Jira issue ID, issue key, target status, idempotency key, message classification, recipient count, Volanea response status, and provider message identifier if available. Avoid logging full HTML bodies, raw descriptions, credentials, or unnecessary personal data.

Alternatives: direct web request, Zapier or Make, and custom apps

The middleware route is the best default for teams that care about credential isolation, customization, and reliable delivery. It is not the only route.

Direct Jira Automation to Volanea

A direct request is the shortest path: Jira Automation’s Send web request action POSTs an email payload to Volanea. It can be acceptable for a tightly controlled internal proof of concept where no sensitive issue data is involved and automation-rule access is restricted.

Its tradeoffs are substantial: the email credential is coupled to a Jira rule, complex recipient logic is awkward, durable idempotency is limited, and debugging provider failures in a workflow UI is less capable than server-side logging. Move to middleware before the integration becomes business-critical.

Zapier or Make as middleware

Zapier and Make can bridge Jira to an HTTP email API without deploying code. They are useful for prototypes, low-volume workflows, and teams that need visual automation.

However, evaluate retries, replay behavior, secret handling, transformation limits, data retention, and cost before making a no-code scenario the system of record for customer notifications. You still need duplicate prevention and a careful recipient policy.

Forge, Connect, or a custom Jira app

A custom Jira app can provide deeper integration, richer UI, and more controlled configuration for organizations with complex workflows. It is appropriate when you need administrators to configure templates, recipient rules, project mappings, or audit views inside Jira.

That approach requires application development, permissions design, lifecycle management, and Jira platform expertise. For a single transition-to-email workflow, Jira Automation plus a small HTTP service is usually simpler and easier to operate.

Operational checklist for a production rollout

Before enabling the rule for customers or a large internal audience, confirm the following:

The trigger is a specific Issue transitioned event, not a broad update trigger.
Conditions limit sends to the intended project, issue type, and destination status.
The Jira payload uses JSON encoding for text fields.
The Volanea API key exists only in encrypted server-side configuration.
Jira authenticates to middleware with a separate inbound secret or gateway control.
The middleware validates required fields and rejects invalid recipients.
Sender identity and domain authentication are configured for the chosen From address.
HTML output escapes all Jira-provided text.
Idempotency is durable across retries, process restarts, and multiple server instances.
Failed sends are logged, monitored, and retried deliberately rather than blindly.
The message contains only information the recipient is authorized to receive.
Your team has a documented owner for replies, bounces, and delivery incidents.

These controls are not overengineering. They are what makes an automated notification trustworthy after the first happy-path test.

Conclusion

To send email from Jira reliably, treat Jira as the event source rather than the email engine. Use an Issue transitioned automation rule to identify the workflow moment that matters, send a structured JSON web request to a private endpoint, and let that endpoint securely map the issue data into a Volanea email request.

This pattern protects the Volanea API key, gives you room for templates and recipient rules, and handles the practical realities of retries, timeouts, missing fields, and duplicate delivery. Start with one narrowly scoped workflow transition, test the edge cases, and expand only after the audit trail and failure handling are working.

FAQ

Can Jira send email through Volanea without a Marketplace app?

Yes. Jira Automation can use the Send web request action to notify a server-side endpoint, and that endpoint can call Volanea’s REST email API. No native Volanea Jira app or Marketplace installation is required for this approach.

What Jira event should trigger the email?

Use the Issue transitioned trigger when the email corresponds to a meaningful workflow movement, such as an issue entering Ready for customer review. Add conditions so routine status changes do not become unnecessary email.

Where should the Volanea API key be stored?

Store it only in encrypted server-side environment configuration or a secrets manager used by your middleware. Do not store it in Jira issue fields, frontend code, public repositories, or client-visible configuration.

How do I stop duplicate emails when Jira retries a web request?

Create a durable idempotency key for the transition, store it in a database with a uniqueness constraint, and treat a repeated key as already processed. Pass that same key to the email API when supported.

Why is a middleware endpoint better than calling the email API directly from Jira?

Middleware keeps the sending credential out of the automation rule, validates dynamic Jira fields, applies recipient and content policy, records delivery attempts, and gives you reliable deduplication and error handling.

How to Send Email From Jira with Volanea