How to Send Email From Benchmark Email With Volanea

If you need to send email from Benchmark Email with Volanea, the practical route is a Zapier-triggered workflow with a server-side relay—not a native Benchmark Email marketplace app. That distinction matters: Benchmark Email supplies the contact event, while Volanea handles the API delivery of the message you choose to send.

Benchmark Email and Volanea solve different parts of an email stack. Benchmark Email is useful for collecting and managing marketing contacts, forms, lists, and campaigns. Volanea is designed for application-style email sending through SMTP or REST. Connecting them lets a new subscriber or newly created contact initiate a transactional or operational message without exposing your sending credentials in a browser or form.

There is no native Volanea app, listing, or installable marketplace plugin inside Benchmark Email. Rather than looking for one, use Benchmark Email’s Zapier integration as the event source, then have Zapier call a middleware endpoint that sends the final message through Volanea’s REST API. This guide uses the documented Benchmark Email New Contact Zapier trigger as the concrete starting point.

What this integration does—and does not do

The integration is best understood as a three-hop flow:

1. A person becomes a contact in Benchmark Email, for example after completing a Benchmark Email signup form or being added through an import, integration, or staff workflow.
2. Benchmark Email’s Zapier app exposes that event through the New Contact trigger.
3. Zapier passes selected contact fields to your private middleware endpoint, which validates the event and uses Volanea’s REST API to send an email.

The resulting message can be a welcome note, a product-access email, a lead-routing confirmation, a double-check notification for an internal team, or an onboarding message that is more dynamic than the campaign content you maintain in Benchmark Email.

It is not a way to make Benchmark Email itself behave like a general-purpose outbound webhook service. Benchmark Email does not provide a native Volanea connection that you install and configure from a Benchmark Email marketplace. The Zapier trigger is the bridge. Zapier receives Benchmark Email’s contact event, and its Webhooks action is what performs the outbound HTTP request to your service.

That architecture is slightly more involved than pasting an API key into a form, but it creates important separation:

• Benchmark Email remains the contact and marketing-data system.
• Zapier handles trigger polling or event orchestration and field mapping.
• Your middleware owns secrets, validation, retry decisions, and duplicate protection.
• Volanea delivers the message using the sender domain and email API configuration you control.

The Benchmark Email trigger: New Contact

For this workflow, select New Contact as the trigger event in Zapier’s Benchmark Email app. A contact is Benchmark Email’s subscriber/contact record, and this trigger is appropriate when the email should happen because a person was newly added to the connected Benchmark Email account or list.

The specific source of that contact can vary. A Benchmark Email form submission can create the contact; so can a connected form tool, a CRM sync, a manual add, or an import. That flexibility is useful, but it also means you need to decide which newly created contacts should receive the Volanea message. If a bulk import of historical subscribers should not produce a new welcome email, do not rely on “newness” alone. Add a tag, list rule, source value, or separate intake process that distinguishes a genuinely new signup from a backfill.

What Zapier receives from Benchmark Email

Benchmark Email does not send an arbitrary raw HTTP payload directly to Volanea in this setup. Its Zapier trigger presents a normalized set of available contact fields to subsequent Zap steps. The exact sample values and optional fields depend on the account, lists, and contact data available in the trigger test.

At minimum, an email address is the field to treat as required. Depending on your Benchmark Email data, Zapier may also expose values such as the contact identifier, first name, last name, list-related information, subscription status, and custom fields. Do not assume that a first-name field exists merely because it exists on some contacts. A Benchmark Email list can contain contacts with only an email address, and imported records often have incomplete profile data.

For a stable integration, create an explicit payload in Zapier’s Webhooks by Zapier action rather than forwarding every available field. The JSON body below is the shape your Zapier action should send to your middleware endpoint after mapping data tokens from the New Contact trigger:

{
  "event": "benchmark_email.new_contact",
  "contact_id": "{{Benchmark Email Contact ID}}",
  "email": "{{Benchmark Email Email}}",
  "first_name": "{{Benchmark Email First Name}}",
  "last_name": "{{Benchmark Email Last Name}}",
  "list_id": "{{Benchmark Email List ID}}",
  "source": "benchmark-email-zapier"
}

