How to Send Email from MailPoet with Volanea

MailPoet does not offer a native Volanea app or a documented outgoing-webhook action, but you can still send email from MailPoet with Volanea reliably. The practical integration is a MailPoet Automation Custom Action that fires a WordPress hook, plus a small server-side plugin that maps the subscriber to Volanea’s REST email API.

The integration model: MailPoet hook to Volanea REST API

It is important to start with the constraint rather than hide it behind an imaginary marketplace flow: MailPoet’s documented Automation actions include actions such as Send email, Delay, and If/Else. Its premium Custom action fires a WordPress hook you name, but it is not an outbound HTTP webhook action with a URL field, request-header editor, or JSON-body template.

That means MailPoet does not itself POST a subscriber object to Volanea. Instead, it calls a WordPress action hook on the same server where your WordPress site runs. Your integration plugin listens for that hook, retrieves the subscriber record through MailPoet’s PHP API, builds an email request, and posts it to Volanea at POST /v1/send.

This is a useful distinction for both security and reliability:

• MailPoet Automation decides when an event should lead to an email.
• Your WordPress plugin holds the secret Volanea key and applies your message logic.
• Volanea accepts the transactional send, checks suppression and contact status, renders and queues the message, and supplies the delivery-side visibility.
• An idempotency key makes an uncertain retry less likely to create a duplicate send.

For a welcome message, the concrete MailPoet trigger is Someone Subscribes. When double opt-in is enabled, MailPoet documents that a person enters this automation after they confirm and their subscriber status changes from unconfirmed to subscribed. That is generally the correct moment to send an onboarding or account-next-steps message rather than emailing an address that has not yet confirmed consent.

This setup needs MailPoet’s Automation functionality and its premium Custom Action feature. If your plan does not include Custom Actions, do not pretend that a webhook is available in the default automation builder. Use a WordPress integration plugin that watches an available WordPress/MailPoet event, or choose a WordPress automation connector that can receive the MailPoet event and make an authenticated HTTP request on the server side.

What actually triggers the Volanea email

The recommended trigger is a MailPoet Automation with these two steps:

1. Trigger: Someone Subscribes
2. Action: Custom action

In the trigger settings, select the MailPoet list or lists that represent a real signup journey. For example, you might choose a list named Product updates or Free course signup. Avoid using a broad all-subscribers list unless every person joining it should receive this exact message.

In the Custom Action configuration, set the hook name to:

volanea_mailpoet_welcome

MailPoet’s documented Custom Action behavior is to fire the WordPress hook you specify. Its example callback receives the subscriber email address as the hook argument. That scalar email address is the real payload crossing the MailPoet-to-plugin boundary in this approach.

In other words, the first hop does not resemble an external webhook such as this:

{
  "event": "subscriber.created",
  "data": {
    "email": "ada@example.com"
  }
}

MailPoet does not document that outbound JSON contract for Custom Actions. The reliable, documented contract for the Custom Action listener is the subscriber email argument:

add_action('volanea_mailpoet_welcome', function ($subscriber_email) {
  // $subscriber_email is the value MailPoet supplies to the Custom Action hook.
}, 10, 1);

That small detail affects the whole implementation. Since the hook gives you an email address rather than a complete JSON record, the server-side plugin should look up the subscriber before composing the message. MailPoet’s subscriber API returns fields including email, first_name, last_name, status, created_at, confirmed_at, and last_subscribed_at.

The lookup also makes it possible to implement sensible safeguards. You can refuse to send if the subscriber no longer has status subscribed, if the email argument is malformed, or if a configuration error means the sender domain has not been set.

Before you build: choose the message boundary

A MailPoet-to-Volanea integration can be used for more than welcome emails, but the event and email type should match.

Good fits for this route

Use a Custom Action plus Volanea for messages where a subscriber event needs an immediate operational response, such as:

• a confirmed subscription welcome with account setup instructions;
• a lead magnet delivery email after opt-in;
• a notification that a subscriber entered a high-intent list;
• a request to complete a profile or choose preferences;
• a message after a MailPoet automation branch establishes eligibility.

For example, an automation may begin with Someone Subscribes, wait for an appropriate amount of time, use If/Else conditions to distinguish subscribers, and then fire the volanea_mailpoet_welcome Custom Action only for the branch that should get the message.

Cases where MailPoet’s own Send Email action is simpler

If the message is a normal newsletter, a promotional nurture message, or content that belongs entirely in MailPoet’s editor and reporting, its built-in Send email action is often the more direct choice. You avoid operating a custom plugin and avoid maintaining a second template path.

