How to Send a Transactional Email from n8n Using Volanea

Sending a transactional email from n8n does not require a native app integration: n8n can call Volanea’s REST API directly from an HTTP Request node. This guide shows the honest, production-ready pattern to send transactional email from n8n while keeping credentials protected, mapping workflow data safely, and avoiding duplicate sends.

First, clarify what the n8n Send Email node does

There is an important distinction to make before building the workflow. n8n’s built-in Send Email node is an SMTP client: it connects to an SMTP server and sends a message through that server. It is not an outbound webhook service, and it does not emit a standard “Send Email From n8n” webhook payload that another platform can receive.

That means there is no Volanea app to install in n8n, no native Volanea action to select from the node menu, and no webhook payload produced by the Send Email node that you should forward elsewhere. If your goal is to send through Volanea, use one of these two patterns instead:

1. REST API pattern: Use n8n’s HTTP Request node to make a POST request to Volanea’s send endpoint. This is the approach covered in this guide.
2. SMTP pattern: Configure the n8n Send Email node with Volanea SMTP relay credentials, if SMTP is the better fit for your workflow.

The REST approach is usually the clearest choice when your workflow already has structured data—an order number, an account ID, a recipient address, a template variable, or an event ID. You can see the full REST endpoint and setup details in the email API reference and setup guides.

This article focuses on the REST route because it gives you explicit JSON payloads, reusable HTTP credentials, request-level idempotency, and a direct response that n8n can route into later steps.

What you will build

The finished workflow has a simple responsibility: receive or assemble event data, validate the email inputs, then submit one transactional message to Volanea.

A common version looks like this:

Webhook or app trigger
        ↓
Edit Fields or Code node
        ↓
Optional validation / IF node
        ↓
HTTP Request: POST Volanea /v1/send
        ↓
Optional logging, CRM update, or response

For a concrete example, imagine an application sends n8n an order.paid event. The workflow uses that event to send the buyer a receipt.

The message data might include:

• Recipient email address
• Customer first name
• Order number
• Total paid
• Currency
• Receipt URL
• Event ID, used to prevent duplicate sends

The workflow does not need to construct SMTP commands or manage an SMTP connection. Instead, it converts this event data into Volanea’s JSON email request.

Why HTTP Request is the right n8n node

n8n’s HTTP Request node can call any REST API. It supports an HTTP method, URL, request headers, JSON body, and generic authentication options. That makes it suitable when a service does not have a dedicated native n8n node.

Using HTTP Request also makes the integration visible and portable. Anyone reviewing the workflow can see the destination endpoint, inspect the JSON body, understand which upstream values are mapped, and test the request without reverse-engineering an SMTP credential.

The trade-off is that you are responsible for entering the endpoint, authentication header, and body correctly. That is a good trade-off for transactional email because the message itself is an important business event, not an opaque background action.

Prerequisites before you send

Set up the sending side before you build the n8n workflow. A correct API request alone cannot make an unverified sender address appropriate for production mail.

You need:

1. A Volanea project and secret API key. Volanea secret keys use sk_… or sk_test_… prefixes. Use a test key while building the workflow and a live key only after you have validated the entire send path.
2. A verified sending domain and sender address. Your from address must belong to a domain you have configured for sending. Use a recognizable sender such as Billing <receipts@notify.example.com> rather than a personal inbox.
3. An n8n workflow with a trigger. This can be a Webhook node, a schedule, a database trigger, a form submission, or an app-specific trigger.
4. A stable event identifier. For example, an order ID, support-ticket ID, account ID plus event type, or another value that uniquely represents the message you intend to send.
5. A safe place for credentials. Put the API key into an n8n credential, not directly into a Code node, Set node, or workflow export.

A practical early decision is whether the email should be test-only or customer-facing. A Volanea test secret key is useful for exercising the workflow and reviewing the resulting request path without risking an accidental production email. Once mappings and sender configuration are verified, replace the credential with the live key.

Choose the event boundary carefully

Transactional email should be tied to a business event that has actually happened. For a receipt, that is usually a confirmed payment event—not “checkout started.” For a password-reset email, it is a successfully created reset token—not simply a form submission. For an invitation, it is the completed invitation record—not a button click before the record is saved.

This distinction reduces the chance of inconsistent mail. If an upstream system retries a request, the event ID and idempotency key described later in this guide ensure that “retry” does not silently become “send a second receipt.”