The {{...}} entries represent Zapier field selections, not literal text to send. In the Zap editor, select the matching output token from the New Contact test data. Names in Zapier’s picker can differ slightly from the illustrative labels above, especially for custom contact fields. Map by the actual output shown in your Zap—not by guessing a field label.

If Benchmark Email only supplies an address and no name, send empty strings or omit the name fields. Your middleware should accept both cases. The email itself should be normalized and validated before attempting delivery.

Why a middleware relay is the safer design

It is technically possible to configure an HTTP request action in an automation tool with an API credential in a request header. It is usually not the best production design for an email-sending key. A dedicated relay gives you a controlled boundary between a marketing-system trigger and a delivery API.

The relay can be a small Node.js endpoint on a serverless platform, a containerized service, or a route inside an existing application. It receives a limited event body from Zapier, checks a shared secret, validates the recipient, applies business rules, and makes the Volanea API request from the server.

This is especially valuable when the email content includes account state, an entitlement link, a coupon generated from a private system, or internal metadata. Those values should be assembled from trusted server-side systems, not accepted blindly from a contact record or an automation payload.

A useful trust boundary

Treat the incoming webhook as an instruction to consider sending, not as unquestionable proof that an email should go out. A robust relay should:

• Require a secret header that only your Zap action knows.
• Reject malformed JSON and missing email addresses.
• Normalize the email address before lookup and deduplication.
• Decide whether that contact is eligible for the particular message.
• Use a server-side Volanea API key stored in environment variables or a secret manager.
• Record an event key before—or atomically with—sending so retries do not create duplicate mail.

This pattern also makes a later migration easy. If you move the source from Benchmark Email to a different form, CRM, or product event, your Volanea delivery code can remain unchanged. Only the inbound mapping needs to change.

Build the Zapier workflow

Create a new Zap with Benchmark Email as the trigger app and choose New Contact. Connect the Benchmark Email account that owns the list or forms creating the contacts. During testing, pick a recent representative contact; ideally, test with one contact that has first and last name values and another that has only an email address.

Next, add a filtering step if appropriate. For example, continue only if the new contact belongs to a particular onboarding list, has a custom source field equal to website, or carries a tag that represents a confirmed signup. The exact filter condition should reflect the data that your Benchmark Email account genuinely records. A filter is preferable to relying on a human convention such as “we usually only add website leads to this list.”

Then add Webhooks by Zapier as the action app and choose its custom request option. Configure it as follows:

• Method: POST
• URL: your HTTPS middleware endpoint, such as https://example.com/hooks/benchmark-email
• Payload type: JSON
• Body: the explicit, mapped JSON object shown in the previous section
• Headers: Content-Type: application/json and a private shared-secret header such as X-Integration-Secret

Do not put the Volanea API key in the body. In the preferred design, Zapier never receives that key at all. Zapier only receives a narrow inbound secret used to authenticate its call to your relay. If that secret is ever exposed, rotate it and update the Zap; it should not grant permission to send arbitrary email through Volanea.

Test the real contact path

A successful Zap test only proves that the selected sample can travel through the configured steps. It does not prove every future Benchmark Email contact has the fields your template needs. Create a controlled test contact through the same real source that production contacts use—such as the actual Benchmark Email form—and verify all of the following:

1. The contact appears in the expected Benchmark Email list.
2. Zapier runs the New Contact trigger and passes the expected data tokens.
3. The relay accepts the event and logs a non-sensitive event identifier.
4. Volanea accepts the email request.
5. The message arrives with the intended sender, subject, personalization, and links.

Use a test recipient address you control. Avoid repeatedly creating contacts with the same email during setup unless you understand how the trigger handles previously existing contacts; use tagged plus-addresses where your mailbox supports them.

Map Benchmark Email contact data to an email payload

The mapping should be intentionally small. A welcome email generally needs a recipient address, a safe display name, and possibly an event or contact ID for observability. It usually does not need every list attribute or custom field available in Benchmark Email.

