How to Send Email From Divi With Volanea

Divi can collect a lead, support request, booking enquiry, or quote request, but teams that need dependable transactional delivery often need more control than a basic WordPress mail handoff provides. This guide explains how to send email from Divi with Volanea by connecting Divi’s Contact Form module to Volanea from secure server-side WordPress code.

There is an important limitation to establish first: Divi does not ship a native Volanea integration, a Volanea marketplace app, or a Contact Form setting for arbitrary outbound REST webhooks. The direct route is therefore a small WordPress integration that listens to Divi’s documented contact-form submission hook and makes the API request from your server. That distinction matters for security, error handling, and duplicate-send prevention.

What the Divi-to-Volanea integration does

The integration has one job: after a visitor successfully submits a Divi Contact Form module, WordPress receives Divi’s processed form values and passes them to a custom PHP callback. That callback validates the values, builds a transactional email payload, and submits it to Volanea’s REST API over HTTPS.

The resulting sequence is:

1. A visitor submits a Contact Form module on a Divi page.
2. Divi validates the submission, including required fields and spam checks configured for the module.
3. Divi triggers the WordPress action et_pb_contact_form_submit with the processed field data, error status, and contact-form metadata.
4. Your server-side callback maps the data into a Volanea email request.
5. Volanea accepts the request and handles the outbound transactional message.
6. Your code records success or failure without exposing an API key to the visitor’s browser.

This is not a browser-to-email-provider connection. The browser talks to WordPress; WordPress talks to Volanea. Keeping that boundary is the correct design because an email API key is a sending credential, not a public website configuration value.

The pattern is useful for internal notifications, such as a sales inbox receiving a new lead. It can also send an acknowledgement to the person who submitted the form, but do that deliberately: an acknowledgement email should be a distinct message with an expected recipient, a clear sender identity, and content that does not accidentally disclose internal notes.

The real trigger in Divi: Contact Form submission

For this implementation, the concrete trigger is a successful submission of Divi’s Contact Form module. Divi’s module is not a CRM record system with stages or pipeline events. It is a WordPress form module that processes submitted fields and normally sends its notification using WordPress mail behavior.

The integration point is the et_pb_contact_form_submit WordPress action. Divi calls it after processing the contact form. A callback attached to that action receives three arguments:

• $processed_fields_values: the submitted fields after Divi has processed them.
• $et_contact_error: the form error state.
• $contact_form_info: information Divi has assembled about the contact form.

Do not confuse this with a generic JSON webhook emitted by Divi. Divi does not provide a Contact Form UI where you paste a webhook URL and define a JSON body. The hook is server-side PHP running inside the same WordPress installation as Divi.

The processed field shape to expect

The useful data is the processed field array, where each field is keyed by the field ID configured in the Divi module. A typical form with field IDs name, email, and message reaches the hook in this conceptual shape:

$processed_fields_values = array(
    'name' => array(
        'label' => 'Name',
        'value' => 'Avery Chen',
    ),
    'email' => array(
        'label' => 'Email Address',
        'value' => 'avery@example.com',
    ),
    'message' => array(
        'label' => 'How can we help?',
        'value' => 'I would like a quote for an annual plan.',
    ),
);

That is the data shape your callback should map. The exact keys are not universal: they depend on the field IDs in the individual Divi Contact Form module. If an editor calls a field work_email rather than email, code that assumes email will receive an empty value. Establish field IDs as part of the form’s integration contract and avoid changing them casually after launch.

The raw browser request used by the module includes Divi and WordPress form state in addition to visitor-entered values. It is not a stable public API contract and should not be copied into an email payload. Build from $processed_fields_values instead, because it represents the values after Divi’s own processing.

Configure the form before writing code

Create or edit the Contact Form module and make the fields explicit. For a basic internal lead notification, use at least:

• name — text field, required.
• email — email field, required.
• message — text area, required or optional according to the form’s purpose.
• company — optional text field if sales qualification needs it.

Keep the module’s recipient and success-message settings sensible as a fallback, but test the custom route independently. The callback below is intended to create the Volanea send; it does not require a visitor to wait for Volanea’s response before Divi can show the form’s success state.

Why Divi needs a server-side route

A common but unsafe idea is to put a REST request in page JavaScript and store the Volanea API key in a Divi Code module, a theme script, a page builder setting, or a front-end environment variable. Do not do this. Anything delivered to a browser can be inspected in page source, browser developer tools, cached assets, and network requests.

An exposed transactional-email key can enable unauthorized sends, exhaust a sending allowance, harm the domain’s reputation, or create an incident that requires key rotation. Obfuscation is not protection; a JavaScript bundle still has to contain the usable secret.

A WordPress action hook avoids that problem. The key stays in server-side configuration, and the browser receives only Divi’s normal form response. The WordPress server can also apply recipient allowlists, content limits, spam rules, logging, and rate controls before an email request leaves your infrastructure.

