How to Send Email from Attentive with Volanea

If you need to send email from Attentive with Volanea, the reliable path is a signed Attentive webhook delivered to your own server-side relay, which then calls Volanea’s REST API. There is no native Volanea app, marketplace listing, or one-click Attentive plugin to install—and that is important, because the relay is where you authenticate the webhook, validate consent and recipient data, prevent duplicate sends, and keep your Volanea secret key private.

This guide uses Attentive’s email.subscribed webhook as the concrete trigger. When a person opts in to email in Attentive, Attentive POSTs a JSON event to your HTTPS endpoint. Your endpoint verifies Attentive’s HMAC signature, maps the subscriber email into a Volanea message request, and sends the email with an idempotency key.

What this integration does—and does not do

Attentive supports outbound webhooks for selected events. Those webhooks are JSON HTTP POST notifications sent to a URL you configure for a custom app. For an email capture use case, the relevant event is email.subscribed: it occurs when a subscriber opts in to an email subscription.

The integration flow is deliberately simple:

1. A shopper completes an Attentive sign-up unit and opts in to email.
2. Attentive emits an email.subscribed webhook notification.
3. Your webhook relay verifies that the request genuinely came from Attentive.
4. The relay checks that the event has an email address and is appropriate for the message you intend to send.
5. The relay calls Volanea’s POST /v1/send endpoint using a secret key stored in server-side environment variables.
6. Volanea accepts the send request and handles the transactional email pipeline.

This is an event bridge, not a synchronized email platform. It does not automatically mirror every Attentive profile field, subscription state, campaign interaction, or segment into Volanea. If you need that broader synchronization, define it separately and treat subscription data as a source-of-truth and consent-design problem—not merely as a webhook-mapping exercise.

It also is not a reason to bypass marketing-email requirements. An email.subscribed event includes subscription metadata, including whether the subscription is MARKETING or TRANSACTIONAL. Use that information to decide what type of message is allowed. A welcome email for a new marketing subscriber should align with the consent the person gave, while an account or order message should be tied to a genuine transactional relationship.

The Attentive trigger: email.subscribed

The exact trigger in this setup is Attentive’s email.subscribed webhook event. Attentive documents this event as occurring when a user opts in to an email subscription.

That makes it a useful trigger for a narrowly defined first-email workflow, such as:

• sending a confirmation or welcome message after an email opt-in;
• delivering a promised resource after the person completes an email sign-up flow;
• notifying an internal team that a high-value email subscription occurred; or
• initiating a follow-up process in your own application.

Do not confuse the trigger with an Attentive Journey action. Attentive Journeys can coordinate messages in Attentive, but the outbound HTTP mechanism covered here is the webhook feature attached to a custom app. The webhook is what sends the event to infrastructure you control.

Attentive’s webhook catalog also includes events such as SMS subscription changes, sends, link clicks, email opens, email unsubscriptions, and custom-attribute updates. For this article, keep the subscription focused: subscribe only to email.subscribed. Narrow subscriptions reduce noise, lower the chance of accidental sends, and make troubleshooting much easier.

Why email.subscribed is the safest starting point

The payload contains the recipient address in subscriber.email, the event time in timestamp, a subscriber identifier, company data, sign-up-source information, and subscription metadata. That is sufficient to create an explicit welcome-email workflow without guessing at fields or scraping the Attentive UI.

It is also an event whose business meaning is clear. A person opted in. That is much easier to reason about than sending an email whenever an email is opened, a profile attribute changes, or an SMS is sent.

The important limitation is that an email subscription event is not an order event, account-creation event, or purchase event. Do not use it as a generic trigger for receipts, password resets, loyalty notices, or cart recovery. Send those from the application or commerce system where the underlying event actually occurred.

Configure the Attentive webhook endpoint

Before adding code, create the destination Attentive will call. Attentive’s webhook setup requires a custom app. In the Attentive integration setup area, select the custom app under Built by you, open its Webhooks tab, enable the event webhook setting, select Universal webhook, and provide your HTTPS endpoint in the HTTP Post URL field.

For this use case, the endpoint might be:

https://events.example.com/webhooks/attentive/email-subscribed

Then select only the email.subscribed event and copy the generated Signing key. Store that signing key in your relay’s secret manager or deployment environment as ATTENTIVE_WEBHOOK_SECRET.

