How to Send Email From n8n With Volanea

If you need to send email from n8n, you do not need a native marketplace integration to build a dependable workflow. n8n can receive an event through its Webhook node, transform the incoming data, and make an authenticated outbound HTTP request to Volanea’s REST API.

This approach is useful when an event in your product, database, CRM, or form tool should trigger an email immediately. A new account can receive a welcome message, a newly paid invoice can send a receipt, or a support request can create an acknowledgement email without putting email-delivery logic directly inside the system that produced the event.

Volanea does not ship a native n8n app or marketplace plugin. The integration described here uses n8n’s built-in workflow primitives instead: a Webhook node to receive an event and an HTTP Request node to call the Volanea email API. That distinction matters because it gives you a portable integration that is easy to inspect, test, version, and adapt as your workflow grows.

What this n8n and Volanea integration does

At a high level, the workflow has one job: accept a trusted event, validate the information needed for an email, map the event into Volanea’s send-email payload, and make one server-to-server API call.

A practical workflow looks like this:

1. Your application creates or updates a record, such as a customer, order, ticket, or form submission.
2. Your application sends an HTTP POST request to an n8n Webhook node.
3. n8n receives the incoming payload as workflow data.
4. A Code node, Set node, or validation branch prepares the recipient, subject, text, and HTML content.
5. n8n’s HTTP Request node sends that prepared JSON to Volanea.
6. Volanea accepts the message for delivery and returns an API response that n8n can log, route, or use in later workflow steps.

The Webhook node is the concrete n8n trigger in this example. In n8n terms, a webhook-triggered workflow starts when the Webhook node receives an HTTP request at its production URL. Your application remains responsible for deciding what event should produce that request. For example, your backend may post to n8n after it creates a customer record, after a payment provider confirms an invoice, or after a user submits a form.

The advantage is separation of concerns. Your application emits a business event. n8n orchestrates the follow-up work. Volanea handles the email API and delivery infrastructure.

Why use n8n’s HTTP Request node instead of a native app

A dedicated app node can be convenient, but it is not required for an API integration. n8n’s HTTP Request node is designed for calling services with standard HTTP methods, JSON bodies, headers, and credential-based authentication. That makes it appropriate for REST APIs such as Volanea’s.

Using the HTTP Request node has several practical benefits:

• No dependency on a marketplace plugin: You can build the workflow even when a provider does not have a prebuilt n8n integration.
• Visible request mapping: The URL, request body, authentication method, and headers are all inspectable in the workflow.
• Flexible event sources: The workflow can begin with a Webhook node, a database trigger, a schedule, a CRM trigger, or another n8n trigger node.
• Controlled error handling: You can branch based on recipient validity, HTTP status codes, or API error responses before attempting another send.
• Portable patterns: The same basic workflow can support receipts, passwordless-login links, alerts, invitations, lifecycle messages, and internal operational notifications.

The tradeoff is that you must configure the request explicitly. That is generally an advantage for transactional email because you should know exactly which event creates a message, what data enters the message, and which credential authorizes the send.

For the current configuration options and request formats available in n8n, consult its HTTP Request and Webhook node documentation. For Volanea-specific endpoint details and API behavior, keep the email API reference and setup guides nearby while you build.

The event that starts the email send

The most reliable way to start this workflow is to have your application send a webhook event after a durable business action succeeds. In this guide, the event is a customer record being created.

That does not mean n8n itself is watching a database table. Instead, your application creates the record and then posts an event to the n8n Webhook node. This is often cleaner than making n8n poll for changes because the event can happen immediately and can include the exact data the email needs.

Example: customer-created event from your application

Imagine a product signup service that creates a customer record. After the database transaction succeeds, the backend posts this JSON to the n8n production webhook URL:

{
  "event": "customer.created",
  "event_id": "evt_01JQ7CZ6CXD6D48C3JTB44V2ZW",
  "occurred_at": "2026-09-22T14:18:44Z",
  "customer": {
    "id": "cus_8a52f6",
    "email": "ada@example.com",
    "first_name": "Ada",
    "plan": "starter"
  }
}

The backend call that sends that event might look like this:

await fetch(process.env.N8N_CUSTOMER_CREATED_WEBHOOK_URL, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-Workflow-Secret': process.env.N8N_WEBHOOK_SECRET
  },
  body: JSON.stringify({
    event: 'customer.created',
    event_id: event.id,
    occurred_at: new Date().toISOString(),
    customer: {
      id: customer.id,
      email: customer.email,
      first_name: customer.firstName,
      plan: customer.plan
    }
  })
});