This design is effectively lightweight middleware. It is direct in the sense that WordPress sends to Volanea, but it does not pretend that Divi itself has a native webhook configuration screen.

Store the Volanea API key outside Divi

Put the Volanea API key in server-side configuration, ideally as an environment variable managed by your host or deployment system. If your hosting arrangement cannot provide environment variables, define a constant in wp-config.php, which is outside the normal WordPress admin UI and should not be committed to source control.

For example, in wp-config.php:

/** Keep this value in host-managed environment configuration when possible. */
define( 'VOLANEA_API_KEY', getenv( 'VOLANEA_API_KEY' ) ?: 'replace-with-a-server-side-secret' );

In production, do not leave the fallback string in place. A better deployment policy is to fail closed when the environment variable is absent:

$volanea_key = getenv( 'VOLANEA_API_KEY' );
if ( ! $volanea_key ) {
    throw new RuntimeException( 'VOLANEA_API_KEY is not configured.' );
}
define( 'VOLANEA_API_KEY', $volanea_key );

Your callback can then read VOLANEA_API_KEY without putting secrets in the Divi builder, page content, a shortcode attribute, or an options field that many administrators can export.

Use a verified sender, not the visitor’s address

The from address in the Volanea request should be an address on a domain you control and have configured for sending, such as forms@notifications.example.com. Do not set the visitor’s submitted address as the sender. That breaks authentication alignment and can look like spoofing.

Use the visitor’s validated address as reply_to instead. An employee can reply normally while the authenticated sender remains your own domain. Before going live, complete your sending-domain configuration and consult the email API setup guides for the current Volanea authentication and request details.

Working WordPress hook and REST field mapping

The following example is a WordPress plugin-style implementation. Put it in a small site-specific plugin or a must-use plugin rather than in a child theme if possible. A plugin keeps business-critical form behavior separate from presentation changes and makes it less likely that a theme update or redesign removes the integration.

The code uses the Divi action trigger, reads the actual processed field structure, maps it to an email, and uses WordPress’s HTTP API for the server-to-server request.

<?php
/**
 * Plugin Name: Divi Contact Form to Volanea
 * Description: Sends a Volanea transactional notification after a successful Divi Contact Form submission.
 */

add_action( 'et_pb_contact_form_submit', 'site_send_divi_form_to_volanea', 10, 3 );

function site_send_divi_form_to_volanea( $processed_fields_values, $et_contact_error, $contact_form_info ) {
    // Divi has already identified a submission error. Never send from an invalid form.
    if ( ! empty( $et_contact_error ) ) {
        return;
    }

    // Read values by the Divi field IDs used in this particular Contact Form module.
    $field_value = static function( $field_id ) use ( $processed_fields_values ) {
        if ( empty( $processed_fields_values[ $field_id ]['value'] ) ) {
            return '';
        }

        return sanitize_text_field( wp_unslash( $processed_fields_values[ $field_id ]['value'] ) );
    };

    $name    = $field_value( 'name' );
    $email   = sanitize_email( $field_value( 'email' ) );
    $company = $field_value( 'company' );
    $message = $field_value( 'message' );

    // Do not send if the fields needed by this workflow are absent or invalid.
    if ( '' === $name || ! is_email( $email ) || '' === $message ) {
        error_log( 'Divi/Volanea: required form values were missing or invalid.' );
        return;
    }

    if ( ! defined( 'VOLANEA_API_KEY' ) || '' === VOLANEA_API_KEY ) {
        error_log( 'Divi/Volanea: API key is not configured.' );
        return;
    }

    $recipient = 'sales@example.com';
    $subject   = sprintf( 'New website enquiry from %s', $name );

    // Escape values for HTML because visitor input is untrusted.
    $html = '<h2>New website enquiry</h2>'
        . '<p><strong>Name:</strong> ' . esc_html( $name ) . '</p>'
        . '<p><strong>Email:</strong> ' . esc_html( $email ) . '</p>'
        . '<p><strong>Company:</strong> ' . esc_html( $company ?: 'Not supplied' ) . '</p>'
        . '<p><strong>Message:</strong><br>' . nl2br( esc_html( $message ) ) . '</p>';

    // Volanea REST payload: Divi fields are mapped into sender, recipient, subject,
    // HTML content, and Reply-To. Confirm the current endpoint and schema in Volanea docs.
    $payload = array(
        'from' => array(
            'email' => 'forms@notifications.example.com',
            'name'  => 'Example Co website',
        ),
        'to' => array(
            array( 'email' => $recipient, 'name' => 'Sales team' ),
        ),
        'reply_to' => array(
            'email' => $email,
            'name'  => $name,
        ),
        'subject' => $subject,
        'html'    => $html,
    );

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

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

    $status = wp_remote_retrieve_response_code( $response );
    if ( $status < 200 || $status >= 300 ) {
        error_log(
            'Divi/Volanea API returned HTTP ' . $status . ': '
            . wp_remote_retrieve_body( $response )
        );
    }
}

