How to Send Email From WPForms With Volanea

If you need to send email from WPForms through an email API, the cleanest route is WPForms Webhooks plus Volanea’s REST API. A completed form submission can create a server-to-server POST request that maps the form’s fields into a transactional email request.

This approach is useful when WordPress’s default mail delivery is not reliable enough for important enquiries, quote requests, support forms, registration notices, or lead alerts. It also keeps the message delivery layer separate from the form builder: WPForms collects and validates the submission, while Volanea handles the outbound email.

What this integration does—and does not do

WPForms does not need a native Volanea marketplace app for this workflow. Its Webhooks addon can send data from a form submission to an external HTTP endpoint, including an email API endpoint. In this integration, the trigger is a form submission: after a visitor successfully submits the form, WPForms makes an outbound request from your WordPress server.

The resulting flow is straightforward:

1. A visitor completes and submits a WPForms form.
2. WPForms validates the form and completes its normal submission processing.
3. The form’s Webhooks configuration builds an HTTP POST body from selected form fields.
4. Your WordPress server sends that POST request to Volanea.
5. Volanea authenticates the request and queues the transactional email for delivery.

This is not the same as replacing every notification in WPForms. WPForms can still send its own built-in admin notification and confirmation email if you leave those enabled. Before going live, decide whether you want one delivery path or two. Leaving both active is a common source of duplicate staff notifications.

The direct webhook route requires the WPForms Webhooks addon, which WPForms makes available on plans that include that addon. If your plan does not include Webhooks, skip to the server-side hook approach below rather than assuming a standard form notification can call an arbitrary API.

Requirements before you configure the form

Set up the sending identity and recipient policy before connecting the form. A webhook test can appear successful while the resulting message is rejected, suppressed, or routed somewhere unexpected if the sending domain is not ready.

You need the following items:

• A WordPress site with WPForms installed and a form ready to submit.
• A WPForms license that includes the Webhooks addon for the direct no-code configuration.
• A Volanea API key with permission to send email.
• A verified sender address or domain in Volanea, such as forms@example.com.
• An internal destination address, such as sales@example.com or support@example.com.
• Field IDs for the WPForms fields you will use in the message.
• Access to WordPress administration to edit the form’s Settings area.

For production forms, use an address on a domain you control in the from field. Do not put the visitor’s submitted address in from. A contact form visitor might enter Gmail, Outlook, a typo, or an address belonging to somebody else; sending as that address damages alignment and can cause a provider to reject the message. Put the visitor address in reply_to instead.

A dependable pattern is:

Use a dedicated sender such as forms@ rather than a personal mailbox. It makes operational ownership clear and gives you a clean place to receive replies if a reply-to address is unavailable or malformed.

The WPForms trigger: a completed form submission

The concrete WPForms event in this setup is a form submission. The Webhooks addon attaches its request to the form and sends the configured request when that form is submitted successfully.

That distinction matters. Viewing a form, changing a field, starting a multi-page form, or saving a browser draft is not an email trigger. The request happens only after the submission reaches WordPress and passes WPForms processing. Consequently, a visitor’s browser does not call Volanea directly, and the Volanea secret should never be embedded in page JavaScript, hidden fields, or a front-end application configuration object.

Find the form field IDs

Open the form in the WPForms builder. Select a field and inspect its Field Options panel to identify its field ID. In WPForms Smart Tags, a field value is referenced with syntax such as:

{field_id="1"}

For the examples in this guide, assume this contact form has the following IDs:

Your IDs will differ. Do not copy these numbers blindly: an incorrect ID can produce an empty recipient, an empty reply-to address, or a subject that does not identify the lead.

Add Webhooks to the form

Install and activate the WPForms Webhooks addon from the WPForms Addons screen if it is included with your license. Then open the target form and navigate to Settings » Webhooks. Enable webhooks for the form and add a new webhook connection.

Configure the connection as an HTTP POST request with the request format set to JSON. Use the Volanea email-send endpoint specified by the current email API reference and setup guides. The exact endpoint version is part of the API contract, so use the endpoint shown in your Volanea dashboard and documentation rather than a URL copied from an old integration.

