How to Send Email From Outgrow With Volanea

Outgrow can collect high-intent leads through calculators, quizzes, assessments, forms, and polls—but collecting a lead is only useful if the next email arrives quickly. This guide explains how to send email from Outgrow with Volanea using Outgrow’s webhook capability and a small server-side integration.

There is an important architectural detail up front: Volanea does not provide a native Outgrow marketplace app or one-click Outgrow plugin. The reliable integration is an event flow: a person completes an Outgrow experience, Outgrow posts the lead data to a webhook URL you control, your server validates and maps that data, and the server calls Volanea’s email REST API. That design keeps your API key private, gives you full control over template logic, and makes duplicate protection possible.

The integration architecture

The basic path is deliberately simple:

1. A visitor completes an Outgrow content experience and submits the lead form.
2. Outgrow creates a lead and sends the lead data to the webhook URL configured for that experience.
3. Your webhook endpoint checks that the request is valid and extracts the email address, name, result, and any relevant answers.
4. Your endpoint sends a REST request to Volanea with the recipient, sender, subject, and HTML or text content.
5. Your application records the Outgrow lead identifier or another stable event key so a retry does not create a second email.

This is not merely a workaround for the absence of a native integration. It is usually the better design for a post-submission email because it creates a clear boundary between lead capture and delivery. Outgrow remains responsible for the interactive experience and lead event; Volanea remains responsible for sending; your integration owns business logic such as consent, segmentation, content selection, and idempotency.

For a lower-code implementation, the same architecture can use Zapier or Make as the middle layer. Outgrow can trigger a workflow when it receives a new lead, and the workflow can make an authenticated HTTP request to Volanea. The same data-mapping and duplicate-send concerns still apply, so read the direct webhook design first even if you choose an automation platform.

The Outgrow trigger: a new lead submission

The event that starts this workflow is an Outgrow lead submission. In practical terms, a person reaches the lead-generation portion of an Outgrow experience, submits identifying information such as an email address, and Outgrow records a new lead for that content piece.

That distinction matters. A calculator result changing in the browser is not automatically an email event. A visitor can change sliders, retake a quiz, or move between questions without becoming an identifiable lead. Configure the workflow around the completed lead capture event, not around every interaction in the experience.

Configure the lead form before the webhook

Before wiring delivery, decide which fields the email needs. At a minimum, collect an email field. If your message is personalized, collect a name field as well. For result-based follow-up, make sure your result or outcome is available in the lead data for the relevant content type.

Use stable, understandable field labels. A field labelled Work email is easier to map and debug than an unnamed custom input. If you plan to use a quiz result in the message, give each result a deliberate title and avoid changing it casually after automation is live; result labels often become part of your routing logic.

A useful minimum schema is:

• Email — the recipient address.
• First Name — optional personalization value.
• Result or outcome title — the content branch that determines the message.
• A score, recommendation, estimate, or answer summary — optional context for the email.
• Consent information — required if the message is promotional rather than purely transactional.

Add the webhook destination

In Outgrow, use the webhook integration for the relevant content experience and set its destination to an HTTPS endpoint you control, such as https://hooks.example.com/outgrow/leads. Use a test lead after saving the integration and retain the received test request while you build the mapping.

Do not point Outgrow directly at a browser application, a public static page, or a Volanea API URL. A browser application exposes credentials and cannot safely make a trusted server-to-server decision. A Volanea email endpoint expects an email-send payload, whereas an Outgrow webhook provides lead data; a server or workflow layer is what translates one into the other.

Understand the Outgrow payload before mapping it

Outgrow sends a JSON HTTP request containing lead information when the webhook fires. The precise set of properties depends on the content type, the lead form fields you enabled, the questions used in the experience, and the plan or integration configuration. A calculator will not necessarily produce the same fields as an assessment, and optional lead fields may be absent when a visitor leaves them blank.

Treat your webhook test request as the contract for that specific Outgrow experience. Do not build production mapping from a guessed field name or from a field that only happens to exist in one test record.

A representative lead payload

The important shape is a lead record plus submitted field values. A representative payload for an Outgrow lead can look like this:

{
  "id": "lead_01J9X7Q9E6Q3",
  "email": "alex@example.com",
  "name": "Alex Morgan",
  "created_at": "2026-10-10T14:22:18.000Z",
  "content_title": "Growth Readiness Assessment",
  "result": "Ready to scale",
  "answers": {
    "Team size": "11-50",
    "Primary goal": "Improve activation"
  }
}

The values are illustrative; your received request is authoritative. In particular, check whether your account exposes fields at the top level, under a lead-data object, or by the labels configured in the Outgrow lead form. Preserve the raw request in a protected log during setup, with personal data redacted or access-controlled, so you can compare future changes against the original payload.

The mapping for this example is straightforward:

Avoid relying on a full name being present. Many lead forms require only email, and some people enter a single name. Your message should work with a neutral greeting when no usable first name exists.

Build a secure webhook-to-email service

A minimal middleware service can be a serverless function, an Express or Fastify application, a worker, or a route in your existing backend. Its job is not just forwarding JSON. It must validate input, make the delivery decision, prevent repeat sends, and keep the Volanea credential out of Outgrow and out of the client.

The example below uses Node.js and Fastify. It receives the Outgrow lead payload, normalizes likely field locations, chooses an email template from the result, and calls Volanea’s REST endpoint. Store VOLANEA_API_KEY and VOLANEA_FROM_EMAIL in the deployment platform’s encrypted environment-variable or secret manager—not in source control.

import Fastify from "fastify";

const app = Fastify({ logger: true });

// Replace this with a durable database table or key-value store in production.
// The key must survive process restarts and be unique per Outgrow lead event.
const processedLeadIds = new Set();

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

function firstName(name = "") {
  const first = String(name).trim().split(/\s+/)[0];
  return first || "there";
}

app.post("/outgrow/leads", async (request, reply) => {
  const lead = request.body;

  // Match these fallbacks to the actual test payload from your Outgrow experience.
  const leadId = lead.id ?? lead.lead_id ?? lead.data?.id;
  const email = lead.email ?? lead.data?.email ?? lead.answers?.Email;
  const name = lead.name ?? lead.data?.name ?? lead.answers?.["First Name"];
  const result = lead.result ?? lead.data?.result ?? "Your results";
  const primaryGoal = lead.answers?.["Primary goal"] ?? "your goals";

  if (!leadId) {
    request.log.warn({ lead }, "Outgrow payload had no stable lead ID");
    return reply.code(400).send({ error: "Missing Outgrow lead ID" });
  }

  if (!email || !/^\S+@\S+\.\S+$/.test(email)) {
    request.log.warn({ leadId }, "Outgrow payload had no usable email");
    // Return a successful response if this is intentionally a non-email lead;
    // otherwise Outgrow may retry a payload that can never be delivered.
    return reply.code(200).send({ skipped: "No usable email address" });
  }

  if (processedLeadIds.has(leadId)) {
    return reply.code(200).send({ duplicate: true });
  }

  const safeName = escapeHtml(firstName(name));
  const safeResult = escapeHtml(result);
  const safeGoal = escapeHtml(primaryGoal);

  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_EMAIL,
      to: [{ email, name: name || undefined }],
      subject: `Your assessment result: ${result}`,
      html: `
        <p>Hi ${safeName},</p>
        <p>Your result is <strong>${safeResult}</strong>.</p>
        <p>Based on your answer, improving ${safeGoal} is a useful next step.</p>
        <p>Reply to this email if you would like help interpreting the result.</p>
      `,
      text: `Hi ${firstName(name)},\n\nYour result is ${result}.\n\nBased on your answer, improving ${primaryGoal} is a useful next step.\n\nReply to this email if you would like help interpreting the result.`
    })
  });

  if (!volaneaResponse.ok) {
    const errorBody = await volaneaResponse.text();
    request.log.error(
      { leadId, status: volaneaResponse.status, errorBody },
      "Volanea email request failed"
    );
    return reply.code(502).send({ error: "Email provider request failed" });
  }

  // In production, write this only after the provider accepts the request,
  // using a durable conditional insert keyed by leadId.
  processedLeadIds.add(leadId);

  return reply.code(200).send({ sent: true, leadId });
});

await app.listen({ port: process.env.PORT || 3000, host: "0.0.0.0" });

The Volanea call is the POST https://api.volanea.com/v1/emails request in the example. It maps the Outgrow recipient to to, uses your verified sender in from, and creates both HTML and plain-text versions. Before deployment, compare the request fields and authentication convention with the current email API reference and setup guides, then send a controlled test to an inbox you own.

Use a durable idempotency store

The in-memory Set exists only to show the logic. It is not sufficient in a production deployment because serverless functions can run in parallel, processes restart, and multiple application instances do not share memory.

Use a database record with a unique constraint on the Outgrow lead ID, or a key-value store operation that creates a key only if absent. The safest sequence is: claim the lead ID atomically, send the email, and record the provider response. If a send fails after the claim, use a defined retry state rather than immediately treating the event as complete.

Keep the Volanea API key out of Outgrow and the browser

The Volanea API key belongs in your middleware’s secret store. It should not be placed in an Outgrow custom field, an Outgrow result page, a public JavaScript bundle, an email template, a webhook URL query string, or a client-visible configuration file.

Outgrow’s role in this direct design is to call your webhook URL. It does not need the Volanea key, and that is a benefit. Your endpoint adds the Authorization header only after it has received and validated the lead event on the server.

Why direct browser delivery is unsafe