The exact webhook URL comes from the Webhook node in n8n. While testing, n8n provides a test URL. Once the workflow is active, use its production URL in your application. Do not accidentally leave a production application pointed at a test webhook URL, because test executions are intended for manual workflow development rather than continuous production traffic.

How n8n represents the webhook data

When the Webhook node receives a JSON request, the incoming request body is typically available beneath the item’s body property. That means the customer email in the example is referenced in n8n expressions as:

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

The customer’s first name is:

{{$json.body.customer.first_name}}

And the event ID used for deduplication is:

{{$json.body.event_id}}

A representative n8n item after the Webhook node looks like this:

[
  {
    "json": {
      "headers": {
        "content-type": "application/json",
        "x-workflow-secret": "redacted"
      },
      "params": {},
      "query": {},
      "body": {
        "event": "customer.created",
        "event_id": "evt_01JQ7CZ6CXD6D48C3JTB44V2ZW",
        "occurred_at": "2026-09-22T14:18:44Z",
        "customer": {
          "id": "cus_8a52f6",
          "email": "ada@example.com",
          "first_name": "Ada",
          "plan": "starter"
        }
      }
    }
  }
]

Do not assume every incoming source has the same nesting. A form service might put fields under body.data; a custom application may send the customer object at the top level; a database node may produce email directly under $json.email. Inspect a real n8n execution before writing expressions so you map the actual incoming shape rather than an imagined one.

Build the workflow in n8n

Create a new workflow and add the following nodes in order:

1. Webhook — receives the customer.created event.
2. IF or Code — verifies that the event is expected and the email address exists.
3. Code or Set — builds a clean Volanea email payload.
4. HTTP Request — posts the payload to Volanea.
5. Respond to Webhook or a follow-up node — returns an appropriate response, logs the result, or routes errors.

Configure the Webhook node

Set the Webhook node to use:

• HTTP Method: POST
• Path: something private and purpose-specific, such as events/customer-created
• Response mode: choose a response strategy that matches your sender’s timeout expectations

A descriptive path is preferable to a generic path such as send-email. The triggering application is notifying your automation system about a business event; it is not directly exposing a public email-sending endpoint.

Use an authentication control for the webhook itself. Depending on your n8n deployment and requirements, that can include webhook authentication, a secret header checked in an IF node, a reverse-proxy control, or a signed event generated by your application. At minimum, reject requests whose shared secret does not match the expected server-side value.

Validate before you send

A workflow should not send simply because it received JSON. Check the event name and required fields first. At a minimum, verify:

• body.event equals customer.created
• body.event_id is present
• body.customer.email is present
• body.customer.email is plausibly an email address
• the recipient is eligible for the category of message you intend to send

For transactional messages, eligibility might mean the event is associated with an account action or purchase. For marketing messages, you need more careful consent and suppression logic. Do not reuse a transactional welcome-email workflow to send promotional content merely because both messages contain an email address.

A simple Code node can normalize and validate the data before the API request:

const body = $json.body;

if (body.event !== 'customer.created') {
  throw new Error(`Unexpected event: ${body.event}`);
}

const email = body.customer?.email?.trim().toLowerCase();
const firstName = body.customer?.first_name?.trim() || 'there';

if (!email || !email.includes('@')) {
  throw new Error('customer.email is missing or invalid');
}

if (!body.event_id) {
  throw new Error('event_id is required for deduplication');
}

return [
  {
    json: {
      eventId: body.event_id,
      recipient: email,
      firstName,
      plan: body.customer?.plan || 'your plan'
    }
  }
];

This Code node deliberately creates a smaller, predictable object. Downstream nodes no longer have to know the full webhook payload shape, and template logic becomes easier to review.

Map n8n data to the Volanea email payload

The most important part of the integration is field mapping. Your source event uses business fields such as customer.email and customer.first_name. Volanea needs email fields such as sender, recipient, subject, and content.

After the validation Code node above, configure an HTTP Request node to make a POST request to Volanea’s email-send endpoint. Use JSON as the body content type and map n8n values with expressions.

The request below shows the complete mapping as a cURL equivalent. It is useful both for testing outside n8n and for checking that the HTTP Request node is producing the payload you expect:

curl --request POST 'https://api.volanea.com/v1/emails' \
  --header 'Authorization: Bearer YOUR_VOLANEA_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "from": "Acme <notifications@mail.example.com>",
    "to": ["ada@example.com"],
    "subject": "Welcome to Acme, Ada",
    "html": "<h1>Welcome to Acme, Ada</h1><p>Your starter plan is ready.</p>",
    "text": "Welcome to Acme, Ada. Your starter plan is ready."
  }'

