How to Send Email From AdRoll With Volanea

AdRoll is useful for building and targeting advertising audiences, but send email from AdRoll is not a native outbound automation workflow. The reliable approach is to trigger from the original CRM, form, ecommerce, or lead source; then add the email address to AdRoll and send the transactional message through Volanea in the same server-side or automation flow.

The important limitation: AdRoll is not the outbound trigger

There is no native Volanea app, AdRoll marketplace plugin, or documented AdRoll workflow action that posts an outbound HTTP payload to an arbitrary URL. More importantly, AdRoll’s documented Zapier integration is designed in the other direction: another app supplies a trigger, and AdRoll is selected as the action that adds an email address to a CRM audience. AdRoll’s own setup instructions describe choosing a trigger in Zapier, then choosing AdRoll as the action app and supplying an Advertiser ID, CRM Segment, and email address. (help.adroll.com)

That means there is no AdRoll-side event called “record created,” “form submitted,” or “stage changed” that can start a Volanea email send. AdRoll does not send a public, standard outbound webhook payload for a person joining an audience, being matched to an audience, viewing an ad, or converting after an ad click. Consequently, there is no real AdRoll-to-Volanea webhook JSON body to map, and a guide that claims otherwise would be inventing an integration.

The concrete event that should start this flow is the event before AdRoll receives the address. For example, use the real trigger from your source system:

• New form submission in your form tool.
• New customer or order paid in your ecommerce platform.
• New or updated contact in your CRM.
• Lead created in a sales platform.
• Subscription confirmed in your consent-management or email-capture system.

That source event can safely fan out to two independent actions:

1. Add the contact’s email address to an AdRoll CRM audience for advertising use.
2. Send an appropriate transactional email through Volanea.

This architecture reflects how AdRoll’s Zapier integration actually works. Zapier examples and AdRoll’s help documentation describe the AdRoll action as Add Email to CRM Audience, not an AdRoll trigger that emits contact data downstream. (zapier.com)

What “sending from AdRoll” should mean in practice

The phrase “send email from AdRoll” can mean two different things, and separating them prevents implementation mistakes.

Audience activation is not email permission

An AdRoll CRM audience is an advertising audience. It can contain first-party email data that AdRoll uses for audience matching and advertising purposes. AdRoll says CRM audiences are built from first-party customer data and recommends using connected CRM integrations to sync lists; it also states that advertisers are responsible for having the necessary rights and permissions to upload customer and prospect data. (help.adroll.com)

That does not automatically mean the person opted in to receive promotional email. Your email decision needs its own consent and preference checks. A customer who can appropriately receive an order receipt may not have agreed to marketing email. A lead submitted through a gated download form may have consented only to the requested resource and any disclosure presented with that form.

The source system is the system of record

Use the source system as the authoritative place for:

• The recipient address.
• The event ID or record ID used to deduplicate sends.
• Consent and subscription status.
• Merge data such as name, order number, product name, and account status.
• The business rule that decides whether an email should be sent.

AdRoll should receive the address as a downstream audience update. Volanea should receive a purpose-built message request. Neither system should be treated as the canonical source for a new lead’s permission status.

Recommended architecture: source trigger, AdRoll action, Volanea send

For most teams, the cleanest design is a three-part workflow:

Source application event
        |
        +--> Add Email to CRM Audience in AdRoll
        |
        +--> POST normalized event to your middleware
                    |
                    +--> POST /v1/send at Volanea

This can be implemented with Zapier, Make, an application backend, a serverless function, or a queue worker. The key is that the workflow begins with the original event, not with an assumed audience-change webhook from AdRoll.

Option A: Zapier for low-volume, straightforward flows

Use a Zap where the first step is your real source trigger, such as a new CRM contact or completed form submission. Add the documented AdRoll action Add Email to CRM Audience to keep the retargeting audience current. Then use a Webhooks by Zapier action to POST a normalized event to a server endpoint you control.

Zapier documents Webhooks by Zapier as an action capable of GET, POST, PUT, and Custom Request operations. The Custom Request option is useful when you need explicit JSON and headers. (help.zapier.com)

A Zapier-only alternative is to call Volanea directly using a webhook action. That is acceptable for a small workflow, but middleware is usually safer for production because it keeps template decisions, consent enforcement, idempotency, audit logging, and key rotation in code you control.

Option B: Make for visual workflows with credential storage

Make’s HTTP app can call APIs that do not have a native integration. Its current HTTP documentation supports API-key authentication and recommends defining authentication in its dedicated Credentials field rather than placing secrets directly in headers or query parameters. (apps.make.com)