There are two implementation details to review before copying this into production. First, change sales@example.com and forms@notifications.example.com to real addresses for your organization. Second, verify the currently supported Volanea endpoint, authentication header, and message-object field names against the Volanea API reference. API versions are contracts, not guesses, and a production integration should follow the version your account is configured to use.

Field mapping in plain language

The mapping is intentionally narrow:

Do not map a hidden form field directly to to, from, or arbitrary HTML. A visitor can alter browser-submitted values. Recipient routing should be an allowlisted server-side decision.

Test the integration safely

Start with a non-production recipient mailbox. Use a real inbox that your team can inspect, not only a mail-catching tool, because you want to assess both API acceptance and actual inbox delivery. Submit the form with ordinary values, then with punctuation, multiline text, an international name, and an invalid email address.

A useful test plan includes:

1. Successful lead: Confirm Divi shows its configured success response and the internal mailbox receives one notification.
2. Required-field failure: Leave a required field blank. The callback must not send an email.
3. Invalid email: Submit a malformed address. Verify server-side validation prevents a malformed reply_to value.
4. HTML test: Enter <script> or HTML-like content in the message. The received email should show text, not execute or render injected markup.
5. Reply test: Reply from the notification mailbox. The response should go to the visitor through reply_to while the outbound sender remains your configured address.
6. Repeat submission: Submit twice intentionally. Decide whether two form submissions should create two notifications or whether your workflow needs duplicate protection.

Check WordPress or host error logs for Divi/Volanea messages. Avoid logging the full payload in normal production logs because form content may contain personal data. Log a timestamp, a safe form identifier, the HTTP status, and a provider-side message identifier if the API response includes one.

When this breaks: failures in the Divi-to-API hop

Every integration has a failure boundary. Here, the critical boundary is between Divi’s form-processing request and the WordPress server’s outbound request to Volanea. Plan for ambiguity rather than assuming every request is either perfectly sent or perfectly failed.

A timeout can create duplicate sends

Suppose WordPress sends the email request, Volanea accepts it, but the response does not reach WordPress before the 10-second timeout. WordPress sees a timeout. A visitor refreshes and submits again, or an administrator adds retry behavior. The recipient may receive two notifications even though the first delivery succeeded.

Do not automatically retry every failed request without a duplicate strategy. At minimum, generate and store a submission fingerprint using stable elements such as the form identifier, email address, message, and a short time window. Before sending, check whether that fingerprint was recently handled. If Volanea supports an idempotency mechanism in the API version you use, send a stable idempotency key and preserve it across retries; otherwise, maintain the deduplication state in WordPress or a queue.

Be careful with a simplistic fingerprint. Two legitimate enquiries from the same person with the same message could occur. A practical policy might suppress only exact duplicates within five minutes and record the suppression for investigation.

Webhook-like requests can time out even without a native webhook

Although this route uses a WordPress hook rather than a Divi webhook URL, the HTTP behavior is similar: the visitor’s form request is waiting while WordPress does work. A slow DNS lookup, blocked outbound firewall rule, TLS issue, or unavailable API can delay the response.

Keep the outbound HTTP timeout bounded. Ten seconds is a reasonable starting point for an inline notification, but it is not a guarantee of user experience. For high-volume or business-critical forms, write a job to a server-side queue and let a background worker send the Volanea request. That gives the visitor a prompt form confirmation and gives operations a retryable job record.

If you queue messages, preserve enough context to retry safely: normalized recipient, subject, body, submission time, form ID, attempt count, last error, and idempotency or deduplication identifier. Encrypt or strictly limit access to queue data because it contains form submissions.

Fields can be missing after a form edit

A Divi editor can remove a field, rename a field ID, duplicate a module, or deploy a different page version. The form may still look correct to visitors while your code receives no value under the expected key. If email becomes email_address, the sample callback correctly refuses to send, but the business consequence is a missed lead.

Treat field IDs as versioned integration inputs. Document them next to the form, test forms after page-builder changes, and alert on the “required values missing” error rather than leaving it as an ignored log line. If multiple forms use the same hook, identify the intended module using safe metadata from $contact_form_info and route each form through its own explicit mapping.

The same principle applies to plan and feature differences. Divi functionality, WordPress hosting restrictions, security plugins, caching behavior, and third-party form enhancements can affect what data reaches a hook or whether outbound requests are allowed. Test on the actual plan, hosting stack, and active-plugin set used in production; do not rely on a demo-site result.

An accepted API request is not the same as inbox placement