In n8n, the equivalent body can be assembled in a Code node so the HTTP Request node receives one finished JSON object:

const { recipient, firstName, plan, eventId } = $json;

return [
  {
    json: {
      eventId,
      from: 'Acme <notifications@mail.example.com>',
      to: [recipient],
      subject: `Welcome to Acme, ${firstName}`,
      html: `
        <h1>Welcome to Acme, ${firstName}</h1>
        <p>Your <strong>${plan}</strong> plan is ready.</p>
        <p>You can now sign in and start using Acme.</p>
      `,
      text: `Welcome to Acme, ${firstName}. Your ${plan} plan is ready. You can now sign in and start using Acme.`
    }
  }
];

Then set the HTTP Request node as follows:

Method: POST
URL: https://api.volanea.com/v1/emails
Authentication: Predefined Credential Type or Generic Credential Type
Credential: Volanea API key stored as a Bearer-token header
Send Headers: Content-Type = application/json
Send Body: JSON
Specify Body: Using JSON
JSON Body: {{$json}}

The mapping is intentionally straightforward:

The from address must be a sender address you are authorized to use in Volanea. Do not populate it from arbitrary webhook data. Letting an external request choose the sender can create spoofing risk, break your domain-alignment design, and make operational debugging much harder.

Keep both HTML and text content

Include both html and text versions of the message. HTML gives you layout and branded presentation. Plain text gives recipients a readable fallback and is helpful for clients, accessibility tools, or circumstances where rich content is unavailable.

Keep the text version meaningfully equivalent to the HTML version. Do not write a detailed HTML message and reduce the text alternative to a vague sentence. A customer who cannot view the HTML should still understand why they received the email and what action, if any, they should take.

Store the Volanea API key securely in n8n

The Volanea API key belongs in n8n credentials, not in the workflow body, a Code node, a browser application, a public repository, or client-visible environment configuration.

In the HTTP Request node, create a credential that sends the API key as a bearer token in the Authorization header. The final outbound request should have this server-side header:

Authorization: Bearer YOUR_VOLANEA_API_KEY

Do not put the secret directly in a header field inside the node if you can avoid it. Use n8n’s credential storage so the secret is managed separately from the workflow definition and is masked in normal workflow views. Limit access to people who need to edit or operate the workflow.

Why the key must never reach the browser

A Volanea API key authorizes email sends. If it is exposed in front-end JavaScript, a mobile application bundle, a public form, browser storage, or a publicly reachable configuration endpoint, anyone who retrieves it may be able to send email through your account.

That can lead to abuse, unexpected sending costs, sender reputation damage, and incident response work. It also makes attribution difficult because unauthorized sends can look like normal API traffic.

The correct trust boundary is:

Browser or external service
  → your backend or authenticated event source
  → n8n Webhook workflow
  → Volanea API

Only the server-controlled portions of that chain should have access to the Volanea credential. The browser should send a form submission or application action to your backend; it should never call the email provider directly with a long-lived sending key.

Separate credentials by environment

Use separate Volanea API keys and separate n8n credentials for development, staging, and production. A development workflow should not be able to accidentally send real customer messages from your production sender identity.

A sensible environment policy is:

• Development sends only to an internal test allowlist.
• Staging sends to test inboxes or controlled QA recipients.
• Production uses the production sender domain and only production event sources.
• Each environment has a different webhook URL, secret, and Volanea credential.

This separation makes failures easier to isolate. It also prevents an engineer testing a field mapping from accidentally emailing a real customer with an unfinished template.

Test the workflow before activating it

Before you activate the production workflow, use the Webhook node’s test URL and send a representative event. Test more than the ideal happy path.

Start with a valid customer-created event and confirm all of the following:

1. n8n receives the payload in the expected body structure.
2. The validation node produces the expected normalized values.
3. The HTTP Request node sends the correct JSON fields.
4. Volanea returns a successful response.
5. The message arrives at a controlled inbox with the correct sender, recipient, subject, HTML, and text content.
6. The event ID is visible in your logs or stored wherever you track send idempotency.

Then test failure conditions deliberately. Send an event with no email address, an event with a misspelled field, an incorrect webhook secret, and an event type that the workflow should not process. A reliable workflow should reject those inputs before reaching the Volanea API.