The real payload n8n receives and sends

The phrase “webhook payload from Send Email in n8n” is misleading because the Send Email node sends through SMTP; it does not post a standard outbound webhook body. The payload you work with in this design comes from your workflow trigger—for example, the application, form, payment system, or database event that starts the workflow.

If you use an n8n Webhook node, n8n exposes the incoming request data in its workflow item. Webhook data commonly includes request areas such as headers, params, query, and body. The exact fields inside body are defined by the service calling your webhook, not by n8n.

For example, your own application could trigger n8n with this JSON request body:

{
  "event": "order.paid",
  "eventId": "evt_01JQ7N3Y5YX9S4G8K8Z0R5Q6P1",
  "order": {
    "id": "ord_10482",
    "total": 49.00,
    "currency": "USD",
    "receiptUrl": "https://app.example.com/orders/ord_10482/receipt"
  },
  "customer": {
    "email": "alex@example.net",
    "firstName": "Alex"
  }
}

Inside n8n, an expression can access the customer address with:

{{$json.body.customer.email}}

And the stable send identifier with:

{{$json.body.eventId}}

That example is an application-defined event body. It is not a special payload generated by the Send Email node. If your workflow starts from Stripe, HubSpot, a form tool, PostgreSQL, or another n8n trigger, inspect that trigger’s execution data and update the expressions to match its actual fields.

Inspect before you map

Do not guess at incoming property names. Run the trigger once with representative test data, then open the node execution in n8n and inspect the JSON output. n8n data moves through workflows as items, with each item carrying a json object; an expression such as $json.customer.email reads a field from the current item.

This matters because the same concept can appear in different shapes:

{
  "email": "alex@example.net"
}

{
  "customer": {
    "email": "alex@example.net"
  }
}

{
  "data": {
    "attributes": {
      "email": "alex@example.net"
    }
  }
}

All three contain a recipient, but they need different n8n expressions. Confirm the input before activating a customer-facing workflow.

Build a normalized email event in n8n

Avoid making your final HTTP request depend on a deeply nested third-party payload in ten different places. Instead, add an Edit Fields node before the HTTP Request node and create a small, normalized object with the exact business values your email needs.

For the order receipt example, create these fields:

After that node, the item can look like this:

{
  "recipient": "alex@example.net",
  "firstName": "Alex",
  "orderId": "ord_10482",
  "total": 49,
  "currency": "USD",
  "receiptUrl": "https://app.example.com/orders/ord_10482/receipt",
  "sendKey": "evt_01JQ7N3Y5YX9S4G8K8Z0R5Q6P1"
}

This is not only easier to read. It separates your email contract from the upstream trigger’s implementation. If the payment platform later changes order.total to payment.amount, you update one mapping node rather than rebuilding the message request.

Validate before making the API call

Email is a side effect: once a send request is accepted, you should assume a recipient may receive it. Add a simple IF node before the HTTP Request node when the upstream source is not fully controlled.

At minimum, check that:

• recipient exists and is not blank.
• recipient is an expected string value.
• orderId or another business identifier exists.
• sendKey exists and is stable across retries.
• The event type is one you intend to email about.

For higher-risk workflows, validate that the event status is final. For example, send only if paymentStatus equals paid, not if it is merely pending or authorized.

You can optionally check addresses before adding them to a sensitive flow with the free email address verification tool. Verification is useful for intake and data-cleaning scenarios, but it should not replace consent, suppression handling, or sound transactional-email logic.

Configure the Volanea HTTP Request node

Add an HTTP Request node after your normalized event step. This node submits the email to Volanea.

Use these request settings:

Volanea’s single-message endpoint is POST /v1/send. It accepts one message addressed to one recipient or a list of recipients, up to the endpoint’s documented limit. The endpoint runs the send pipeline, including suppression checking, contact upsert, message rendering, tracking instrumentation, and dispatch.

Store the API key as an n8n credential

Create a generic Header Auth credential in n8n rather than typing the secret into the node body. Configure it to send the Volanea secret API key in the Authorization header.

The request headers should be:

Authorization: Bearer sk_test_your_secret_key
Content-Type: application/json
Idempotency-Key: order-receipt-evt_01JQ7N3Y5YX9S4G8K8Z0R5Q6P1

Use a test key while you are experimenting. When you are ready for production, create or update the credential with a live secret key rather than scattering key changes across nodes.