Do not use a temporary request-inspection service as the permanent destination. Those tools are useful during initial payload inspection, but the production endpoint receives subscriber data. It needs access control, logging hygiene, monitoring, durable deployment, and secret storage appropriate for customer information.

Requirements to meet before enabling the webhook

Your endpoint should meet these practical requirements:

• It must use HTTPS. Attentive’s UI requires an https:// HTTP Post URL.
• It must read the raw request body before JSON parsing for signature verification.
• It must verify x-attentive-hmac-sha256 with the Attentive signing key.
• It must return a 2xx response only after it has safely accepted or durably queued the event.
• It must avoid putting full webhook bodies, raw email addresses, or secret headers into application logs.
• It must tolerate duplicate delivery and out-of-order events.

Attentive recommends that a given event type be handled by only one application per company. That is a meaningful operational constraint. If two different custom apps both react to email.subscribed, you can end up with duplicate or conflicting downstream behavior even when both integrations appear healthy in isolation.

The actual Attentive webhook payload

For an email subscription, Attentive documents a payload shaped like this:

{
  "type": "email.subscribed",
  "timestamp": 1632945178104,
  "company": {
    "display_name": "Hudson & Ivy",
    "company_id": "MDc6Q29tcGFueTU"
  },
  "subscriber": {
    "email": "test@gmail.com",
    "phone": "",
    "external_id": 16467358
  },
  "creative": {
    "name": "Desktop Fullscreen (Email + SMS) - 15% Off",
    "type": "DESKTOP",
    "subtype": "DYNAMIC"
  },
  "subscription": {
    "type": "MARKETING"
  }
}

The fields you should care about for a basic welcome-email relay are:

Do not assume optional fields are always present. Attentive’s documentation explicitly notes that email or phone values may be omitted depending on the type of subscription. In this integration, subscriber.email is mandatory for sending an email, so treat a missing or blank address as a controlled non-send—not as a value to replace with a phone number, guessed profile field, or fallback address.

Consent is data, not decoration

The event’s subscription.type should participate in your business rule. For example, a marketing welcome sequence may accept only MARKETING; a service-message workflow should not be triggered simply because a person signed up for marketing email.

This is especially important when teams later reuse the endpoint for more than one flow. The original code might send one welcome message correctly, but a loosely designed relay can become a catch-all sender that turns unrelated profile events into messages. Keep the endpoint purpose-specific and add a new route or event policy for each additional workflow.

Why a server-side relay is required

It is technically possible to point an Attentive webhook at any HTTPS URL you control, but it is not appropriate to point it straight at Volanea’s send endpoint. The Attentive payload is an event payload, not a Volanea send request; it also needs authentication, recipient validation, content construction, consent checks, and duplicate protection before it becomes an email.

More importantly, the Volanea API key does not belong in Attentive or in a browser-visible configuration value. The correct location is your server-side relay’s secret store: for example, a managed environment variable, cloud secret manager, encrypted deployment secret, or platform-specific server secret.

The relevant secret layout is:

ATTENTIVE_WEBHOOK_SECRET=the signing key copied from Attentive webhook settings
VOLANEA_API_KEY=sk_live_...
VOLANEA_FROM_EMAIL=hello@mail.example.com
VOLANEA_FROM_NAME=Example Store

Attentive stores the webhook destination and provides its signing key so your application can authenticate incoming requests. Your middleware stores the Volanea secret key so your application can authenticate outbound send requests. The two secrets do different jobs and should never be substituted for one another.

Never expose the Volanea key to the client

Do not place VOLANEA_API_KEY in:

• JavaScript shipped to a browser;
• a public form configuration object;
• an Attentive sign-up unit’s client-side markup;
• a query string;
• a mobile application bundle;
• a repository committed with real values; or
• a frontend build variable that is intentionally exposed at runtime.

Anyone with a secret sending key can potentially send mail through your account. Even if the sender domain is protected, a leaked key is an operational and deliverability incident. Keep it server-only, scope access to the smallest set of systems possible, rotate it after suspected exposure, and make sure logs redact Authorization headers.

For broader authentication, sender verification, and endpoint details, use the Volanea API reference and setup guides rather than adapting request bodies from another email provider. API field names that look familiar are not necessarily interchangeable.

Working Node.js relay: verify, map, and send