Here is a practical mapping table for the relay:

Do not use unescaped contact values to construct HTML. A first name is user-controlled data in many collection flows. Escape it before inserting it into HTML, and use a neutral fallback such as “there” when it is missing. Similarly, never let a field from Benchmark Email choose the Volanea from address, API key, arbitrary URL, or template name without allow-listing it on the server.

For higher-risk messages, look up the contact in your own application using the email address or a securely mapped external identifier. Then generate the email from current application state. This avoids sending a stale or malformed message because an old profile field in a marketing list happened to be present.

Working Node.js relay and Volanea REST call

The example below is an Express route. It receives the JSON shape configured in the Zapier Webhooks step, authenticates the request with a shared secret, maps contact fields, and calls Volanea’s REST email endpoint. It uses environment variables for secrets and sender configuration.

Before deploying, configure your verified Volanea sender domain and consult the email API setup guides for the current endpoint, authentication, and sending requirements for your account. Keep the sender address aligned with the domain you have authenticated for delivery.

import express from "express";

const app = express();
app.use(express.json({ limit: "32kb" }));

const required = (value, label) => {
  if (!value || typeof value !== "string" || !value.trim()) {
    throw new Error(`${label} is required`);
  }
  return value.trim();
};

const escapeHtml = (value = "") =>
  String(value)
    .replaceAll("&", "&")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#039;");

app.post("/hooks/benchmark-email", async (req, res) => {
  try {
    // Authenticate the Zapier-to-relay hop. This is NOT the Volanea key.
    if (req.get("X-Integration-Secret") !== process.env.BENCHMARK_ZAPIER_SECRET) {
      return res.status(401).json({ error: "unauthorized" });
    }

    const {
      event,
      contact_id: contactId,
      email,
      first_name: firstName = "",
      list_id: listId = ""
    } = req.body;

    if (event !== "benchmark_email.new_contact") {
      return res.status(400).json({ error: "unexpected event" });
    }

    const recipient = required(email, "email").toLowerCase();
    if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(recipient)) {
      return res.status(422).json({ error: "invalid email" });
    }

    // Replace this comment with durable storage in production.
    // Deduplicate on a stable event key before sending, for example:
    // `benchmark:${contactId || recipient}:${listId}:welcome-v1`.
    const eventKey = `benchmark:${contactId || recipient}:${listId}:welcome-v1`;

    const safeFirstName = escapeHtml(firstName.trim()) || "there";
    const subject = "Welcome — here is what happens next";
    const html = `<p>Hi ${safeFirstName},</p><p>Thanks for signing up. We’re glad you’re here.</p>`;
    const text = `Hi ${firstName.trim() || "there"},\n\nThanks for signing up. We’re glad you’re here.`;

    const volaneaResponse = await fetch("https://api.volanea.com/v1/emails", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({
        from: process.env.VOLANEA_FROM_ADDRESS,
        to: [recipient],
        subject,
        html,
        text,
        // Keep source identifiers as metadata only if supported by your API setup.
        metadata: {
          source: "benchmark-email-zapier",
          benchmark_contact_id: String(contactId || ""),
          benchmark_list_id: String(listId || ""),
          event_key: eventKey
        }
      })
    });

    const responseBody = await volaneaResponse.text();
    if (!volaneaResponse.ok) {
      console.error("Volanea send failed", volaneaResponse.status, responseBody);
      return res.status(502).json({ error: "email provider rejected request" });
    }

    console.log("Email accepted", { eventKey, recipient });
    return res.status(202).json({ accepted: true, eventKey });
  } catch (error) {
    console.error("Benchmark relay error", error);
    return res.status(500).json({ error: "internal error" });
  }
});

app.listen(process.env.PORT || 3000);

The important field mapping happens in two places. Zapier maps the New Contact output into email, first_name, contact_id, and list_id. The relay then maps email to Volanea’s to array, generates subject, html, and text, and takes the sender from VOLANEA_FROM_ADDRESS, never from the incoming request.