Do not put your key in an expression that reads from webhook data. An external caller must never be able to influence the API credential, sender address, or endpoint URL. The trigger supplies customer and event values; your workflow owns the authorization and sending policy.

Use a stable idempotency key

The Idempotency-Key header is one of the most important parts of this integration. It tells Volanea that retries of the same logical email should not create multiple sends. A repeated key replays the stored result instead of sending a duplicate message.

For the receipt example, set the header value with an n8n expression:

{{'order-receipt-' + $json.sendKey}}

Do not generate a fresh random UUID inside a retrying workflow. That defeats idempotency because each retry looks like a new logical request. Also avoid using a timestamp as the only key; time changes on every execution.

Good idempotency keys are deterministic and descriptive:

order-receipt-ord_10482
password-reset-user_8401-token_29d6
invite-team_209-member_883
subscription-renewal-inv_7303

A key should represent one intended message. If you deliberately need to send a second receipt, follow-up, or corrected invoice, use a different logical event ID and therefore a different key.

Use this working Volanea request body

In the HTTP Request node, choose JSON for the request body and use a body like the following. The fields map from the normalized n8n item created earlier.

{
  "from": "Acme Billing <receipts@notify.example.com>",
  "to": ["{{$json.recipient}}"],
  "subject": "Your receipt for order {{$json.orderId}}",
  "html": "<p>Hi {{$json.firstName || 'there'}},</p><p>Thanks for your payment of <strong>{{$json.currency}} {{$json.total}}</strong> for order <strong>{{$json.orderId}}</strong>.</p><p><a href=\"{{$json.receiptUrl}}\">View your receipt</a></p>",
  "text": "Hi {{$json.firstName || 'there'}},\n\nThanks for your payment of {{$json.currency}} {{$json.total}} for order {{$json.orderId}}.\n\nView your receipt: {{$json.receiptUrl}}"
}

Replace the sender address with an address on a domain you have verified in Volanea. The display name is optional, but using one makes the sender easier to recognize in the recipient’s inbox.

The to field is shown as an array so the body is explicit about recipient boundaries. Keep a transactional receipt to the intended customer unless the business event genuinely requires multiple recipients. A list of addresses should never become a substitute for a campaign tool or an undisclosed bulk-mail pattern.

Why include both HTML and text

The HTML field gives you control over basic structure, links, emphasis, and branded design. The text field provides a readable fallback for recipients whose clients prefer plain text, security tooling that strips HTML, or assistive setups where a simple message is more useful.

Write the text version intentionally. Do not just remove tags and assume it is good enough. The plain-text receipt should still include the payment amount, order number, and a full destination URL.

Keep dynamic HTML safe

Workflow values can contain quotes, ampersands, angle brackets, or unexpected text. If fields such as names, organization names, support notes, or product titles are inserted into HTML, escape or sanitize them before composing the final HTML string.

For controlled values like an internally generated order ID, the risk is usually low. For user-provided content, such as a support-agent note or form message, do not inject the raw string into HTML without a deliberate encoding step. A Code node can sanitize structured values before the HTTP Request node, or you can use a provider-hosted template with controlled variables.

Test the workflow safely

Test the workflow with a mailbox you control before you expose it to real events. The goal is to verify the entire chain: trigger data, transformations, headers, API response, sender identity, recipient rendering, and inbox behavior.

A reliable test sequence is:

1. Set the Volanea credential to a test key.
2. Trigger the workflow with a known sample event.
3. Inspect each n8n node’s input and output.
4. Confirm that the HTTP Request body contains the expected rendered recipient, subject, and links.
5. Confirm the request includes a stable Idempotency-Key.
6. Review Volanea’s returned JSON in the HTTP Request node output.
7. Repeat the exact same event once to confirm that idempotency prevents an unintended duplicate action.
8. Switch to a live key only when the workflow behaves as expected.

During testing, do not use a placeholder production recipient that might belong to someone else. Use a controlled mailbox and verify both HTML and plain-text rendering.

Use test and production URLs correctly

If your workflow begins with an n8n Webhook node, n8n provides separate test and production webhook URLs. The test URL is intended for building and inspecting input data. The production URL is registered when the workflow is published and is the one an external service should call in normal operation.

A common mistake is to copy the test URL into an application configuration and wonder why production events stop working later. Test URLs exist for interactive development; production triggers should target the production webhook URL after the workflow is published.