If a browser calls an email API directly, anyone who can open developer tools can recover the key and send mail on your behalf. That can create immediate billing, abuse, and sender-reputation risk. Even restricting the key by domain does not make a secret in client-side code safe.

A private server endpoint also gives you a place to enforce your own rules. For example, you can reject malformed addresses, suppress addresses that have opted out, require a consent value before sending a marketing message, and prevent results from being inserted into HTML without escaping.

Verify the sending identity

Set VOLANEA_FROM_EMAIL to an address on a domain you have authenticated in Volanea. Do not use a visitor’s address as the sender. Put a reply-capable mailbox in the sender or reply-to configuration according to your support process, and make sure the message’s purpose matches the consent collected in Outgrow.

For campaign-style follow-up, email consent is not a cosmetic checkbox. A lead who submits a calculator may expect the requested result, but that does not automatically establish permission for an ongoing promotional series in every jurisdiction. Separate the immediate requested result from optional marketing enrollment in both your form design and your automation logic.

Personalize without making templates fragile

A result email should answer the question the visitor just asked. If someone completes a readiness assessment, the immediate email can confirm the result, summarize one or two inputs, and point to the appropriate next step. It should not depend on every possible optional answer being present.

Start with a dependable baseline message that requires only an address and result. Add personalization only where missing data has a graceful fallback. For example, Hi there is better than rendering Hi undefined, and a generic recommendation is better than failing an entire email because an optional custom answer is absent.

Route by result, not by copied prose

As the experience grows, avoid putting all content decisions in one long template literal. Define a map keyed by expected result title or an internal result code:

const contentByResult = {
  "Ready to scale": {
    subject: "Your next steps for scaling",
    headline: "You are ready to build a repeatable growth system."
  },
  "Build the foundation": {
    subject: "Your foundation-building plan",
    headline: "Start by tightening the basics before adding complexity."
  }
};

const content = contentByResult[result] ?? {
  subject: "Your Outgrow result",
  headline: "Here is a practical next step based on your responses."
};

Keep a fallback for renamed, translated, or unexpected results. It is common for a marketing team to adjust wording in Outgrow without realizing that a webhook integration routes on the previous text. A fallback prevents a harmless copy change from becoming an outage.

Treat answers as untrusted input

Every answer submitted through a public form is untrusted. Escape text before adding it to HTML, cap its length before logging it, and never evaluate it as code. If you include calculator values, format numbers and currencies on the server rather than assuming a string is already safe or correctly formatted.

Also consider data minimization. An Outgrow webhook can contain more lead information than an email requires. Send only necessary values to the template and avoid placing sensitive answers in subjects, URLs, or third-party analytics parameters.

A no-code route with Zapier or Make

If you do not operate an application server, use Outgrow’s Zapier integration or a webhook-triggered scenario in Make as the middle layer. The model remains: Outgrow lead event first, transformation second, Volanea HTTP request last.

In Zapier, select the Outgrow new-lead trigger for the relevant content, test it with a real sample lead, then add an HTTP request action. In Make, receive the Outgrow webhook through a custom webhook module, inspect the captured bundle, and add an HTTP module that makes the POST request to Volanea. Map only the fields your email needs.

The HTTP request should use the same essential payload:

{
  "from": "Results Team <results@example.com>",
  "to": [{"email": "{{Outgrow Email}}", "name": "{{Outgrow Name}}"}],
  "subject": "Your result: {{Outgrow Result}}",
  "html": "<p>Hi {{Outgrow First Name}},</p><p>Your result is <strong>{{Outgrow Result}}</strong>.</p>",
  "text": "Hi {{Outgrow First Name}},\n\nYour result is {{Outgrow Result}}."
}

Store the Volanea key in the automation platform’s private credential or connection settings where available, or in its encrypted secret facility—not in mapped lead fields. Be especially careful with workflow run histories: they may retain recipient addresses and response bodies. Limit access, set appropriate retention, and avoid logging full payloads unnecessarily.

No-code tools are excellent for a small number of clear workflows. A dedicated endpoint is usually the stronger choice when you need conditional content, a reliable idempotency database, custom consent logic, high volume, or detailed delivery observability.

When this breaks: diagnose this specific hop

The Outgrow-to-webhook-to-email path has failure modes that are different from a standard form handler. Design for them before your first campaign or high-traffic quiz launch.

Outgrow retries can create duplicate sends

A webhook sender may retry when it does not receive a timely successful response, when the network connection drops, or when your endpoint returns an error. The first attempt may have reached your application and even triggered Volanea, while the response back to Outgrow was lost. Without idempotency, the retry sends the recipient a second copy.

Use the stable Outgrow lead ID as the idempotency key whenever it is provided. Store it in a durable system with a uniqueness guarantee. Do not use only the recipient email as the key: one person can legitimately submit two different calculators or submit again after changing their answers.

Webhook timeouts can be mistaken for email failures