The Volanea route is most valuable when your development team needs a programmatic transactional send with a server-side API contract, explicit error handling, or a template and event lifecycle maintained outside MailPoet.

Do not use a list join as a universal event bus

A list subscription is a consent and audience-management event. It is not necessarily equivalent to a paid order, completed account verification, accepted quote, or support escalation. If a WooCommerce order status or WordPress user registration is the real business event, model that event directly in the application or select the specific MailPoet Automation trigger that represents it.

Using the wrong trigger creates downstream problems: people receive emails at surprising times, repeated list moves create duplicate sends, and troubleshooting becomes harder because the event name no longer describes the actual user action.

Store the Volanea API key only on the server

The Volanea API key belongs in server-only WordPress configuration. It must not appear in a MailPoet email block, custom JavaScript, a page source, a form hidden field, browser-side configuration object, or a public webhook URL.

A browser-visible key can be copied by any visitor. An attacker could use it to send mail from your authenticated sending identity, consume your account quota, pollute delivery metrics, or damage domain reputation. Treat it as a production credential, not as a tracking identifier.

A straightforward WordPress configuration approach is to place the secret in wp-config.php, outside your active theme and outside a repository:

define('VOLANEA_API_KEY', 'sk_live_replace_with_your_secret_key');
define('VOLANEA_FROM_EMAIL', 'hello@example.com');
define('VOLANEA_FROM_NAME', 'Example Co');

Use a deployment secret manager or environment variables if your host supports them. The goal is the same: WordPress PHP can read the key at runtime, but visitors and front-end JavaScript cannot.

Do not place the key in an Automation Custom Action field. MailPoet’s Custom Action is where you name the internal WordPress hook; it is not a secret-management layer. Do not hard-code a production key into a plugin that you commit to Git, either.

Before turning on the automation, verify the sending domain in Volanea. The from email address in the API request should use that verified domain. If your sender identity is unverified, the send can be rejected before it ever reaches a recipient mailbox.

For a fuller review of authentication, sender setup, and request formats, consult the Volanea API reference and setup guides while configuring your environment.

Working WordPress plugin: subscriber mapping and REST send

Create a small must-use plugin or a normal WordPress plugin owned by your team. A must-use plugin is often a good fit for operational email logic because it does not depend on a theme and is loaded automatically by WordPress.

Create this file:

wp-content/mu-plugins/mailpoet-volanea.php

Then add the following code. It listens for the exact Custom Action hook named earlier, receives the MailPoet subscriber email, loads the subscriber record from MailPoet, maps the fields to the Volanea request, and calls Volanea’s POST /v1/send endpoint.

<?php
/**
 * Plugin Name: MailPoet to Volanea welcome email
 * Description: Sends a Volanea transactional welcome email when MailPoet fires a Custom Action.
 */

if (!defined('ABSPATH')) {
  exit;
}

add_action('volanea_mailpoet_welcome', 'example_send_mailpoet_welcome_with_volanea', 10, 1);