Return a useful webhook response

If your application calls an n8n Webhook node synchronously, add a Respond to Webhook node after the Volanea request. Return a small result to the caller rather than exposing the entire provider response or internal workflow data.

For example:

{
  "accepted": true,
  "eventId": "{{$json.sendKey}}",
  "message": "Transactional email request submitted"
}

Do not return the Volanea secret key, raw authorization headers, or arbitrary error internals. An external caller needs to know whether their event was accepted; they do not need a map of your email infrastructure.

Make the workflow reliable in production

The technical act of posting JSON is easy. Reliable transactional email comes from what happens around that request: retry behavior, event ownership, error routing, and observability.

Separate delivery submission from delivery outcome

A successful API response means Volanea accepted and processed the send request. It should not be interpreted as proof that the recipient opened the email or that the message reached the final inbox. Downstream delivery can involve bounces, deferrals, mailbox-provider filtering, and recipient actions.

Design your workflow around stages:

• Event received: n8n got the order, account, or application event.
• Send submitted: n8n successfully called Volanea’s API.
• Delivery event received: a later email event indicates delivered, bounced, complained, or another status.
• Business record updated: your database or CRM records the relevant state.

For critical flows such as password resets, receipts, and account security notifications, this distinction prevents false confidence. “Sent” is not the same as “delivered,” and “delivered” is not the same as “read.”

Decide how failures should behave

An HTTP failure can be transient or permanent. A timeout, temporary network problem, or server error may be safe to retry with the same idempotency key. A malformed recipient address or missing required field should go to an error path for correction rather than repeated automatically.

A good workflow has separate paths for:

• Input validation failures
• Authentication failures
• HTTP timeouts and connection failures
• Rate limiting or temporary provider errors
• API validation errors
• Successfully submitted messages

Enable retry behavior only when the retry uses the same logical event and the same idempotency key. If the upstream trigger itself retries, your deterministic key protects the recipient from duplicate messages across both systems.

Preserve an audit trail

For business-critical messages, store a compact record after a successful send submission. A database table, data store, CRM activity, or internal event log can capture:

• Your event ID
• Idempotency key
• Recipient address or a privacy-appropriate reference
• Email category, such as receipt or password_reset
• Volanea response identifier, if returned
• Workflow execution ID
• Timestamp

This gives support and engineering teams a way to answer practical questions: Was a receipt requested? Which order triggered it? Did n8n submit it once or multiple times? Was the workflow using the correct sender?

Avoid logging full message bodies when they include sensitive information. Transactional mail can contain order details, account identifiers, reset URLs, personal names, or support content. Record only what you need to troubleshoot responsibly.

Templates, volume, and workflow design choices

Inline HTML is a good starting point for a small receipt or alert. It becomes harder to maintain when multiple workflows need the same branding, localization, legal footer, or complex conditional layout.

Volanea supports reusable templates addressed by templateId, allowing a send request to refer to stored content rather than carrying all markup every time. That is useful when the workflow should pass structured variables while the email team controls the shared template.

When inline content is enough

Use inline html and text content when:

• The message is short and rarely changes.
• One workflow owns the email.
• You are prototyping an integration.
• The dynamic content is simple.
• You need the email content visible directly in the n8n workflow.

A payment receipt, internal alert, or one-off operational notification often fits this model well.

When a template is better

Use a reusable template when:

• Several workflows send the same message category.
• Branding changes frequently.
• You support multiple locales.
• Marketing, support, and engineering need a shared content review process.
• Conditional layout would make an n8n JSON string difficult to maintain.

Keep the workflow responsible for event mapping and delivery policy. Keep the template responsible for presentation. This separation means a design update does not require editing every automation.

Do not turn transactional mail into bulk mail

A transactional trigger should produce a message because of a specific customer action or account event. If your workflow starts selecting hundreds of contacts based on engagement, lifecycle stage, or audience membership, it is moving into campaign territory.

That distinction matters operationally. Transactional email should prioritize event relevance, predictable timing, and direct recipient value. Promotional or audience-based sends need consent rules, unsubscribe handling, frequency controls, and campaign review.

For a legitimate high-volume event, batch processing may be appropriate. Volanea’s batch endpoint can submit up to 1,000 personalized messages in a call, with per-message results. But do not use batching simply to hide a campaign inside a transactional workflow. Choose the sending model that matches the message’s purpose.