In production, replace the in-code deduplication comment with a durable database or key-value store. Record a “processing” or “sent” state using a unique constraint on eventKey. Without durable state, a process restart or concurrent retry can send the same welcome message more than once.

Keep Volanea credentials out of Benchmark Email and the browser

The Volanea API key belongs in the middleware runtime’s secret store or environment configuration as VOLANEA_API_KEY. It does not belong in a Benchmark Email form, custom JavaScript snippet, publicly readable page configuration, or an email link. It should also not be included in the JSON body emitted by Zapier.

In this architecture, Benchmark Email holds no Volanea credential. Benchmark Email creates the contact; Zapier carries selected contact fields; the relay owns the delivery credential. The only credential configured in the Zapier action is the limited X-Integration-Secret used to authenticate the relay call.

This distinction is not merely cosmetic. A Volanea API key authorizes sending through your account. If it appears in client-visible JavaScript, a browser network request, a public repository, a screenshot, or an automation configuration accessible to too many editors, someone can use it outside the intended workflow. Rotate compromised keys immediately and audit send activity.

Use separate secrets for development and production. Restrict who can edit the Zap. Configure sender addresses server-side, and avoid logging full API keys, complete request headers, or personal data unnecessarily. If you need to inspect a failure, log a contact ID or a hashed email address rather than the full message payload.

When this breaks: failure modes in this specific hop

A multi-service workflow should be designed for imperfect delivery between each service. The weak points are usually not Volanea’s send call alone; they are the assumptions around the Benchmark Email-to-Zapier trigger and the Zapier-to-relay request.

Retries can cause duplicate sends

Automation platforms may retry a request when they do not receive a timely successful response. A timeout is ambiguous: your relay may have sent the Volanea request successfully, but Zapier may not have received the relay’s response. A retry then creates a second request.

Solve this with idempotency at your relay. Derive a stable event key from the Benchmark Email contact ID when available, plus the list or workflow identifier and a message version. Store it with a unique constraint before sending. If a later call has the same key, return a successful response without issuing another Volanea send.

Do not deduplicate solely on email address forever. The same person may legitimately receive a different message after joining a different list or starting a new onboarding sequence. Include the message purpose and version in the key.

Webhook timeouts and slow downstream work

Your relay should validate, deduplicate, send, and respond quickly. Do not perform long CRM lookups, PDF generation, or multiple external API calls synchronously before returning a response to Zapier. Those operations increase the chance that the HTTP action times out and is retried.

For work that cannot complete quickly, write the event to a queue after authentication and deduplication, return a success response, and let a worker perform the Volanea request. The queue worker still needs the same idempotency protection because workers can also retry after failures.

Missing fields and plan-dependent access

Not every Benchmark Email contact will have the same profile fields, and features or available data can vary with the account configuration and plan. A form may collect only email; an import may omit names; a custom field may not be included in the Zapier sample; a connected list may differ from the list used during testing.

Make email your only required personal field unless your business process explicitly requires more. Give names a fallback. If list membership or a custom marker is required to decide eligibility, fail closed: log the missing field and do not send the message until the mapping is corrected. A generic greeting is better than a misrouted sensitive email.

Contact timing and subscription status

A newly created contact is not automatically proof that a message is appropriate. Depending on how the contact was created, subscription consent, list placement, and confirmation state may be different. Keep your content aligned with the consent and compliance rules that apply to the message type.

For promotional content, use Benchmark Email’s campaign and consent-management capabilities rather than treating a transactional API as a shortcut around unsubscribe handling. Use Volanea for genuine transactional or operational messages, and keep a clear record of why the message was triggered.

Deliverability and sender-domain considerations

A technically successful API request is not the same as a strong inbox outcome. The sender identity used by the Volanea relay should be a domain you control and authenticate for sending. Configure the DNS records required by your Volanea account, use a consistent From identity, and ensure your reply handling is intentional.

Avoid a confusing split where Benchmark Email campaigns come from one brand domain while Volanea onboarding messages come from an unrelated domain. Recipients notice sender inconsistency, and it can undermine trust. If separate streams are necessary, make the relationship clear in the copy and use appropriate subdomains where your domain strategy supports them.