The scenario still begins at the source app. Route the source event to the AdRoll audience update and to an HTTP request that reaches your middleware or Volanea. Do not configure a Make scenario around an imagined “AdRoll audience member added” trigger unless you have independently confirmed a custom source system exposes one.

Option C: Middleware for production email

A small endpoint or queue worker is the best default when email is customer-facing. It gives you a place to:

• Reject requests with no email address or no allowed consent state.
• Normalize malformed names, currencies, dates, and HTML.
• Generate one stable idempotency key per business event.
• Log the source event and Volanea response without storing unnecessary message content.
• Retry transient failures without duplicating an email.
• Keep the Volanea key out of browser code, public webhooks, and no-code field mappings.

For the Volanea request syntax, keep the Volanea REST API reference close while you build. The documented single-message endpoint is POST /v1/send at the https://api.volanea.com base URL. It uses Bearer authentication and supports an Idempotency-Key header for safe retries. (volanea.com)

The real payload question: what AdRoll does and does not send

Because AdRoll is the downstream action in the supported Zapier pattern, it does not supply a contact-event payload to your Volanea sender. There is no public payload shaped like this:

{
  "adroll_event": "audience_member_added",
  "email": "customer@example.com"
}

That example is not an AdRoll payload and must not be implemented as one.

Instead, define a normalized payload from the system that actually created the contact or conversion. This is a practical contract for the webhook sent by Zapier, Make, or your application to your middleware:

{
  "eventId": "form_01JQ4P8TQ1Y5S7E6",
  "eventType": "lead.created",
  "occurredAt": "2026-09-28T14:32:11.000Z",
  "contact": {
    "email": "alex@example.com",
    "firstName": "Alex",
    "lastName": "Rivera",
    "marketingConsent": false
  },
  "context": {
    "source": "website-demo-form",
    "campaign": "fall-demo-request",
    "accountId": "acct_4821"
  }
}

The essential field mapping is deliberately small:

Do not map an AdRoll audience ID into an email recipient. The audience ID identifies the AdRoll segment, not a person’s deliverable address.

Working middleware code: normalized event to Volanea email

The following Node.js handler receives the normalized payload above and sends a transactional acknowledgement through Volanea. It intentionally does not claim to receive an AdRoll webhook. Instead, it receives the original source event that is also used to populate the AdRoll CRM audience.

// Node 18+ example: POST /hooks/lead-created
// Required environment variables:
//   VOLANEA_API_KEY=sk_live_...
//   VOLANEA_FROM="Acme <updates@notify.example.com>"

export async function handleLeadCreated(request) {
  const event = await request.json();

  const email = event?.contact?.email?.trim().toLowerCase();
  const firstName = event?.contact?.firstName?.trim() || "there";
  const eventId = event?.eventId;
  const eventType = event?.eventType;

  if (!eventId || !email || !eventType) {
    return Response.json(
      { error: "eventId, eventType, and contact.email are required" },
      { status: 400 }
    );
  }

  // This example is a transactional confirmation. Do not turn this into a
  // promotional message unless your source-of-truth consent rule permits it.
  if (eventType !== "lead.created") {
    return Response.json({ skipped: true, reason: "unsupported_event_type" });
  }

  const subject = "We received your request";
  const text = `Hi ${firstName},\n\nThanks for your request. Our team will be in touch soon.\n\n— Acme`;
  const html = `<p>Hi ${escapeHtml(firstName)},</p><p>Thanks for your request. Our team will be in touch soon.</p><p>— Acme</p>`;

  const response = await fetch("https://api.volanea.com/v1/send", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      // Stable across retries of the same source event:
      "Idempotency-Key": `lead-created:${eventId}`
    },
    body: JSON.stringify({
      from: process.env.VOLANEA_FROM,
      to: email,
      subject,
      text,
      html
    })
  });

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

  if (!response.ok) {
    console.error("Volanea send failed", {
      status: response.status,
      eventId,
      result
    });

    return Response.json(
      { error: "email_send_failed", upstreamStatus: response.status },
      { status: 502 }
    );
  }

  return Response.json({ accepted: true, eventId, result }, { status: 202 });
}

function escapeHtml(value) {
  return value.replace(/[&<>'"]/g, (character) => ({
    "&": "&amp;",
    "<": "&lt;",
    ">": "&gt;",
    "'": "&#39;",
    "\"": "&quot;"
  })[character]);
}

Volanea’s documented send endpoint accepts a message with from, to, subject, text, and html; the sender domain must be verified before mail can be accepted. Its send pipeline also supports suppression checks and idempotency for retry-safe sending. (volanea.com)

