How to Send Email from AdRoll with Volanea

AdRoll does not provide a native Volanea app, marketplace installation, or standard customer-configurable outbound webhook that can call an email API directly. To send email from AdRoll with Volanea, use AdRoll’s Zapier trigger for new leads, map that lead into a controlled server-side request, and send the resulting message through Volanea’s REST API.

This approach is intentionally more explicit than a one-click integration. It gives your team a clear delivery boundary: AdRoll collects the lead, Zapier handles the event handoff, your middleware validates and normalizes the data, and Volanea sends the email from an authenticated domain.

What this integration does

The practical use case is straightforward: someone submits an AdRoll Lead Ad form, and your system sends a timely transactional or campaign-style follow-up email through Volanea.

For example, a prospect may complete a Lead Ad to request a demo, download a guide, join a waitlist, or ask for a quote. Rather than exporting leads manually, you can route the event into an email workflow that acknowledges the submission, explains the next step, and records a stable delivery event in your own application.

The recommended architecture is:

1. A prospect submits an AdRoll Lead Ad form.
2. AdRoll makes that lead available to Zapier through the AdRoll integration trigger.
3. Zapier invokes a secure endpoint you control.
4. Your endpoint validates the request, maps the lead fields, and creates a deterministic idempotency key.
5. Your endpoint calls Volanea’s REST email API.
6. Volanea accepts the send request and delivers from your configured sending domain.

This is not an “AdRoll sends email” feature in the AdRoll dashboard. AdRoll remains the advertising and lead-acquisition system. Volanea remains the delivery infrastructure. The integration layer connects the two without exposing your sending credentials in browser code, form markup, or a public URL.

The concrete AdRoll trigger: a new Lead Ad lead

The event that begins this workflow is a new lead generated by an AdRoll Lead Ad. In Zapier, the relevant AdRoll trigger is typically presented as New Lead: it runs when a lead is collected from an AdRoll lead-generation flow.

That terminology matters. Do not model this integration as a website page view, an ad impression, or an audience-list change unless your actual objective is different. A lead is the useful event here because it is the point at which you may have an email address and consent context suitable for a follow-up message.

What AdRoll does and does not send directly

AdRoll does not give standard users a general-purpose “POST this JSON to my URL” outbound-webhook configuration for this scenario. Therefore, there is no native raw AdRoll webhook body to paste into Volanea, and there is no place inside AdRoll’s standard campaign interface to safely store a Volanea API key.

Instead, Zapier receives the lead from the AdRoll integration and exposes the available output fields to your Zap. Those fields depend on the lead form and on what AdRoll supplies for that event. Commonly useful values include the lead identifier, email address, name fields, campaign or form metadata, and submission timestamp when available.

Treat the Zapier output as third-party input, not as a guaranteed schema. A form with only an email question will not produce a first name. A form may use a custom question label instead of a conventional first_name field. Some account configurations may expose less campaign metadata than others. Your integration should tolerate that variation.

Start with a lead form that can support the email you want to send

Before building the automation, review the lead form itself. Your email workflow needs an email-address field, and it should ask only for information that is genuinely needed for the next step.

A practical form-to-email plan looks like this:

• Email address: required for the follow-up send.
• First name: optional, but useful for a greeting when populated.
• Interest or request type: useful for choosing a template or message variant.
• Consent language: important when the follow-up is promotional rather than purely transactional.
• Campaign/form identifier: useful for attribution, support, and debugging.

Do not assume that collecting an email address automatically authorizes every type of marketing email. Match the content and frequency of the follow-up to the disclosure shown with the lead form, your privacy notice, and the applicable requirements for your recipients and jurisdiction.

Why Zapier or middleware is required

Because the AdRoll side is not a native outbound HTTP webhook destination, the durable solution includes a middleware hop. Zapier can be that orchestration layer, but it should not be the only place where your business rules live.

A direct Zapier-to-email-API setup can be appropriate for a simple acknowledgement message. However, a small server endpoint is usually the better production design because it gives you validation, logging, deduplication, template selection, secret handling, and a place to change behavior without rebuilding a visual workflow.

Recommended flow

Configure a Zap with these high-level steps:

1. Trigger: AdRoll — New Lead.
2. Optional filter: continue only when the lead contains a non-empty email address.
3. Optional formatter step: normalize basic values, such as trimming spaces and lowercasing the email address.
4. Action: Webhooks by Zapier — send a POST request to your private middleware endpoint.

Your middleware then calls Volanea. This keeps the sending decision in infrastructure you control rather than in a client-visible configuration or a long-lived browser session.