function example_send_mailpoet_welcome_with_volanea($subscriber_email) {
  // The Custom Action supplies the subscriber email as its hook argument.
  $email = sanitize_email($subscriber_email);

  if (!is_email($email)) {
    error_log('MailPoet → Volanea: invalid subscriber email received.');
    return;
  }

  if (!defined('VOLANEA_API_KEY') || !VOLANEA_API_KEY) {
    error_log('MailPoet → Volanea: VOLANEA_API_KEY is not configured.');
    return;
  }

  if (!defined('VOLANEA_FROM_EMAIL') || !is_email(VOLANEA_FROM_EMAIL)) {
    error_log('MailPoet → Volanea: VOLANEA_FROM_EMAIL is not configured.');
    return;
  }

  try {
    // MailPoet subscriber shape includes email, first_name, last_name, status,
    // created_at, confirmed_at, and last_subscribed_at.
    $subscriber = \MailPoet\API\API::MP('v1')->getSubscriber($email);
  } catch (\Exception $exception) {
    error_log('MailPoet → Volanea: subscriber lookup failed for ' . $email);
    return;
  }

  // The automation may be delayed or a subscriber may have unsubscribed since entry.
  if (($subscriber['status'] ?? '') !== 'subscribed') {
    error_log('MailPoet → Volanea: skipped non-subscribed address ' . $email);
    return;
  }

  $first_name = trim((string) ($subscriber['first_name'] ?? ''));
  $last_name  = trim((string) ($subscriber['last_name'] ?? ''));
  $name       = trim($first_name . ' ' . $last_name);
  $greeting   = $first_name !== '' ? $first_name : 'there';

  // A stable key identifies one logical welcome operation. Reuse this exact key
  // only if retrying this exact request with the same payload.
  $subscription_marker = (string) (
    $subscriber['last_subscribed_at']
    ?? $subscriber['confirmed_at']
    ?? $subscriber['created_at']
    ?? ''
  );

  $idempotency_key = 'mailpoet-welcome-' . hash(
    'sha256',
    strtolower($email) . '|' . $subscription_marker
  );

  // Field mapping:
  // MailPoet $subscriber['email']      -> Volanea to[0].email
  // MailPoet first_name + last_name     -> Volanea to[0].name
  // WordPress server configuration      -> Volanea from.email and from.name
  // Message content generated here      -> Volanea subject, html, and text
  $payload = [
    'from' => [
      'email' => VOLANEA_FROM_EMAIL,
      'name'  => defined('VOLANEA_FROM_NAME') ? VOLANEA_FROM_NAME : '',
    ],
    'to' => [[
      'email' => $email,
      'name'  => $name,
    ]],
    'subject' => 'Welcome to Example Co',
    'html' => '<p>Hi ' . esc_html($greeting) . ',</p>'
      . '<p>Thanks for confirming your subscription. Here is how to get started.</p>',
    'text' => "Hi {$greeting},\n\n"
      . "Thanks for confirming your subscription. Here is how to get started.",
  ];

  $response = wp_remote_post('https://api.volanea.com/v1/send', [
    'timeout' => 15,
    'headers' => [
      'Authorization'    => 'Bearer ' . VOLANEA_API_KEY,
      'Content-Type'     => 'application/json',
      'Idempotency-Key'  => $idempotency_key,
    ],
    'body' => wp_json_encode($payload),
  ]);

  if (is_wp_error($response)) {
    error_log('MailPoet → Volanea network error: ' . $response->get_error_message());
    return;
  }

  $status_code = wp_remote_retrieve_response_code($response);
  $body = wp_remote_retrieve_body($response);

  if ($status_code < 200 || $status_code >= 300) {
    error_log(
      'MailPoet → Volanea API error (' . $status_code . '): ' . $body
    );
    return;
  }

  error_log('MailPoet → Volanea accepted welcome email for ' . $email);
}

The code intentionally does not make an HTTP request from the browser. It runs after MailPoet fires a WordPress hook and uses WordPress’s server-side HTTP client, wp_remote_post().

It also uses the subscriber lookup rather than treating the hook value as a complete person record. This matters because MailPoet’s Custom Action callback provides the email identifier, while names and subscription status live on the MailPoet subscriber record.

Understand the field mapping before customizing the email

The mapping in the plugin is small, but each field has a deliberate source.

The plain-text version is not optional filler. Including text gives recipients and mail clients a readable fallback, improves accessibility, and makes the message easier to inspect in logs and tests.

Do not directly concatenate untrusted profile fields into HTML. The example uses esc_html() for the greeting. If you add custom MailPoet fields, sanitize and escape them for the context where they are used. An address field, free-form comment, or imported profile value should not be trusted as HTML merely because it exists in your WordPress database.

For more advanced messages, replace inline html and text with a Volanea template workflow if that better fits your team. Keep the same rule: send only variables you expect, validate their type and shape, and preserve the same idempotency key when retrying the same logical send.

Configure the MailPoet Automation safely

Once the server plugin is active and the secret configuration exists, create the automation in MailPoet.

Suggested welcome automation

1. Go to the MailPoet Automations area in the WordPress administration interface.
2. Create a new automation.
3. Select Someone Subscribes as the trigger.
4. Select the intended list or lists in the trigger settings.
5. Add optional conditions or delays only when they reflect a real messaging requirement.
6. Add the premium Custom action action.
7. Enter volanea_mailpoet_welcome as the hook name.
8. Activate the automation.
9. Subscribe a test address through the same form and confirmation process used by real visitors.
10. Check WordPress logs and Volanea send activity before enabling the flow for a large audience.

A useful testing sequence begins with a disposable mailbox, then a mailbox hosted by a major provider, then a production-like sender domain. A message accepted by an HTTP endpoint is not necessarily proof of inbox placement; it means the API accepted the request for processing. Review the later delivery outcome, bounce status, suppression result, and message activity rather than relying only on an initial success response.

If your form uses double opt-in, perform the confirmation step. The trigger behavior differs from a raw form submit: the automation begins once MailPoet considers the subscriber subscribed, not merely when an email address was typed into a form.

Keep one system responsible for one message