Do not rely solely on a successful API response. Email sending is asynchronous infrastructure: an API may accept a message while later delivery events, bounces, or recipient-side filtering require separate monitoring. The initial response tells you the request was accepted by the API; it is not a guarantee that every mailbox provider will place the message in the inbox.

When this breaks: retries, timeouts, and incomplete payloads

The most common problems in this integration happen at the boundary between the originating system, n8n, and the email API. Plan for them before volume makes them difficult to investigate.

Retries can create duplicate sends

A sender may retry a webhook request when it does not receive a response quickly enough. n8n can also retry a failed node execution depending on how you configure the workflow. If the first Volanea request succeeded but the response was lost, delayed, or treated as failed by an upstream component, a retry can send the same welcome email again.

That is why the example includes event_id. Treat it as an idempotency key for your workflow logic. Before the HTTP Request node sends the email, check whether that event ID has already been processed. Store processed IDs in a durable location appropriate for your stack, such as a database table, data store, or application endpoint.

A useful deduplication record contains:

• the source event_id
• the recipient address
• the workflow name or message type
• the time of the first send attempt
• the Volanea response identifier, when available
• the final processing outcome

The key should represent the business event, not only the recipient. A customer may legitimately receive two different transactional messages on the same day, but they should not receive the same customer.created message twice because one webhook request was retried.

Webhook timeouts can confuse the source system

A webhook sender typically expects an HTTP response within its own timeout window. If your n8n workflow waits for a slow downstream API call, runs extensive enrichment, or encounters a transient dependency problem, the source system may time out and retry.

For event ingestion, respond quickly when possible. One pattern is to validate that the incoming request is structurally acceptable, acknowledge it, and let the rest of the workflow continue asynchronously. Another is to make the source application use an outbox or queue pattern: it records the event durably and retries with the same event ID until it receives a clear acknowledgement.

Do not simply shorten timeouts and hope the issue disappears. A timeout is ambiguous: the source cannot know whether n8n never received the event, received it but did not process it, or sent the email successfully but failed to return a response. Idempotency is what makes that ambiguity safe.

Payload fields may be missing on some plans or paths

Real event payloads are rarely perfectly uniform. A paid plan may include customer.first_name, while an imported account or enterprise-created record may have no first name. A form might provide email, while a CRM event uses primary_email. A customer may have a blank plan during a trial conversion.

Do not let optional fields silently turn into broken content such as “Welcome to Acme, undefined.” Normalize values and provide safe defaults before generating the subject and body. The Code-node example uses there as a fallback first name and your plan as a fallback plan label.

For fields that are genuinely required, stop the workflow before sending. It is better to route an incomplete event to an error queue or operations channel than to email an address you did not intend to contact.

Bad recipient data creates delivery and support problems

A string containing @ is only a minimal sanity check, not comprehensive address verification. Your source of truth should validate email collection at the appropriate point in the customer journey, and your workflow should avoid attempting sends to blank, malformed, suppressed, or known-bounced addresses.

If you need to inspect an address before an important workflow, use an address-validation process rather than relying on template code alone. Even a technically valid address can be mistyped, abandoned, or unable to receive messages.

API failures need a clear policy

Separate failures into categories before you configure retries:

• Authentication and authorization failures: usually configuration problems; do not blindly retry.
• Validation failures: usually malformed request data or an unverified sender; fix the workflow or source record.
• Rate-limit responses: retry with controlled backoff where appropriate.
• Temporary server or network errors: retry carefully, using your event ID to avoid duplicate sends.
• Unexpected success-response parsing errors: log the raw response and investigate before rerunning executions.

A retry policy without idempotency turns transient trouble into duplicate email. An idempotent workflow lets you retry the processing of an event while protecting the recipient experience.

Operational practices for reliable transactional email

The workflow itself is only one part of reliable sending. The event source, sender domain, message content, and observability all affect the outcome.

Use a verified, purpose-specific sender

Choose a sender address that matches the type of email. For example, use notifications@ for account events, receipts@ for payment confirmations, or support@ for support interactions. Keep the display name recognizable and avoid changing it frequently.

A consistent sender helps recipients recognize legitimate messages and helps your team investigate complaints or delivery issues. It also avoids mixing transactional and promotional traffic under a vague or overloaded identity.

Log the business context, not secrets

Log enough data to trace an email back to the event that created it. Useful records include event ID, customer ID, recipient domain, message category, workflow execution ID, timestamps, and API response status.

Avoid logging the Volanea API key, webhook secrets, full sensitive form submissions, or unnecessary message content. If logs are widely accessible, personal data and authentication values become an operational risk.