Why the Idempotency-Key is not optional

A timeout does not tell you whether a recipient received an email. Your middleware may have successfully handed the request to Volanea and then lost the HTTP response. If a workflow tool retries without a stable idempotency key, the second request can create a second logical message.

The example uses lead-created:${eventId}. That works because the source event ID is stable. Do not use the current timestamp, a random UUID generated per attempt, or a workflow execution ID that changes during a retry. Those values defeat deduplication.

Configure the AdRoll audience update separately

The AdRoll part of the workflow should be intentionally boring:

1. Create or identify the appropriate AdRoll CRM audience.
2. In Zapier, choose the source application’s contact, subscriber, customer, or form trigger.
3. Add the AdRoll action that adds the source email address to the CRM audience.
4. Map the source email field to the AdRoll action’s email input.
5. In a separate action or branch, invoke the middleware endpoint above.

AdRoll’s documentation says that the CRM segment ID can be found in the audience URL after creating the segment, and its Zapier setup uses that audience ID as a custom CRM Segment value. It also documents an important limitation: this Zapier integration can add contacts to a list but cannot remove them. (help.adroll.com)

That removal limitation has a second-order effect: if someone revokes consent, update your source-of-truth preference system and suppress promotional email immediately. Do not assume an AdRoll audience removal will occur through this particular Zapier route, and do not use audience membership as your email suppression system.

Authentication: where the Volanea key belongs

The Volanea API key must live only in a server-side secret store or an automation platform’s protected credential mechanism. It must never appear in:

• Browser JavaScript.
• A public landing-page configuration object.
• An AdRoll Pixel snippet.
• An exposed Zapier Catch Hook URL or a client-side form field.
• A Git repository, screenshot, ticket, or email.

There is no place to store a Volanea key “on the AdRoll side” because AdRoll does not expose the required outbound custom-request action for this workflow. Put the key in middleware environment variables such as VOLANEA_API_KEY, or configure it in the protected credentials mechanism of the HTTP automation tool you use.

If you use Make directly, its HTTP documentation specifically recommends the dedicated Credentials field for authentication instead of putting secrets into ordinary headers or query parameters, because that centralizes key management and makes rotation safer. (apps.make.com)

If you use Zapier to call your middleware, the middleware holds the Volanea key and Zapier holds only a separate shared secret or signed credential for reaching your endpoint. This reduces the blast radius: rotating Volanea credentials does not require editing every automation.

Protect the middleware endpoint too

A secret Volanea key is only one half of the security model. Your endpoint must also reject untrusted requests. At minimum:

• Require a shared secret in a request header or use a signed webhook scheme.
• Rate-limit requests by source and IP where appropriate.
• Validate the JSON schema and reject missing eventId or contact.email values.
• Allowlist supported eventType values.
• Log request IDs, not full addresses or raw body content, where possible.
• Return a successful response only after durable processing is assured.

A Zapier Catch Hook URL should also be treated as a secret. Zapier warns that publishing the URL, including in front-end JavaScript, can allow others to trigger the workflow. (help.zapier.com)

When this breaks

This integration has two distinct hops: the source-to-AdRoll audience update and the source-to-Volanea send. Diagnose them separately instead of assuming one success proves the other succeeded.

Retries can cause duplicate sends

Workflow tools and HTTP clients commonly retry when a response is slow, absent, or a 5xx status is returned. A retry might happen even when the first Volanea request was accepted but the caller never received the response. This is why the stable Idempotency-Key derived from the source event is critical.

Use an event ID from the original CRM, order, form submission, or application database. If the source platform does not provide a stable event ID, generate one once when first receiving the event and persist it before calling Volanea.

A webhook timeout is not an email failure

A source platform or automation service can time out waiting for middleware. If middleware then continues processing asynchronously, the source may retry. Return a quick acknowledgement only after writing the event to a durable queue or idempotency store. Let a worker perform the Volanea request afterward.

For low-volume flows, a synchronous call may be enough. For receipts, password-related notices, payment events, or lead routing where duplicates are costly, queue the event and persist a unique event record before attempting delivery.

Fields may be absent, blank, or shaped differently

The source event—not AdRoll—determines the available payload. A lead form may have only an email address. An ecommerce event may have an email address but no first name. A CRM trigger might emit a contact before enrichment or consent fields are available.

Design templates so personalization is optional. Use Hi there rather than sending Hi undefined. Reject empty or malformed email values before calling Volanea. Require the fields that matter to the business decision, such as order ID for a receipt or subscription status for a marketing campaign.