Do not leave a MailPoet Send email action in the same automation branch when the Custom Action is sending the same welcome email through Volanea. That is the fastest way to send two welcome messages.

Give the workflow a precise name, such as Confirmed newsletter signup → Volanea welcome. Add a comment in your plugin naming the related automation. These simple operational labels save time when someone revisits the integration months later.

When this breaks: diagnose this specific hop

Every integration has failure modes. Here, the important hop is not an opaque SaaS-to-SaaS webhook; it is MailPoet Automation firing a WordPress hook, followed by a WordPress server calling Volanea over HTTPS.

MailPoet retries or repeated automation runs cause duplicate sends

A send can duplicate if the automation runs more than once for the same person or if the WordPress process repeats a call after an uncertain result. For example, the outbound HTTPS request may reach Volanea but the WordPress server may time out before receiving the response. A naive retry with a new identifier can create a second email.

The plugin calculates a stable Idempotency-Key from the normalized address and subscription timestamp. If the same logical welcome send is retried, retain the same payload and same key. Do not generate a fresh random key inside every retry attempt, because that tells the API each retry is a new message.

Also examine why the automation fired twice. Common causes include a subscriber being moved through lists, a duplicated automation, manually restarted automation runs, and separate processes adding the same person to an eligible list. The correct fix may be in the automation design rather than in the HTTP client.

The WordPress request times out

The code uses a 15-second timeout to avoid holding PHP workers indefinitely. A timeout is ambiguous: it can mean the request never left WordPress, the network failed, Volanea did not respond in time, or Volanea processed the request but the response was lost.

Do not automatically retry every failure in a browser request. Put retries in a controlled server-side job or queue, record the idempotency key and payload, and retry only transient failures such as network errors or selected server errors. Authentication errors, malformed payloads, and an unverified sender are configuration problems, not retry candidates.

If your WordPress host blocks outbound HTTPS requests, the error will appear before Volanea has any record of the message. Check the WordPress error log, host egress policy, DNS resolution, and PHP HTTP transport configuration.

A payload field is missing or blank

The MailPoet Custom Action gives your callback the subscriber email, not every profile field. first_name and last_name can be empty because a form did not request them, an imported subscriber did not contain them, or the subscriber was created by another plugin.

Design message content to work with missing optional values. The example falls back to “there” instead of rendering an awkward blank salutation. If a field is mandatory for your business process, validate it before sending and route the person to a data-completion workflow instead of sending an incomplete transactional message.

Plan availability also matters. The Custom Action is documented as a premium feature. If it is unavailable in the installed MailPoet edition, the hook will never fire because the Automation cannot be configured. In that case, use a WordPress-side integration based on an event available in your environment; do not assume the standard plan has an outbound webhook setting.

The subscriber status changed before a delayed action runs

Automations can contain delays. During that delay, a recipient may unsubscribe, bounce, or otherwise become ineligible. The plugin checks that the subscriber’s current MailPoet status is subscribed before calling Volanea.

This status check is particularly useful for consent-sensitive messages. It is not a substitute for understanding the message category, but it reduces the risk of sending an email to a person whose MailPoet record no longer says they are subscribed.

Volanea accepts the request but no email arrives

An accepted REST request is not an inbox-delivery guarantee. The recipient may be suppressed, unsubscribed, blocked by a receiving mailbox provider, or subject to ordinary email filtering. Start diagnosis in this order:

1. Confirm the WordPress log records a 2xx Volanea response.
2. Inspect the Volanea message activity and recipient outcome.
3. Confirm the sending domain and From address are verified and aligned.
4. Check whether the recipient is suppressed or unsubscribed.
5. Review bounce and complaint events before trying repeated sends.
6. Test a separate known-good recipient mailbox.

Avoid repeatedly sending to an address that has hard-bounced or is suppressed. Repeated attempts do not solve a nonexistent mailbox and can harm deliverability decisions.

Operational improvements for production sites

The example plugin is intentionally small, but production sites should add observability and ownership.

Log correlation values, not secrets

Log the subscriber email only if that is acceptable for your privacy and retention policies. Better yet, log a one-way hash or a WordPress subscriber ID where possible. Record the hook name, idempotency key, HTTP status code, Volanea message identifier if returned, and a concise error category.

Never log the Authorization header or Volanea API key. Redact secrets in error collectors and ensure debug logs are not publicly downloadable.

Use a queue when sends are business-critical

A WordPress request that runs immediately after an automation hook is convenient, but it shares the lifecycle of the PHP process that invoked it. High-volume sites and critical messages benefit from a queue:

• Persist the intended send and idempotency key first.
• Process the send in a scheduled background task.
• Mark the job accepted only after a successful API response.
• Retry temporary failures with the same request identity.
• Alert when a job exhausts retries or receives a non-retryable response.

This makes message handling more resilient to short host outages and avoids slowing down a request that is adding or updating a subscriber.

Keep templates and business rules versioned

Whether you use inline HTML or an API template, version your email content. A welcome sequence often changes because of product changes, legal copy updates, or brand revisions. Source-controlled PHP templates or named Volanea templates make it possible to understand which content a recipient received.

If you introduce template variables, define a small contract. For example, firstName, signupSource, and gettingStartedUrl are understandable. Passing the entire MailPoet subscriber object as an unbounded data blob is less safe and harder to test.

Validate before growing the list

Before launching paid acquisition or importing a large source of subscribers, test the form, confirmation, automation entry, Custom Action, WordPress lookup, API send, and delivery outcome as one path. If you are importing addresses or accepting addresses from multiple forms, use an email address verification tool before high-volume campaigns to identify malformed or risky inputs early.

Alternatives when Custom Action is not available

There is no need to force the wrong architecture when your MailPoet plan or site constraints differ.

Use WordPress-level delivery for ordinary site email

If the goal is to deliver emails WordPress sends through wp_mail()—such as password resets, WooCommerce receipts, form notifications, and other system mail—the Volanea Email Delivery WordPress plugin is a separate route. It hands eligible WordPress mail to Volanea’s HTTP API rather than requiring SMTP configuration.

That route is different from the Custom Action integration in this guide. It changes the delivery transport for WordPress-generated mail; it does not turn a MailPoet Automation into an outbound webhook and it does not provide Custom Action-specific data mapping.

Use a WordPress automation connector as middleware

If you cannot use MailPoet Custom Actions but have a WordPress connector that exposes MailPoet subscriber events and can make outgoing HTTP requests, the connector can be the middleware. Keep the Volanea key in the connector’s server-side credential store, map only necessary subscriber fields, and set a stable idempotency key if the connector supports custom request headers.

Do not paste the Volanea secret into a client-side form integration. The fact that a connector has a visual workflow builder does not change the rule that credentials must remain on the server.

Call Volanea from the original business event

For account signups, purchases, password resets, and authorization notices, the cleanest architecture may be to call Volanea from the application or WooCommerce event that created the business event. MailPoet can still manage subscriber lists and marketing automation, while the application owns transactional delivery.

This approach avoids deriving an operational event from a marketing-list action. It also gives the code access to authoritative order IDs, account IDs, inventory data, and event timestamps for idempotency and audit trails.

Conclusion

To send email from MailPoet with Volanea, use MailPoet’s Someone Subscribes Automation trigger and a premium Custom action that fires a named WordPress hook. A small server-side plugin receives MailPoet’s real hook argument—the subscriber email—loads the full subscriber record through MailPoet’s API, maps it to Volanea’s POST /v1/send request, and authenticates using a secret key stored outside client-visible configuration.

The integration is intentionally not a fictional one-click app or outbound webhook setup. Its strength is that the sensitive work happens on your WordPress server: you can validate subscription status, handle missing fields, create idempotency keys, log failures safely, and decide when a retry is appropriate.

Start with one narrow message, test the confirmed-subscription path end to end, and add queueing and monitoring before the workflow becomes business-critical.

FAQ

Does MailPoet have a native Volanea integration?

No native MailPoet app, marketplace listing, or documented one-click Volanea connection is used in this setup. The integration uses MailPoet’s premium Custom Action to fire a WordPress hook and a custom server-side plugin to call Volanea’s REST API.

What MailPoet event starts the email send?

This guide uses the Someone Subscribes Automation trigger. When sign-up confirmation is enabled, MailPoet documents that the automation begins after the person confirms and becomes subscribed.

Does MailPoet send a JSON webhook payload to Volanea?

No. MailPoet’s Custom Action fires an internal WordPress hook. The documented callback pattern receives the subscriber email address, so the plugin looks up the MailPoet subscriber record and creates the Volanea JSON request itself.

Where should the Volanea API key be stored?

Store it in server-only WordPress configuration, such as wp-config.php, an environment variable, or a managed secret store. Never put it in browser JavaScript, MailPoet email content, form markup, or a public webhook URL.

How do I prevent duplicate welcome emails?

Use a stable idempotency key for one logical send and reuse that same key only when retrying the same request. Also inspect the MailPoet Automation design so the subscriber cannot enter duplicate branches or trigger the same Custom Action unexpectedly.