Keep the first message simple. Use a recognizable From name, a subject that matches the signup expectation, readable text content alongside HTML, and a direct reply path when replies should reach a team. Do not overload a new-contact email with many images, tracking redirects, or unrelated promotions before you have validated that the trigger behaves correctly.

Before enabling the Zap for a large list, test deliverability with representative mailbox providers and inspect the full headers. Confirm the sending domain, alignment, and recipient experience. Also verify that an internal notification or admin address cannot accidentally be populated from a public form field.

Choosing this route versus other approaches

The Zapier-plus-relay design is a strong fit when Benchmark Email is already the system that creates the subscriber record and a new contact should invoke an application-controlled email. It is also useful when non-developers need to maintain the trigger and filter while developers retain control over credentials and email delivery logic.

Use a different approach when the real event happens earlier. If a user creates an account in your product, send the account verification or password setup email directly from your application through Volanea. Do not wait for a marketing-list sync to create a contact, then use that delayed contact event to send a security-sensitive message.

Similarly, if the goal is a scheduled newsletter, a segmentation campaign, or a promotional series managed entirely in Benchmark Email, use Benchmark Email’s native campaign and automation capabilities. The integration described here is best for crossing from a Benchmark Email contact event into a controlled, server-side transactional send.

A middleware route also gives you portability. You can later replace Zapier with Make, a custom queue, or another event source without moving your Volanea key into the marketing platform or rewriting the delivery rules. The inbound contract remains a small JSON event, and the relay continues to enforce the same validation and duplicate protection.

Production checklist

Before turning on the workflow, review this checklist with both the person who owns Benchmark Email and the person who owns the sending domain:

• Confirm New Contact is the intended Benchmark Email trigger and identify every way a contact can be created.
• Filter the Zap so imports, internal test records, or unrelated lists cannot initiate the message.
• Map only required contact fields, with an email address as the essential value.
• Put BENCHMARK_ZAPIER_SECRET, VOLANEA_API_KEY, and VOLANEA_FROM_ADDRESS in server-side secrets.
• Verify the Volanea sender domain and use a From address under that domain.
• Implement durable idempotency for each message purpose.
• Return promptly from the relay and queue slow background work.
• Test contacts with full data, email-only data, invalid data, and duplicate-event scenarios.
• Monitor Zap history, relay errors, and Volanea API responses without storing unnecessary personal data.
• Document who can change the Zap, rotate secrets, and pause the workflow if an unexpected send occurs.

Once these controls are in place, the integration remains simple for operators: Benchmark Email creates a contact, Zapier forwards a tightly scoped event, and your relay asks Volanea to send a specific message. That is a more dependable model than coupling a marketing contact record directly to a broadly privileged API credential.

FAQ

Can I install Volanea directly in Benchmark Email?

No. There is no native Volanea app, Benchmark Email marketplace listing, or one-click plugin for this connection. Use Benchmark Email’s Zapier integration to react to a New Contact event, then route the data to your middleware and Volanea.

What exactly triggers the Volanea email?

In this guide, the trigger is Benchmark Email’s New Contact event in Zapier. A newly created Benchmark Email contact starts the Zap, subject to any filters you add for list, source, tag, or custom-field conditions.

Where should the Volanea API key be stored?

Store it only in your server-side middleware environment or secret manager. Benchmark Email should not contain it, and it must never be placed in a form, browser JavaScript, or Zapier payload. Zapier should use only a separate shared secret to authenticate to your relay.

How do I stop duplicate welcome emails?

Create a durable idempotency record keyed by the Benchmark Email contact ID when available, the relevant list or workflow, and the message version. If the same event arrives again after a timeout or retry, return success without sending another Volanea request.

Can I use this for a marketing campaign?

You can technically initiate an email from a new-contact event, but promotional campaigns should remain in a consent-aware marketing workflow with appropriate unsubscribe handling. Use the Volanea relay primarily for transactional or operational messages that are genuinely caused by the contact event.