The following Express example receives Attentive’s raw webhook payload, verifies the x-attentive-hmac-sha256 signature, confirms the event and email address, generates a stable idempotency key, and calls Volanea.

It is intentionally designed for one purpose: a single welcome email following an Attentive email.subscribed event with a MARKETING subscription. Change that policy only after deciding what consent and message category should govern the new workflow.

import "dotenv/config";
import crypto from "node:crypto";
import express from "express";

const app = express();

// Keep the raw bytes: Attentive signs the raw request body, not a re-serialized object.
app.post(
  "/webhooks/attentive/email-subscribed",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const signature = req.get("x-attentive-hmac-sha256") || "";
    const expectedSignature = crypto
      .createHmac("sha256", process.env.ATTENTIVE_WEBHOOK_SECRET)
      .update(req.body)
      .digest("hex");

    const signatureIsValid =
      signature.length === expectedSignature.length &&
      crypto.timingSafeEqual(
        Buffer.from(signature, "utf8"),
        Buffer.from(expectedSignature, "utf8")
      );

    if (!signatureIsValid) {
      return res.status(401).json({ error: "Invalid Attentive signature" });
    }

    let event;
    try {
      event = JSON.parse(req.body.toString("utf8"));
    } catch {
      return res.status(400).json({ error: "Invalid JSON" });
    }

    // Concrete Attentive trigger and consent rule for this route.
    if (event.type !== "email.subscribed") {
      return res.status(204).end();
    }

    const recipient = event.subscriber?.email?.trim().toLowerCase();
    const subscriptionType = event.subscription?.type;

    if (!recipient || !recipient.includes("@")) {
      // Acknowledge a valid webhook but deliberately do not send.
      return res.status(204).end();
    }

    if (subscriptionType !== "MARKETING") {
      return res.status(204).end();
    }

    // Stable across Attentive retries for the same event.
    const dedupeMaterial = [
      event.type,
      event.company?.company_id || "unknown-company",
      event.subscriber?.external_id || recipient,
      event.timestamp
    ].join(":");

    const idempotencyKey = crypto
      .createHash("sha256")
      .update(dedupeMaterial)
      .digest("hex");

    // Field mapping:
    // Attentive subscriber.email       -> Volanea to[0].email
    // Environment-controlled sender    -> Volanea from.email / from.name
    // Attentive creative.name          -> welcome-email body context
    const response = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify({
        from: {
          email: process.env.VOLANEA_FROM_EMAIL,
          name: process.env.VOLANEA_FROM_NAME
        },
        to: [{ email: recipient }],
        subject: "Welcome—your email subscription is confirmed",
        text: "Thanks for subscribing. Watch your inbox for updates from us.",
        html: `<p>Thanks for subscribing.</p><p>Watch your inbox for updates from us.</p>`,
        tags: ["attentive", "email-subscribed", "welcome"]
      })
    });

    if (!response.ok) {
      const detail = await response.text();
      console.error("Volanea send failed", {
        status: response.status,
        detail: detail.slice(0, 500),
        eventType: event.type,
        subscriberExternalId: event.subscriber?.external_id
      });

      // Non-2xx causes Attentive to retry webhook delivery.
      return res.status(502).json({ error: "Email send was not accepted" });
    }

    return res.status(202).json({ accepted: true });
  }
);

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

This code is a starting point, not a replacement for a production queue. For low volume, synchronous sending can be acceptable when the API response is reliably fast. For higher volume or critical sends, the safer design is: verify signature, calculate a dedupe key, write a durable job record, return a 2xx response, then have a worker perform the Volanea call. That reduces webhook timeout risk and gives you a durable audit trail.

Field mapping and email content choices

The core mapping is intentionally small. Attentive provides the event; your application owns the email message. Do not blindly interpolate every incoming field into HTML, and do not assume Attentive’s display name or sign-up-unit name should become recipient-visible copy.

A sensible mapping looks like this:

Keep the From address on a domain you have authenticated in Volanea. An unverified sender is not a problem to solve by changing the code repeatedly; it is a domain and DNS configuration issue. A dedicated transactional or lifecycle subdomain can also help you separate types of email operationally, provided your branding, authentication, and consent practices remain coherent.