WPForms lets you set request headers and a request body for the webhook. That is the critical configuration: the request body is not a magical automatic dump of every field. You choose the body keys and map each value with Smart Tags.

Map a WPForms submission to a Volanea email request

A webhook does not have one universal payload shape independent of configuration. With WPForms Webhooks, you define the payload shape through the request-body fields and Smart Tags. That is a feature: send only the values the receiving service needs, rather than forwarding every field, consent checkbox, or internal field by default.

For a simple contact-form alert, configure a JSON request body equivalent to the following. The Smart Tags are resolved by WPForms on the server when a visitor submits the form.

{
  "from": "Website Forms <forms@example.com>",
  "to": "sales@example.com",
  "reply_to": "{field_id=\"2\"}",
  "subject": "New website enquiry from {field_id=\"1\"}",
  "html": "<h2>New website enquiry</h2><p><strong>Name:</strong> {field_id=\"1\"}</p><p><strong>Email:</strong> {field_id=\"2\"}</p><p><strong>Company:</strong> {field_id=\"3\"}</p><p><strong>Message:</strong><br>{field_id=\"4\"}</p>"
}

The equivalent resolved payload for the sample submission looks like this before Volanea receives it:

{
  "from": "Website Forms <forms@example.com>",
  "to": "sales@example.com",
  "reply_to": "avery@example.net",
  "subject": "New website enquiry from Avery Chen",
  "html": "<h2>New website enquiry</h2><p><strong>Name:</strong> Avery Chen</p><p><strong>Email:</strong> avery@example.net</p><p><strong>Company:</strong> Northstar Studio</p><p><strong>Message:</strong><br>Could we discuss enterprise pricing?</p>"
}

In the WPForms request-header area, add the authentication and content headers required by Volanea. A conventional bearer-token request is:

Authorization: Bearer YOUR_VOLANEA_API_KEY
Content-Type: application/json

The resulting server-to-server request is conceptually the following. Replace the endpoint path with the current Volanea REST email endpoint shown in the API reference, and keep the message schema aligned with the endpoint’s documented fields.

curl --request POST "https://api.volanea.com/v1/emails" \
  --header "Authorization: Bearer $VOLANEA_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "from": "Website Forms <forms@example.com>",
    "to": "sales@example.com",
    "reply_to": "avery@example.net",
    "subject": "New website enquiry from Avery Chen",
    "html": "<h2>New website enquiry</h2><p><strong>Name:</strong> Avery Chen</p><p><strong>Email:</strong> avery@example.net</p><p><strong>Company:</strong> Northstar Studio</p><p><strong>Message:</strong><br>Could we discuss enterprise pricing?</p>"
  }'

Field mapping is the key part of the design. The recipient is deliberately static, while the submitter’s address is dynamic and appears only in reply_to. That prevents a user from changing the actual delivery destination by entering an address in a public form field.

Keep HTML input safe and readable

A form message is untrusted visitor input. Do not let a message field determine your full HTML document, headers, recipient list, or sender identity. Keep the surrounding markup static and insert only the values you need.

For a higher-risk form, such as one that accepts rich-text content or file-upload metadata, use the server-side option described later. It gives you a place to escape output, validate email addresses, trim oversized values, and generate a text alternative before calling the API.

Protect the Volanea API key

The Volanea API key belongs in the webhook’s server-side request headers, not in anything the visitor can inspect. When WPForms submits a form, WordPress makes the outbound HTTP call. The site visitor sees the form submission request to your website, but should not see your separate API request from WordPress to Volanea.

Never place the key in any of these locations:

• A hidden WPForms field.
• An HTML data- attribute.
• Browser-side JavaScript or a public React/Vue environment variable.
• The form confirmation message.
• A URL query string.
• A screenshot, support ticket, or source repository.

A key stored in WPForms webhook settings is still a secret with operational implications. WordPress administrators, database backups, migration exports, and compromised plugins can potentially expose configuration stored in the WordPress environment. Use a dedicated restricted key where possible, rotate it after a suspected disclosure, and limit access to WordPress administrators who need to change the integration.

A more secure production pattern