Why not put the Volanea call in client-side code?

Never put a Volanea API key in JavaScript delivered to a browser, in a public landing-page source file, in an AdRoll creative, or in a lead-form URL parameter. Anyone who can load, inspect, copy, or replay that client-side configuration could extract the credential and use it to send mail under your account.

The same caution applies to screenshots, shared Zap exports, and loosely managed documentation. Treat an email-sending API key as a production secret. It can authorize usage, affect deliverability, and create an incident if exposed.

For API setup and current request details, consult the Volanea email API reference and setup guides before deploying.

The payload: normalize Zapier’s AdRoll lead output

Since AdRoll is not posting a native webhook body to your server in this workflow, the request body below is a normalized payload created in Zapier from the fields exposed by the AdRoll New Lead trigger. It is the contract between your Zap and your middleware.

Use a Zapier Webhooks POST action with Content-Type: application/json, then map the corresponding AdRoll fields into this shape:

{
  "source": "adroll",
  "event": "new_lead",
  "lead_id": "{{AdRoll Lead ID}}",
  "email": "{{AdRoll Email}}",
  "first_name": "{{AdRoll First Name}}",
  "last_name": "{{AdRoll Last Name}}",
  "campaign_name": "{{AdRoll Campaign Name}}",
  "form_name": "{{AdRoll Form Name}}",
  "submitted_at": "{{AdRoll Created At}}",
  "interest": "{{AdRoll Custom Question: Interest}}"
}

The tokens inside double braces are not literal AdRoll JSON keys. They stand for the field chips shown in your Zap editor after you test the AdRoll trigger. Select the exact field from the sample lead returned for your account. If your form does not supply campaign_name, form_name, or interest, omit that key or send null; do not fabricate a value.

Map the fields deliberately

A safe minimum mapping is:

The recipient email is the only field required to attempt a send. Everything else should be handled as optional metadata. This prevents a missing name or campaign field from blocking a legitimate confirmation email.

Working middleware example: Zapier lead to Volanea email

The following Node.js example accepts the normalized Zapier request, validates it, creates an idempotency key, and sends the email through Volanea. Store the Volanea credential in the server environment, not in AdRoll, not in the Zap’s request body, and not in front-end code.

import express from "express";
import crypto from "node:crypto";

const app = express();
app.use(express.json());

const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;
const ZAPIER_SHARED_SECRET = process.env.ZAPIER_SHARED_SECRET;

app.post("/integrations/adroll/new-lead", async (req, res) => {
  const suppliedSecret = req.get("x-zapier-secret");

  if (!ZAPIER_SHARED_SECRET || suppliedSecret !== ZAPIER_SHARED_SECRET) {
    return res.status(401).json({ error: "Unauthorized" });
  }

  const {
    source,
    event,
    lead_id,
    email,
    first_name,
    campaign_name,
    form_name,
    submitted_at,
    interest
  } = req.body ?? {};

  if (source !== "adroll" || event !== "new_lead") {
    return res.status(400).json({ error: "Unexpected event" });
  }

  const recipient = String(email || "").trim().toLowerCase();
  if (!recipient || !recipient.includes("@")) {
    return res.status(422).json({ error: "A valid lead email is required" });
  }

  // Prefer a stable source ID. Fall back to deterministic event data only if needed.
  const idempotencyKey = crypto
    .createHash("sha256")
    .update(`adroll:${lead_id || "unknown"}:${recipient}:${submitted_at || "unknown"}`)
    .digest("hex");

  const greeting = first_name ? `Hi ${first_name},` : "Hi,";
  const context = interest
    ? `<p>We received your request about ${escapeHtml(String(interest))}.</p>`
    : "<p>We received your request and will be in touch soon.</p>";

  const response = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify({
      from: {
        email: "hello@example.com",
        name: "Example Company"
      },
      to: [{
        email: recipient,
        name: first_name || undefined
      }],
      subject: "We received your request",
      html: `
        <p>${greeting}</p>
        ${context}
        <p>Thanks for getting in touch. A member of our team will follow up shortly.</p>
        <p><small>Source: ${escapeHtml(campaign_name || form_name || "AdRoll Lead Ad")}</small></p>
      `,
      text: `${greeting}\n\nWe received your request and will be in touch shortly.`,
      metadata: {
        source: "adroll",
        event: "new_lead",
        lead_id: lead_id || null,
        campaign_name: campaign_name || null,
        form_name: form_name || null
      }
    })
  });

  const result = await response.json().catch(() => ({}));

  if (!response.ok) {
    console.error("Volanea send failed", {
      status: response.status,
      result,
      lead_id,
      recipient
    });
    return res.status(502).json({ error: "Email provider request failed" });
  }

  return res.status(202).json({
    accepted: true,
    idempotency_key: idempotencyKey,
    provider_response: result
  });
});