A successful 2xx API response means the provider accepted your request. It does not guarantee that every recipient sees the message in the inbox. Sender-domain authentication, recipient-server policy, content, complaint history, and recipient engagement all affect downstream delivery.

Use an authenticated sending domain, a recognizable From name, an address that can receive replies or a monitored reply path, and content that reflects the visitor’s action. For internal notifications, delivery to a shared mailbox can still be filtered or routed unexpectedly, so test organizational mail rules as well as public mailbox providers.

Security and privacy controls for form email

Contact forms are a common spam and data-exfiltration target. Connecting them to a transactional email API makes it more important to constrain what the form is allowed to do.

First, authenticate the form at the Divi layer with the anti-spam protections available to the module and consider a rate limit at the web application firewall or host. Second, validate again in the server callback. Divi’s validation is valuable, but your outbound email code should independently reject missing required fields, malformed email addresses, unexpectedly long text, and fields you do not recognize.

Third, use a recipient allowlist. A public form should not be capable of turning a submitted recipient field into an API to address. For different departments, map a known form ID or a fixed form type to a fixed internal mailbox on the server.

Finally, minimize personal data. Put only the information needed to handle the enquiry in the email, avoid raw debug logs, and define how long logs or queued jobs are retained. If form submissions are copied to a CRM, help desk, or analytics system, disclose that processing in the site’s privacy information.

Alternatives when custom WordPress code is not practical

The direct hook approach is usually the most controlled option because it stays in WordPress, does not expose credentials, and provides an exact mapping. But it requires a developer who can deploy and maintain a small plugin.

If you cannot add server-side code, use a middleware service only if it can receive the actual form event securely. Divi’s standard Contact Form module does not by itself provide a native arbitrary outbound HTTP webhook configuration. In practice, that means adding a WordPress form or automation component that explicitly supports a webhook or Zapier/Make connection, then having that service call Volanea from its secure credential store.

That route adds another operational hop:

• The form or WordPress automation component captures the submission.
• Zapier, Make, or another middleware workflow receives the event.
• The middleware stores the Volanea credential in its connection settings.
• The middleware maps fields and calls the email API.

It can be appropriate for low-volume, non-sensitive workflows, but assess the tradeoffs: another vendor receives form data, retry semantics may differ, task-based automation costs can grow, and diagnosing a missing notification now spans Divi, WordPress, middleware, and the email API. For a critical lead form, a small reviewed plugin or a queue-backed server integration is generally easier to own.

Operational recommendations for a durable setup

A form-to-email integration is small software, and small software still benefits from ownership. Assign someone to receive failures, rotate credentials, test after Divi updates, and review recipient routing when teams change.

Use separate credentials and sender identities for staging and production. A staging website should send only to test inboxes, even if its form looks identical to production. This prevents accidental testing with real prospects and makes it easier to identify the origin of a message.

Monitor both sides of the integration. On the WordPress side, watch for API errors, validation failures, and an unusual rise in form attempts. On the sending side, monitor acceptance, bounces, complaints, and domain-authentication health. If a submission is important enough that losing it would harm revenue or support, store the lead in a durable database or CRM as well as sending an email notification. Email is an alerting channel, not always the only system of record.

Conclusion

To send email from Divi with Volanea, use Divi’s Contact Form submission hook as the trigger and make the Volanea REST call from WordPress on the server. Divi does not need, and does not provide, a native Volanea marketplace plugin or a browser-visible API-key setting for this workflow.

The durable version of the integration is deliberate: fixed authenticated sender, allowlisted recipient, visitor address in reply_to, explicit Divi field IDs, safe HTML escaping, bounded timeouts, duplicate planning, and monitoring. Build those controls in from the first deployment, and the form can remain a simple editor-friendly Divi module while the sending path is suitable for a production transactional-email workflow.

FAQ

Does Divi have a native Volanea plugin?

No. Divi does not include a native Volanea app, marketplace listing, or Contact Form setting for a Volanea REST connection. Use a server-side WordPress hook or a separate middleware-capable form/automation layer.

What starts the email send in Divi?

A successful submission of a Divi Contact Form module starts the flow. The WordPress integration listens to Divi’s et_pb_contact_form_submit action and receives processed form fields.

Where should the Volanea API key be stored?

Store it only in server-side environment configuration or wp-config.php. Never put it in a Divi Code module, page JavaScript, a front-end environment variable, or any content that a site visitor can download.

Should the visitor’s email address be the From address?

No. Use a verified address on your own sending domain as from, and map the visitor’s validated address to reply_to. That preserves authenticated sending and lets your team reply normally.

How can I stop duplicate form emails?

Use a short-lived submission fingerprint or an API idempotency feature where available, then retry only with a stable identifier. Timeouts are ambiguous: an email provider may have accepted a request even when WordPress did not receive the response.