AdRoll audience sync does not prove the email was sent

The AdRoll Zapier action and the Volanea API call are independent. An address can be successfully added to an AdRoll audience while an email is skipped because the address is suppressed, the sender domain is not verified, the request is malformed, or the account has a sending constraint. Conversely, an email may be accepted while the AdRoll audience update fails.

Track both outcomes against the same source eventId. That gives operations a practical reconciliation view: audience_update_status, email_send_status, and last_error.

Plan and product availability can change the available fields

AdRoll’s publicly documented API focuses on advertising resources such as ads, audiences, campaigns, organization data, geotargeting, and reporting. Its newer Conversions and Events API is documented as server-to-server event ingestion into AdRoll, not a general outbound event stream from AdRoll. It is also described as open beta and requiring an AdRoll-provided API key and technical implementation. (developers.adroll.com)

Do not build a customer email workflow around an assumed event export, audience-member webhook, or automation-builder feature that is not available in your account. Confirm your exact AdRoll plan and enabled products with AdRoll before committing to an architecture that depends on them.

Email content and deliverability decisions

The technical connection is only the beginning. The best email type for this workflow is usually a clearly triggered transactional message: a demo-request acknowledgement, account notification, order update, password-related notification, or confirmation that a requested asset is on its way.

Avoid using an AdRoll audience update as the trigger for a broad promotional blast. Audience membership can be delayed by syncing, matching, or operational workflows, and it does not communicate why the person should receive a particular message at that moment. AdRoll notes that CRM audience matching and population can take time, which reinforces why the original source event is the correct trigger for immediate customer email. (help.adroll.com)

Before production, verify the domain used in from, use a real reply path for customer-facing messages, include a plain-text alternative, and test with addresses at multiple mailbox providers. A 2xx API response means the message was accepted for processing; it is not a promise that it reached the inbox.

A practical rollout checklist

Use this checklist before activating the workflow for real contacts:

1. Choose one source event. Start with a narrowly defined event such as lead.created or order.paid.
2. Document consent. State whether the resulting email is transactional, marketing, or both, and identify the source-of-truth field.
3. Create the AdRoll CRM audience. Keep the audience purpose explicit, such as “Demo leads—retargeting.”
4. Build two independent actions. One updates AdRoll; one sends the normalized event to middleware.
5. Set a verified Volanea sender. Do not test production sending from an unverified domain.
6. Use a stable idempotency key. Base it on a durable source event ID.
7. Test failure modes. Send the same event twice, omit a first name, simulate a 500 response, and retry after a timeout.
8. Reconcile outcomes. Store whether the AdRoll update and the Volanea send each succeeded.
9. Add observability. Alert on persistent 4xx validation failures and repeated 5xx upstream failures.
10. Review privacy and retention. Keep only the data your messaging workflow needs.

Conclusion

You cannot directly send email from AdRoll because AdRoll’s documented public integration model does not provide an outbound contact-event webhook or arbitrary HTTP action for this use case. Its Zapier integration is built to add email addresses from another app into an AdRoll CRM audience.

The dependable solution is to start with the original business event, update the AdRoll audience as one action, and call Volanea as another. This preserves consent context, avoids fictional AdRoll payloads, keeps the Volanea API key server-side, and gives you an event ID that can prevent duplicates when retries happen.

FAQ

Can AdRoll trigger a Volanea email when someone joins an audience?

Not through a documented native outbound webhook, marketplace integration, or Zapier trigger. Use the original CRM, form, ecommerce, or application event that supplied the address to AdRoll instead. (help.adroll.com)

What is the AdRoll trigger for this integration?

There is no concrete AdRoll trigger for this workflow. The concrete trigger is the upstream event, such as a new form submission, new customer, or new CRM contact; AdRoll is a downstream action that adds the email to a CRM audience.

Where should I store the Volanea API key?

Store it in a server-side environment variable, secrets manager, or protected automation credential store. Never place it in client-side code, a pixel, or a publicly exposed webhook configuration.

How do I stop retries from sending duplicate emails?

Use Volanea’s Idempotency-Key header with a stable value derived from the original event ID, such as lead-created:form_01JQ4P8TQ1Y5S7E6. Reuse that exact key on every retry of the same business event. (volanea.com)

Can I use this flow for marketing email?

Only if the source system records valid marketing consent and your message complies with the recipient’s preferences and applicable requirements. Being in an AdRoll CRM audience is not, by itself, evidence of email marketing permission. (help.adroll.com)