The direct Webhooks configuration is practical, but a server-side WordPress hook is usually more maintainable for sensitive or complex forms. Store the API key outside the form configuration, ideally in a server environment variable or a secret manager surfaced to PHP. Then call Volanea after WPForms completes processing.

WPForms provides the wpforms_process_complete action for code that should run after a form submission has been processed. The following plugin-style example handles only form ID 123, validates the email field, creates a constrained email payload, and calls Volanea through WordPress’s HTTP API.

<?php
/**
 * Plugin Name: WPForms Volanea Contact Alerts
 */

add_action( 'wpforms_process_complete', function( $fields, $entry, $form_data, $entry_id ) {
    // Run only for the intended WPForms form.
    if ( (int) $form_data['id'] !== 123 ) {
        return;
    }

    $name    = isset( $fields[1]['value'] ) ? sanitize_text_field( $fields[1]['value'] ) : '';
    $email   = isset( $fields[2]['value'] ) ? sanitize_email( $fields[2]['value'] ) : '';
    $company = isset( $fields[3]['value'] ) ? sanitize_text_field( $fields[3]['value'] ) : '';
    $message = isset( $fields[4]['value'] ) ? sanitize_textarea_field( $fields[4]['value'] ) : '';

    if ( ! is_email( $email ) ) {
        error_log( 'WPForms Volanea alert skipped: invalid reply-to email.' );
        return;
    }

    // Define VOLANEA_API_KEY in server configuration or wp-config.php, not in this file.
    if ( ! defined( 'VOLANEA_API_KEY' ) || VOLANEA_API_KEY === '' ) {
        error_log( 'WPForms Volanea alert skipped: API key is unavailable.' );
        return;
    }

    $html = sprintf(
        '<h2>New website enquiry</h2><p><strong>Name:</strong> %s</p><p><strong>Email:</strong> %s</p><p><strong>Company:</strong> %s</p><p><strong>Message:</strong><br>%s</p>',
        esc_html( $name ),
        esc_html( $email ),
        esc_html( $company ),
        nl2br( esc_html( $message ) )
    );

    $payload = array(
        'from'     => 'Website Forms <forms@example.com>',
        'to'       => 'sales@example.com',
        'reply_to' => $email,
        'subject'  => 'New website enquiry from ' . $name,
        'html'     => $html,
    );

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

    if ( is_wp_error( $response ) ) {
        error_log( 'WPForms Volanea request failed: ' . $response->get_error_message() );
        return;
    }

    $status = wp_remote_retrieve_response_code( $response );
    if ( $status < 200 || $status >= 300 ) {
        error_log( 'WPForms Volanea request returned HTTP ' . $status . ': ' . wp_remote_retrieve_body( $response ) );
    }
}, 10, 4 );

This code shows the actual WPForms action-hook values used for mapping: $fields contains submitted field values keyed by field ID, and $form_data['id'] identifies the form. Adjust the field IDs, form ID, sender, recipient, and endpoint to your environment. Keep VOLANEA_API_KEY out of version control; for example, inject it through your deployment environment and define it during application bootstrap.

Test the integration before enabling it for visitors

Use a real form submission to test the complete chain. A configuration that looks correct in the builder can still fail due to an unverified sending domain, a malformed Smart Tag, a firewall rule, or an API permission problem.

A good test sequence is:

1. Submit the form with a test name and an inbox you control.
2. Confirm that WPForms shows its normal successful submission or confirmation.
3. Check whether the webhook request was accepted in the destination service or in your server logs.
4. Inspect the Volanea activity or message event data for the API response and delivery state.
5. Verify the internal recipient receives the message.
6. Reply to the received message and confirm it goes to the submitter through reply_to.
7. Submit once with an intentionally invalid email address to confirm the form’s validation prevents a bad reply-to value.

Do not use a visitor’s personal data while testing. Test records can remain in WordPress entries, mailboxes, logs, webhook histories, and delivery-event systems. Use a clearly labeled test subject such as [TEST] WPForms delivery check and delete test records according to your retention policy.

Test both success and failure paths

A 2xx API response generally means Volanea accepted the request; it does not by itself guarantee final inbox placement. Treat API acceptance, provider handoff, delivery, and inbox placement as related but distinct stages.