Your endpoint should respond quickly. Do not make it wait on slow analytics calls, CRM enrichment, image generation, or multiple third-party APIs before returning a success status. A long-running request increases the likelihood of a timeout and an Outgrow retry.

For more complex work, persist the lead event quickly, return a success response, and process it asynchronously. If you do send synchronously, set conservative outbound timeouts to Volanea and log the lead ID plus the provider response status. That gives you enough information to determine whether the failure occurred before or after Volanea accepted the send.

Payload fields can be missing or renamed

Different Outgrow experiences, lead forms, and configurations can expose different data. Optional lead-form fields may be absent, custom answers may use the displayed question label, and result fields may not exist for every content format. In addition, changes to a question label can change the key your middleware expects.

Defend against this with required-field validation, defaults for optional fields, and an alert for schema failures. When editing an Outgrow lead form or result configuration, submit a new test lead and compare its payload with the mapping before publishing the change.

A 2xx response is not proof of inbox placement

A successful response from your middleware means it accepted the Outgrow event. A successful response from Volanea means the provider accepted the email request. Neither alone proves that the recipient saw the message in the inbox.

Track delivery events and bounces in Volanea, use an authenticated sending domain, and keep content aligned with what the visitor requested. If messages are accepted but underperform, investigate sender authentication, recipient address quality, consent, and message relevance before repeatedly resending.

Test the complete journey

Testing only the API request is not enough. Test the actual Outgrow submission flow because lead data often differs between a manually constructed JSON object and a live submission.

Use this rollout checklist:

1. Create a test version of the Outgrow experience or use an internal test audience.
2. Submit leads with every important result branch.
3. Submit a lead with only required fields and another with all optional fields.
4. Confirm the raw webhook payload and update the mapping to match it exactly.
5. Send to inboxes you control and check subject, greeting, text fallback, links, and reply behavior.
6. Repeat the same submission or replay the same event to confirm idempotency prevents a duplicate.
7. Simulate a Volanea API error and verify your logs preserve the lead ID without exposing the API key or unnecessary personal data.
8. Confirm that an unsubscribe or consent rule behaves as intended for follow-up marketing messages.

Test with realistic but non-sensitive data. Keep separate staging and production sender identities where possible, and never leave a staging webhook attached to a public production experience.

Operational practices that protect deliverability

The integration is successful only when it supports useful, wanted messages over time. For immediate result delivery, send promptly while the visitor still remembers the assessment or calculation. For longer nurture journeys, use explicit consent and frequency controls rather than treating every lead as permission for unlimited mail.

Monitor three layers separately: Outgrow submissions, webhook acceptance, and Volanea delivery. A drop between submissions and webhook acceptance suggests a configuration or endpoint issue. A drop between webhook acceptance and provider acceptance suggests application or credential trouble. Bounces, complaints, or low engagement after provider acceptance are a list-quality, authentication, relevance, or recipient-side issue.

Validate addresses at the point of capture where appropriate, but do not rely on a syntax check alone. A syntactically valid address can still be undeliverable, disposable, or mistyped. For one-off checks during QA or lead-review workflows, the email address verification tool can help identify obvious risk before a manual follow-up.

Conclusion

To send email from Outgrow with Volanea, use the Outgrow new-lead webhook as the trigger and a private middleware endpoint as the decision point. Map the verified lead payload into Volanea’s recipient and content fields, keep the API key exclusively in server-side secrets, and record the Outgrow lead ID to make retries safe.

That structure gives you more than an automated confirmation email. It creates a maintainable system for result-specific follow-up, consent-aware marketing, reliable debugging, and deliverability-aware sending—without exposing credentials or depending on a nonexistent native plugin.

FAQ

Can Outgrow send directly to Volanea without middleware?

Not safely for a personalized REST email workflow. Outgrow sends lead data, while Volanea needs an authenticated email-send request with mapped fields. Use a server-side webhook endpoint or an automation layer such as Zapier or Make to transform the data and keep the API key private.

What Outgrow event should trigger the email?

Use the new lead submission event from the relevant Outgrow experience. This fires after a visitor submits the lead form, which is the point at which you have an email address and any configured lead information.

Where should the Volanea API key be stored?

Store it only in an encrypted server-side environment variable, secret manager, or private automation-platform credential. Do not put it in Outgrow fields, a webhook query parameter, public JavaScript, or browser configuration.

How do I stop duplicate emails when Outgrow retries a webhook?

Use the Outgrow lead ID as a durable idempotency key. Create a database or key-value record with a uniqueness guarantee before or during processing so the same lead event cannot trigger another send.

Why is my Outgrow field missing in the email?

The field may be optional, renamed, unavailable for that content type, or located differently in the webhook payload than your code expects. Submit a fresh test lead, inspect the received JSON, and update the mapping with a fallback for absent optional values.