Troubleshooting common n8n and API issues

Most integration problems happen before the message is actually submitted. Work from the workflow input toward the API response rather than changing several settings at once.

The recipient expression is blank

Open the execution data for the node immediately before the HTTP Request node. Check whether the expected property exists and whether you are referencing the right level of the object.

For example, these are not interchangeable:

{{$json.email}}
{{$json.customer.email}}
{{$json.body.customer.email}}

Use the expression editor’s preview with a real test execution. If the value is blank, fix the mapping in the normalized event step before touching the Volanea request.

The API returns an authentication error

Check that the HTTP Request node is using the intended saved credential and that the key matches the intended environment. A test key and a live key represent different sending contexts.

Also verify the header format. The key belongs in the authorization header, not in the JSON request body, a URL query string, a recipient field, or an inbound webhook header supplied by an external caller.

The sender address is rejected or mail is not ready for production

Confirm that the sender address belongs to a verified sending domain in Volanea. Sender verification and DNS authentication are not optional polishing steps; they are part of establishing legitimate mail identity and supporting deliverability.

Use a consistent From domain for related mail streams. If receipts come from one unverified-looking address, password resets from another, and alerts from a third, recipients and mailbox providers have a harder time understanding your sending identity.

A retry produced more than one email

Review the Idempotency-Key value in each execution. If it changes on every run, the system cannot recognize the attempts as retries of the same action.

Fix the key to use a stable business event identifier. Then test by running the identical input more than once. A correct retry strategy reuses the key; a new business event uses a new key.

A self-hosted n8n workflow cannot call a local service

This issue is usually unrelated to Volanea but often appears during testing with a local webhook receiver or internal helper service. When n8n runs in Docker, localhost refers to the n8n container, not your host machine. Use a network-reachable hostname or the appropriate Docker host alias for your environment.

Volanea’s API is public HTTPS, so the normal https://api.volanea.com/v1/send endpoint does not need local networking workarounds. If that endpoint fails, inspect the request URL, outbound firewall rules, proxy configuration, and HTTP response details.

A production checklist for transactional email from n8n

Before publishing the workflow, review this checklist:

• The workflow uses an HTTP Request node, not a claimed native Volanea n8n app.
• The trigger data was inspected in an actual n8n execution.
• A normalized event node separates email values from the upstream payload shape.
• Recipient, event type, and business identifiers are validated before sending.
• The from address belongs to a verified Volanea sending domain.
• The Volanea key is stored in an n8n credential, never passed by the trigger.
• The request calls POST https://api.volanea.com/v1/send.
• The request includes HTML and plain-text content, or an approved reusable template.
• Every logical email has a stable Idempotency-Key.
• Test runs use a controlled inbox and, where appropriate, a test key.
• HTTP failures follow an intentional error path.
• Successful submissions are logged with a safe audit record.
• The production webhook URL is configured only after the workflow is published.

This architecture stays simple as your automation grows. An n8n workflow can begin with a single receipt email, then expand to account invites, password resets, renewal notices, internal alerts, and lifecycle messages without changing the underlying integration model: trigger an event, normalize it, validate it, send it with an idempotency key, and observe the result.

FAQ

Does Volanea have a native n8n Send Email integration?

No. There is no native Volanea app or dedicated Volanea action to install in n8n for this flow. Use n8n’s HTTP Request node to call Volanea’s REST API, or use SMTP credentials with n8n’s built-in Send Email node when SMTP is the better fit.

Does n8n Send Email send a webhook payload to Volanea?

No. The n8n Send Email node sends mail through an SMTP server. It does not generate a standard outbound webhook payload. In this guide, the webhook payload comes from the service that triggers your n8n workflow, and the HTTP Request node sends the resulting JSON to Volanea.

What endpoint sends one email through Volanea?

Use POST https://api.volanea.com/v1/send with an authenticated Authorization header, a JSON body containing sender, recipient, subject, and content, plus an Idempotency-Key header for safe retries.

Why should I use an idempotency key for n8n email sends?

Workflow triggers, HTTP calls, and upstream services can retry. A stable idempotency key identifies repeated attempts as the same logical email so a retry does not become a duplicate receipt, alert, invitation, or password-reset message.

Should I use HTML only for transactional email?

No. Include a well-written plain-text version alongside HTML whenever you send inline content. It improves readability in clients or security environments that do not render HTML as expected and provides a more resilient recipient experience.