If the event is being used to welcome marketing subscribers, include the right unsubscribe and preference-management experience for your program. If it is a true transactional email, keep it relevant to the recipient’s requested or expected action. Classification affects copy, list-management expectations, analytics, and reputation—not only legal review.

Before sending at scale, run a representative address through an email address verification check. Verification is not consent and should not be treated as permission to mail someone, but it can help catch malformed or obviously undeliverable addresses before they add noise to your operational metrics.

When this breaks

Every integration has two hops: Attentive to your relay, then your relay to Volanea. Diagnose the hop that failed before changing templates, DNS, or credentials.

Attentive retries create duplicate sends

Attentive retries webhook delivery for up to three days with exponential backoff when it does not receive a successful 2xx response. That is useful for resilience, but it means the same event can arrive more than once.

The classic failure sequence is straightforward: your relay calls Volanea successfully, then crashes or times out before returning 2xx to Attentive. Attentive reasonably retries because it did not see the acknowledgment. Without idempotency, the retry sends a second welcome email.

Use both protections:

1. Send the same Volanea Idempotency-Key for the same Attentive event.
2. Store the key or an event fingerprint in your own durable database with a unique constraint.

The first protects the outbound send call. The second protects your whole business process, including future changes to providers, queues, or retry code. A deterministic key based on event type, company ID, subscriber ID or normalized email, and original timestamp is better than a random UUID generated separately on each delivery attempt.

Your relay times out or returns 5xx

A slow network request, cold start, overloaded database, unavailable secret manager, or Volanea API error can delay your relay. If Attentive does not receive a 2xx, it retries. Do not respond 200 before you know the event has been recorded somewhere durable; doing so can silently lose the send if the process dies immediately afterward.

For production reliability, use an inbox/outbox pattern:

• verify the Attentive signature;
• create a durable event record keyed by the idempotency fingerprint;
• return 202 or 200;
• process the record asynchronously;
• retry the Volanea request with the same idempotency key; and
• record the final API outcome without logging full email content unnecessarily.

This changes a fragile synchronous chain into an observable workflow. It also gives operators a place to inspect pending, accepted, failed, and deliberately skipped events.

The payload lacks an email address

Attentive notes that email and phone fields can be absent depending on the subscription context. The email.subscribed example contains an email address, but your production handler should still verify it rather than assuming it exists.

A missing address should result in a no-op with internal observability: for example, increment a attentive_webhook_skipped_missing_email counter and record a redacted event identifier. Do not send to a guessed address, map a phone number into an email field, or query unrelated systems solely to manufacture a recipient without a defined privacy and identity-resolution policy.

If you expected the address but do not receive it, inspect the actual event type, test the sign-up unit with a real test profile, and verify that the user completed the email portion of the flow. Also confirm that you subscribed to email.subscribed, not sms.subscribed.

Signature verification fails

The most common signature-verification error is parsing and re-stringifying JSON before calculating the HMAC. Attentive signs the raw request bytes and sends the digest in x-attentive-hmac-sha256. The exact byte sequence matters.

Use raw-body middleware for this route. Compare signatures with a timing-safe comparison, and make sure the signing key is the one copied from the exact webhook configuration. Treat a signature mismatch as an authentication failure, not as a malformed subscriber profile.

Volanea rejects the request

If Volanea responds with an error, first classify it:

• 401 or 403: incorrect, revoked, improperly scoped, or unavailable secret key; alternatively, the sender domain may not be verified.
• 400 or 422: request-body validation problem, missing sender, recipient, subject, or content field, depending on the API response.
• 429: rate or quota condition; retry only with controlled backoff and the same idempotency key.
• 5xx or network failure: temporary delivery-path issue; queue and retry safely.

Do not log the API key or full recipient email address while debugging. Log response status, redacted recipient information, the idempotency key, event type, and provider request identifiers where available.

Testing the complete path before launch

A webhook integration is not proven when the endpoint merely returns HTTP 200. Test the whole path from Attentive event creation through email receipt and operational logs.

Start with a non-production sender or clearly labeled test template. Then use this checklist:

1. Confirm the sender domain is verified in Volanea before enabling the webhook.
2. Deploy the endpoint on HTTPS and verify it can receive a POST request.
3. Configure the Attentive custom-app webhook with only email.subscribed.
4. Save the Attentive signing key and Volanea API key as separate server-side secrets.
5. Trigger an email opt-in through a real test sign-up flow.
6. Verify the relay accepts the signature and emits one durable event record.
7. Confirm the Volanea request has the expected From identity, recipient, subject, and tags.
8. Repeat the same payload or force a retry to confirm idempotency prevents a duplicate email.
9. Test a payload without subscriber.email and verify it is skipped safely.
10. Test a deliberately bad signature and verify the route returns 401 without calling Volanea.

Use more than one inbox provider for final testing. A message accepted by an API is not necessarily proof of inbox placement, rendering quality, or a correct unsubscribe experience. Check Gmail, Outlook, iCloud, and a plain-text-capable client if your audience uses them.

Alternatives: Make or Zapier as middleware

If you do not operate a server-side environment, Attentive also supports Make and Zapier integrations. Attentive describes Make as using public APIs and webhooks for real-time signals, and its Zapier documentation explicitly includes passing emails collected in Attentive to an email service provider when no direct integration exists.

Those options can be appropriate for low-volume, non-sensitive workflows, especially when an operations team needs to iterate without deploying code. However, evaluate three constraints before using them for production email sending:

• Secret storage: store the Volanea key in the automation platform’s protected connection or credential feature, never in a public webhook URL or browser-visible field.
• Idempotency: ensure retries reuse a stable idempotency key; a random value created on each automation run defeats duplicate protection.
• Observability: make sure you can trace one Attentive event through the automation run and into the Volanea send result.

A code relay gives you stronger signature handling, flexible policy validation, durable deduplication, and controlled logs. A middleware platform may reduce engineering work, but it does not remove the need to design for retries, consent, and failures.

A production-ready operating model

The best long-term version of this integration is not “webhook in, email out” as an opaque black box. It is a small, well-owned event service with explicit rules.

Give the service these responsibilities:

• authenticate Attentive webhook traffic;
• normalize and validate incoming event data;
• determine whether the event is eligible for a particular message;
• deduplicate safely;
• queue outbound work;
• call Volanea using a server-side secret;
• capture a redacted audit trail; and
• alert when failure rates, skipped addresses, or duplicate attempts rise unexpectedly.

Give it these boundaries:

• It does not decide consent based on a vague profile flag.
• It does not send to an address absent from the event without an approved identity-resolution process.
• It does not turn every Attentive event into an email.
• It does not expose sending credentials to front-end code.
• It does not treat a 2xx API acceptance as the end of deliverability monitoring.

This separation makes future work easier. You can later move the welcome copy into a stored Volanea template, add tenant-specific sender identities, introduce a queue, route events by company ID, or record downstream delivery events—without weakening the original security model.

Conclusion

To send email from Attentive with Volanea, use Attentive’s email.subscribed webhook as the trigger and send it to a server-side relay you control. Verify Attentive’s HMAC signature against the raw body, require subscriber.email, apply an explicit subscription policy, generate a stable idempotency key, and call Volanea’s POST /v1/send endpoint with a server-only secret key.

The key design decision is not the HTTP request itself. It is refusing to skip the middleware layer. That layer protects your API key, transforms Attentive’s event payload into a deliberate email, handles Attentive retries without duplicate sends, and gives you a controlled place to improve reliability as volume grows.

FAQ

Does Volanea have a native Attentive integration?

No. There is no native Volanea app, Attentive marketplace listing, or install-and-authorize flow described here. The supported implementation is a webhook-to-server-to-API integration.

What Attentive event should trigger the first email?

Use email.subscribed when the purpose is a post-opt-in welcome or confirmation flow. It is Attentive’s documented email-subscription webhook event and includes subscriber.email plus subscription metadata.

Where should the Volanea API key be stored?

Store it only in server-side secret storage used by your webhook relay or approved middleware credential vault. Do not place it in Attentive sign-up-unit code, frontend JavaScript, a public URL, or a client application.

How do I stop duplicate welcome emails?

Attentive retries failed webhook deliveries with exponential backoff for up to three days. Use a deterministic event fingerprint and send it as Volanea’s Idempotency-Key; also enforce that fingerprint in your own durable database or queue.

Can I use Zapier or Make instead of writing a webhook relay?

Yes, for an appropriate workflow. Attentive supports Zapier and Make integrations, and both can function as middleware. You still need protected credential storage, reliable field mapping, clear consent rules, and a stable idempotency strategy for retries.