Also test the failure path deliberately. For example, temporarily use a restricted or invalid test key in a staging environment and make sure your team has a way to see the resulting error. An integration that fails silently is worse than one that visibly rejects a test submission.

When this breaks: failures specific to the WPForms-to-API hop

The failure boundary here is not just “email failed.” It is the hop from a completed WordPress form submission to a remote Volanea HTTP endpoint. Diagnose that hop separately from the later email-delivery lifecycle.

Retries can create duplicate sends

A timeout creates ambiguity. WordPress or the webhook layer may decide the request did not complete and retry it, while Volanea may already have accepted the first request. The result can be two alerts for one form submission.

Design recipients and workflows with duplicates in mind. Include an immutable submission identifier in the subject or body when possible, such as the WPForms entry ID for plans and configurations that create entries. With the server-side hook, $entry_id is available to your code and can be included in the subject, logs, or an idempotency strategy supported by your email API.

Do not try to solve duplicates by suppressing all retries. A one-off network interruption should not silently discard a high-value lead. Instead, make a duplicate recognizable, record the response, and choose a retry policy that matches the value and urgency of the form.

Webhook timeouts and blocked outbound traffic

The visitor’s browser waits for WordPress to complete the submission. If a remote API call takes too long, it can slow down the visitor experience or produce an uncertain outcome. On managed WordPress hosts, outbound HTTP requests can also be blocked or filtered by a firewall, DNS policy, or security plugin.

Symptoms include a form that appears to submit but does not produce an alert, HTTP timeout errors, or an API dashboard with no matching request. Check WordPress/PHP error logs, host outbound-request policies, TLS support, DNS resolution, and whether your security layer permits connections to the Volanea API hostname.

For a form where response speed is critical, consider queueing the send through application code or a middleware worker rather than making a long synchronous request in the visitor submission path. Preserve enough data to retry safely, and avoid storing more personal data than necessary.

Missing payload fields and plan-dependent features

An empty reply_to, subject, or body value is usually a mapping issue, not an email-provider issue. Common causes are a field ID copied from another form, a changed form field, conditional logic that leaves a field blank, or a Smart Tag that is malformed.

There is also a plan boundary: the direct Webhooks addon is not included on every WPForms plan. If your installation does not expose Settings » Webhooks, you cannot configure this exact direct webhook flow in that UI. Use the server-side wpforms_process_complete route, upgrade to a plan that includes Webhooks, or use middleware such as Zapier or Make if it meets your security and data-handling requirements.

With middleware, WPForms still triggers on a form submission, but the middle layer receives the submission and makes the Volanea request. That adds another credential store, another failure surface, and potentially another billing and privacy review. It can be useful for a rapid prototype; for a sensitive production lead form, a server-side WordPress hook often offers clearer control.

Authentication and sender failures

A 401 or 403 response usually indicates a missing, expired, malformed, or insufficiently permitted API key. Confirm the Authorization header is set in the server-side webhook configuration and that no extra quotation marks or whitespace were pasted with the secret.

A validation error involving from is different: it commonly means the sender address or domain has not been verified, does not meet the endpoint’s required format, or is not authorized for the key. Keep the sender static and verified. Never make the sender a public form value.

Deliverability choices for form-generated messages

Contact-form alerts are transactional operational messages. Their deliverability depends on more than getting a 200 response from an API. The sending domain needs correctly configured authentication, the message needs a legitimate purpose, and recipient behavior matters.

Keep form alerts separate from newsletters and promotional campaigns where practical. A sudden spike in low-quality or spammy form traffic should not share exactly the same operational path as password resets or other critical customer mail. Likewise, do not silently add a contact-form submitter to marketing mail simply because they asked a question; use explicit consent and preserve the consent record.

Useful practices include:

• Use a clear sender name and a monitored sender mailbox.
• Keep subjects descriptive rather than promotional.
• Validate public email fields at the form level and revalidate them in custom server code.
• Add CAPTCHA, anti-spam controls, and rate limits to public forms.
• Avoid forwarding sensitive information to large internal recipient lists.
• Include only the data a recipient needs to handle the request.
• Review bounce, rejection, and complaint signals for any reply or follow-up flows.