function escapeHtml(value) {
  return value
    .replaceAll("&", "&amp;")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#039;");
}

app.listen(3000, () => {
  console.log("AdRoll lead integration listening on port 3000");
});

The important field mapping happens in two places. First, Zapier maps the AdRoll lead output into the normalized request body. Second, the middleware maps email to Volanea’s recipient field, first_name to optional personalization, and the AdRoll identifiers to metadata that can be searched in your application logs.

Use a verified sender address and domain in the from object. A lead follow-up sent from an unverified or mismatched domain can create delivery problems, confuse recipients, and make troubleshooting much harder.

Where the Volanea API key belongs

The Volanea API key belongs in the secret manager or environment-variable system for the middleware service that calls Volanea. In the example, that is VOLANEA_API_KEY.

It does not belong in:

• An AdRoll campaign setting or ad creative.
• A public lead-form page.
• A browser-side environment variable such as NEXT_PUBLIC_*.
• A Zapier payload field.
• A URL query string.
• Source control, screenshots, or a shared spreadsheet.

If you choose a no-code direct setup rather than middleware, use Zapier’s credential or secure header configuration where available rather than hard-coding a key into the body. Even then, recognize the trade-off: you have less control over validation, response handling, redaction, idempotency storage, and versioned deployment.

The middleware route is preferable for most production teams because it keeps provider secrets in one place. It also lets you rotate a Volanea key without editing every automation that might send mail.

Choose the right message type and timing

A new AdRoll lead is usually best followed by a short acknowledgement rather than an immediate multi-email campaign. The first message should match what the person just did: requested information, registered interest, or submitted a contact form.

A useful confirmation email generally includes:

• A clear acknowledgement that the request was received.
• The expected next step and likely response timing.
• A recognizable sender name and reply path.
• Context from the ad or form, when helpful.
• Consent-appropriate content rather than an unrelated promotion.

Transactional acknowledgement versus marketing nurture

A confirmation that says “we received your demo request” is closer to an operational acknowledgement. A multi-message product newsletter, discount sequence, or recurring promotion is marketing. That distinction affects consent expectations, unsubscribe handling, message content, and your internal policy decisions.

Do not use the same automation for both without deliberately deciding how recipients are enrolled. A safer pattern is to send the immediate acknowledgement, then add the lead to a separately governed nurture flow only when the form’s consent wording and your data policy support it.

Keep the first email simple

The highest-value first email is usually plain, specific, and fast. Avoid loading it with several calls to action, unrelated offers, or excessive tracking parameters. A lead who just completed a form should immediately understand why the email arrived.

If your team needs different follow-ups for different campaigns, select the message server-side based on a known campaign or form value. Use an allowlist of recognized identifiers rather than injecting raw campaign text into a template name or database query.

When this breaks: failures specific to the AdRoll-to-Zapier hop

Every integration should be designed around the ways it can fail. In this workflow, the vulnerable boundary is not only the email provider call; it is also the handoff from AdRoll to Zapier and from Zapier to your endpoint.

Retries can create duplicate sends

Zapier may retry an action when your endpoint times out, returns a transient error, or has a network failure. The endpoint may have already sent the Volanea request before its response was interrupted. Without idempotency, that retry can cause the recipient to receive the same email twice.

That is why the example creates a stable Idempotency-Key from the AdRoll lead ID, recipient address, and submission time. In a mature implementation, also store that key and the resulting Volanea message identifier in a database. If the same event arrives again, return a successful response without creating another send.

Do not use a random UUID as the sole deduplication key. A random value changes on every retry and therefore cannot identify the same logical lead event.

Webhook action timeouts can hide a successful send

A middleware endpoint should acknowledge valid work quickly. If it performs slow database operations, calls several external systems serially, or waits for nonessential analytics, Zapier may regard the step as failed even if the email request eventually succeeds.

For higher volume, accept the lead event, validate it, save a durable job, and return an HTTP success response promptly. A background worker can then perform the Volanea API request. That design improves resilience, but it makes the job table or queue your source of truth for send status.

Lead fields may be absent or inconsistent

AdRoll lead forms and account configurations do not guarantee that every optional field appears in every Zapier sample. A first name may be blank. A custom question may be renamed. Campaign metadata may not be exposed in the way your initial test suggested.

Build your payload contract around the required email address, then make optional fields truly optional. For example:

• Fall back from Hi Jane, to Hi, when no name is available.
• Use a default template when a campaign name is missing.
• Reject only invalid or absent recipient email addresses.
• Log the source field availability without logging unnecessary sensitive values.

Test with leads from every live form, not only the first test lead that Zapier generates.

Authentication failures are different from delivery failures

An HTTP 401 or 403 from your middleware usually means the Zapier shared secret is wrong, missing, or rotated. A provider-side authorization error usually means the Volanea API key is unavailable, invalid, restricted, or attached to the wrong environment.

An accepted API response is different again: it means the provider accepted the request, not necessarily that the message has reached the inbox. Track provider events, bounces, suppressions, and complaint signals separately from the AdRoll lead event.

The email address may be syntactically valid but unusable

A basic @ check is only a first guardrail. A recipient can still be mistyped, suppressed, disposable, non-deliverable, or unable to receive mail. Validate at the appropriate point in your workflow and avoid repeatedly retrying permanent failures.

For lead-quality checks before adding recipients to a longer lifecycle, use an email address verification tool alongside your consent and suppression logic.

Testing the integration before launch

Test the complete path with a real test lead and a recipient mailbox you control. Do not stop after seeing data in Zapier: the most important result is a correctly rendered, correctly attributed email that arrives from the expected sending domain.

Use this launch checklist:

1. Submit a test Lead Ad form with a unique email address.
2. Confirm Zapier receives the event and inspect the actual field names available for mapping.
3. Confirm your middleware receives the normalized JSON payload.
4. Verify that missing optional fields do not cause an error.
5. Verify that the Volanea request uses the intended sender domain and recipient.
6. Trigger the same event twice or replay the request to confirm idempotency prevents duplicates.
7. Test an invalid email address and confirm the failure is logged without retry loops.
8. Test a wrong Zapier shared secret and confirm the endpoint returns an authorization error.
9. Review the final email on desktop and mobile clients.
10. Confirm that campaign metadata is recorded without exposing it to the recipient unnecessarily.

Keep production and test environments separate. A test Zap should use a test middleware URL, a non-production sending configuration where possible, and recipient addresses owned by your team. This prevents accidental messages to real prospects while you change field mappings or templates.

Operational and deliverability considerations

The integration is technically complete only when it is observable. Add structured logs for the incoming lead ID, an internal event ID, the idempotency key, the chosen template, the Volanea response status, and the resulting message ID. Redact or minimize personal data in logs; an email address is useful for support, but it should not be copied into every monitoring event by default.

Set alerts for sharp changes in accepted sends, middleware errors, authorization failures, and provider rejections. A sudden rise in missing-email errors may indicate that an AdRoll form was edited. A rise in duplicate-event detections may indicate retries or a changed event behavior. A rise in bounces or complaints may indicate a list-quality or consent problem rather than an API outage.

Also separate acquisition analytics from email-delivery analytics. AdRoll can help explain which ad and form generated the lead. Volanea can help explain whether the email was accepted and what happened after sending. Joining those records through the lead ID or your own event ID provides a much clearer view than relying on either system alone.

Conclusion

The reliable way to send email from AdRoll with Volanea is not a nonexistent native plugin or marketplace installation. It is an event-driven workflow: use AdRoll’s New Lead trigger through Zapier, send a normalized payload to middleware you control, keep the Volanea API key in server-side secrets, and call Volanea only after validating the lead data.

That architecture adds one small integration layer, but it solves the problems that matter in production: secure credentials, predictable field mapping, duplicate prevention, logging, template control, and graceful handling of incomplete lead data. Start with a simple acknowledgement email, test every live form, and expand only after the core path is observable and idempotent.

FAQ

Can I connect AdRoll to Volanea directly?

Not as a native AdRoll-to-Volanea installation. For AdRoll Lead Ads, use the AdRoll New Lead trigger through Zapier and route the event to middleware or a supported automation endpoint that calls Volanea.

What starts the email send?

The send begins when a new lead is collected through an AdRoll Lead Ad and the AdRoll New Lead trigger makes that lead available to the Zap.

Where should I store the Volanea API key?

Store it in a server-side secret manager or environment variable used by your middleware. Do not place it in browser code, an AdRoll ad, a public form, a Zap payload, or a URL.

How do I stop duplicate emails after retries?

Create a deterministic idempotency key from the AdRoll lead identifier and submission details, pass it with the Volanea request, and persist the processed event in your own datastore before accepting retries as new sends.

What if an AdRoll lead has no first name or campaign field?

Treat those as optional. Send a generic greeting, use a default template, and require only a valid recipient email address for the initial acknowledgement.