Keep template logic restrained

n8n can build dynamic subjects and HTML strings, but it should not become an uncontrolled templating system. Keep templates readable, use defaults for optional personalization, and test messages with unusual names, Unicode characters, empty fields, and long values.

When messages become more complex, centralize templates in your application or a controlled template layer and have n8n pass approved variables. The workflow should orchestrate a known message type rather than generate arbitrary HTML from untrusted event fields.

Monitor outcomes beyond the API call

Monitor at least three stages:

1. Event received: Did n8n receive the source event?
2. Send accepted: Did Volanea accept the API request?
3. Message outcome: Did delivery, bounce, complaint, or suppression signals indicate a downstream problem?

These are different questions. A gap between event received and send accepted points to workflow or API trouble. A gap between send accepted and delivery points to recipient data, sender reputation, mailbox-provider behavior, or message-level issues.

Alternatives when a webhook is not your event source

The Webhook node is a good default when your application can make outbound HTTP calls. But n8n workflows can begin from other triggers when that better matches your system.

For example, you might use:

• A database trigger or polling workflow when a record changes in a system n8n can access.
• A form trigger when a connected form product creates a response.
• A CRM trigger when a deal stage changes.
• A schedule trigger for daily operational summaries or renewal reminders.
• A queue or message-bus integration when your architecture already publishes events asynchronously.

The Volanea portion remains the same: validate the item, build the email payload, and call the HTTP Request node with the API credential. What changes is the incoming data shape and the conditions that determine whether an email should be sent.

If your source cannot issue webhooks and cannot be reached directly by n8n, middleware may be appropriate. Zapier or Make can receive an event from a supported source and call an n8n webhook, or they can make an HTTP request themselves. However, adding middleware adds another credential boundary, another retry system, and another place where duplicate sends can originate. Prefer the shortest dependable path that your source system supports.

A production checklist

Before relying on this workflow for customer email, review this checklist:

• The workflow starts with a real n8n trigger node, such as Webhook, not a manually run test node.
• The production webhook URL is configured in the source application.
• A secret, signature, or other authentication control protects the webhook endpoint.
• The workflow validates the event type and required fields.
• Optional fields have intentional fallback values.
• The Volanea API key is stored in n8n credentials, not in code or client-side configuration.
• The sender address is authorized and appropriate for the message category.
• Both HTML and plain-text content are included.
• A durable event ID is used to prevent duplicate sends.
• Retry behavior is defined separately for validation, authentication, rate-limit, and transient failures.
• Logs contain useful event and execution identifiers but no secrets.
• Development, staging, and production use separate keys and endpoints where applicable.
• The workflow has been tested with valid, missing, repeated, and malformed events.

This setup is deliberately simple, but it supports a mature operational model. Start with one reliable transactional use case, prove the data mapping and duplicate protection, then reuse the pattern for other event-driven emails.

Conclusion

To send email from n8n with Volanea, use n8n’s Webhook node to receive a trusted business event and its HTTP Request node to make an authenticated REST API call. You do not need a native n8n plugin to build the integration, and you should not pretend that one exists.

The durable version of this workflow is more than a single POST request. It validates incoming data, keeps the Volanea API key server-side in n8n credentials, maps explicit fields into a consistent email payload, responds thoughtfully to timeouts, and prevents retry-driven duplicate sends with an event ID. Those controls turn a basic automation into dependable transactional-email infrastructure.

FAQ

Does Volanea have a native n8n integration?

No. This integration uses n8n’s built-in Webhook and HTTP Request nodes rather than a native Volanea app, marketplace listing, or plugin.

What n8n trigger should I use to send a transactional email?

Use the trigger that best represents the completed business event. For a custom application, the Webhook node is often the clearest option: your backend posts an event such as customer.created after the record is successfully created.

Where should I store my Volanea API key in n8n?

Store it in an n8n credential used by the HTTP Request node, configured as a server-side bearer-token header. Never expose a sending API key in browser JavaScript, a mobile app, a public form, or a client-visible configuration file.

How do I stop retries from sending duplicate emails?

Include a durable source event ID in every webhook request and store a record when that event has already been processed. Check that record before sending, so retried requests do not create a second message for the same business event.

Can I use this pattern for marketing email?

Technically, the HTTP integration can send many types of messages, but marketing workflows require consent, suppression, unsubscribe handling, segmentation, and stricter audience controls. Keep transactional and marketing logic separate so an operational event does not become an unauthorized campaign send.