If the contact form creates an automated acknowledgement for the visitor as well as an internal alert, treat those as two different messages with two different recipient policies. The visitor acknowledgement should be sent only after validation, should not expose internal notes, and should contain an easy way to contact your organization if it was sent in error.

Direct webhooks, custom code, and middleware compared

There is no single best architecture for every WordPress site. The right choice depends on how much logic the form requires, who maintains the site, and whether you need a durable audit trail.

Direct WPForms Webhooks

Choose direct Webhooks when the form-to-email mapping is simple, your WPForms plan includes the addon, and you want a low-code integration. It is especially suitable for a static team recipient, a simple reply-to mapping, and a short alert body.

Its limitations are intentional: form-builder configuration is not a full application runtime. Complex transformations, elaborate escaping rules, durable queues, and custom retry logic are harder to manage in a settings screen.

A WordPress server-side hook

Choose custom code when you need field validation, conditional recipients under strict rules, reliable logging, idempotency handling, richer email templates, or secrets that are not stored in the form settings. The wpforms_process_complete action gives you a controlled point after successful form processing.

This route requires development and change-management discipline. Put code in a small site plugin rather than a theme whenever possible, test on staging, and ensure deployment does not overwrite secret configuration.

Zapier or Make middleware

Middleware is useful when non-developers need to connect several business tools around the submission. It can route leads, create CRM records, notify a team channel, and invoke an email API without custom PHP.

The tradeoff is more moving parts. A form submission now depends on WordPress, the automation platform, the Volanea request, and potentially several downstream actions. Review retry behavior across every layer, because independent retries are another path to duplicates.

Operational checklist for a dependable launch

Before publishing the form, review this checklist with the person responsible for WordPress and email delivery:

• The WPForms form ID and referenced field IDs are correct.
• The webhook is attached to the intended form only.
• The request method is POST and the request body is JSON.
• The Volanea endpoint and message schema match the current REST documentation.
• The API key is in server-side configuration or server-side webhook headers, never front-end code.
• The sender domain and from address are verified.
• The recipient is static or controlled by trusted server-side logic.
• Visitor email is used as reply_to, not from.
• Conditional fields have safe fallbacks when they are empty.
• Built-in WPForms notifications are disabled or intentionally retained to avoid duplicates.
• Spam protection and rate limiting are enabled on the public form.
• Logs or observability exist for API failures and non-2xx responses.
• A duplicate-send response plan exists for timeout and retry cases.
• Test submissions have been checked through receipt and reply.

The most durable result is not merely an email that arrives once during setup. It is a documented integration that the next site administrator can inspect, test, rotate credentials for, and recover when a plugin, field, hosting policy, or API changes.

Conclusion

To send email from WPForms with Volanea, use the WPForms Webhooks addon to make a server-side POST after a successful form submission, map each form field with Smart Tags, and authenticate the request with a protected Volanea API key. Keep the sender static and verified, make the visitor address a reply-to value, and test the full delivery path before relying on it for leads or support requests.

For simple alerts, the direct webhook is fast to operate. For sensitive data, advanced routing, or stronger control over validation and retries, use the WordPress wpforms_process_complete hook and make the Volanea API request in server-side code.

FAQ

Does WPForms have a native Volanea plugin?

No native WPForms marketplace plugin is required for this approach. The integration uses WPForms Webhooks to send a form-submission payload to Volanea’s REST API, or a server-side WPForms action hook for a code-based implementation.

What triggers the Volanea email?

A successful WPForms form submission triggers the outbound webhook. WPForms resolves the configured Smart Tags and sends the configured POST request from your WordPress server.

Where should I store the Volanea API key?

Store it only in server-side configuration: the WPForms webhook request headers for a simple setup, or preferably a server environment variable or WordPress configuration constant for custom code. Never expose it in a form field, page source, or browser-side script.

Why did one form submission send two emails?

A request timeout can lead to a retry even when the first request was accepted by the email API. Include a submission identifier in your alert and review retry behavior across WPForms, custom code, and any middleware to identify duplicates safely.

Can I use the submitter’s email address as the sender?

No. Use a verified address on your own domain as from, then set the submitter’s validated email address as reply_to. This is safer and avoids sender-authentication problems.