How to Send Email from Outfunnel with Volanea

Send email from Outfunnel by treating Outfunnel as the lead-routing layer it is, then handing the resulting CRM event to middleware that can securely call Volanea’s email API. This is a reliable way to send a welcome, consultation confirmation, lead follow-up, or internal notification after an Outfunnel-connected form submission.

The important limitation: Outfunnel does not send arbitrary outbound HTTP requests

There is no native Volanea app, marketplace listing, or one-click Outfunnel action for sending email through Volanea. More importantly, Outfunnel’s documented App Connector model is built around connecting supported source apps, CRMs, databases, forms, and marketing platforms; its documented webhook-form feature is an inbound endpoint that receives a form tool’s POST and records that submission in a destination CRM. It is not a generic outbound webhook or HTTP-request action that can call POST https://api.volanea.com/v1/send directly. (support.outfunnel.com)

That distinction determines the correct architecture. Do not look for a place in Outfunnel to paste a Volanea endpoint, request headers, or an API key. Such a direct configuration would be unsafe even if it existed, because a long-lived sending key should be held in a server-side secret store rather than inside browser-visible code or a form configuration.

The practical route is:

1. A form, lead source, or connected app produces a submission.
2. Outfunnel records that submission in your CRM as a contact, lead, activity, deal, note, or field update, depending on the connection and CRM.
3. Middleware such as Make, Zapier, or a small server-side webhook receiver observes the CRM event.
4. The middleware maps approved CRM data into a Volanea transactional email request.
5. Volanea sends the message using a verified sender domain and an idempotency key.

For the examples below, the concrete Outfunnel trigger is a form submission recorded in Pipedrive as a contact/person. Outfunnel’s form-to-CRM guides describe form submissions being recorded in a CRM and support additional actions such as activities, notes, leads, deals, and field updates for applicable CRM connections. (support.outfunnel.com)

The recommended Outfunnel-to-Volanea architecture

The most dependable implementation is not “Outfunnel calls Volanea.” It is:

Webflow, Wix, WordPress, LinkedIn Lead Gen Form, or webhook-compatible form
        ↓ form submission
Outfunnel App Connector
        ↓ create or update CRM contact and selected CRM fields
Pipedrive, HubSpot, Attio, Copper, or Salesforce
        ↓ new-record event, CRM workflow, or webhook
Make, Zapier, or your server-side webhook receiver
        ↓ POST /v1/send
Volanea
        ↓
Recipient inbox and delivery events

This design keeps responsibilities clean. Outfunnel handles lead capture, field mapping, source attribution, and CRM updates. Your CRM becomes the durable business record and the point where a send decision can be audited. Middleware handles conditional logic and authentication. Volanea handles transactional dispatch, suppression checks, contact upsert behavior, rendering, tracking instrumentation, and delivery.

A CRM handoff is also safer than triggering straight from the public form. Before sending, you can inspect the contact’s lifecycle stage, opt-in status, lead source, owner, duplicate status, and any enrichment or qualification fields your sales process requires. That extra decision point matters when a form submission alone is not enough permission to send a particular type of email.

The real Outfunnel trigger: a form submission becomes a CRM record

For this integration, the event that starts the flow is a new form submission handled by Outfunnel and recorded in your CRM.

For example, connect Webflow Forms to Pipedrive in Outfunnel’s App Connector. During setup, you select the source form, map its fields, define how submissions should be recorded, activate the connection, and submit a test lead. Outfunnel’s guidance says Webflow form submissions can be used to add leads to a CRM, map custom fields, and create CRM actions such as an activity, note, lead, deal, or field update where supported. (support.outfunnel.com)

For a simple welcome flow, configure these fields before creating the connection:

• email → Pipedrive person email
• first_name → Pipedrive person name or a dedicated first-name custom field
• last_name → Pipedrive person name or a dedicated last-name custom field
• form_name → a CRM custom field such as outfunnel_form_name
• lead_source → a CRM custom field such as lead_source
• email_opt_in → a CRM custom field such as transactional_email_allowed
• submission_id → a CRM custom field such as outfunnel_submission_id

The submission_id field is especially useful. If the form provider supplies a stable response or submission identifier, carry it through to the CRM. A stable source ID lets middleware create a durable idempotency key for the send. If the provider does not supply one, use the CRM record ID plus a deliberate event name, rather than the current timestamp.

What Outfunnel actually receives for webhook forms

Outfunnel documents its Webhook Forms connection as receiving a POST from the source form tool to a unique Outfunnel webhook URL. It currently requires a flat JSON object, not nested objects. Its documented example looks like this:

{
  "email": "jane@example.com",
  "first_name": "Jane"
}

That is the payload shape sent to Outfunnel by your form tool. It is not an outbound Outfunnel payload, and it is not a payload that Outfunnel forwards directly to Volanea. Nested input such as {"contact":{"email":"jane@example.com"}} is not supported for this webhook-form connection. (support.outfunnel.com)

This is why field naming should be decided early. Use simple, flat field names that are easy to map through Outfunnel and easy to identify later in your CRM. For example:

{
  "email": "jane@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "form_name": "request-demo",
  "lead_source": "webflow",
  "email_opt_in": true,
  "submission_id": "wf_01JQ9S8R9H8M4N5P6Q7R"
}

Do not assume every connected form source provides every property. A Webflow form may not have an external submission ID matching a LinkedIn lead form’s identifier. Build your middleware so it can reject or route incomplete records safely instead of manufacturing recipient addresses or guessing consent.

Build the CRM handoff before building the email

The CRM record should contain enough data to answer one question: should this business event send this specific email exactly once?

For a consultation-request confirmation, create a predictable set of fields in the CRM before configuring your Outfunnel mapping:

Use an explicit sent-state field, such as volanea_welcome_sent_at, instead of relying only on the middleware execution history. Middleware histories can be retained for a limited period, scenarios can be duplicated, and a teammate can rebuild the automation later. A field on the CRM record makes the send state visible to sales, operations, and support.

The basic logic should be:

1. A form submission is recorded by Outfunnel in the CRM.
2. Middleware receives the resulting contact or person event.
3. Middleware verifies that the email address exists and the record matches the intended form or source.
4. Middleware checks that volanea_welcome_sent_at is blank.
5. Middleware sends through Volanea with a stable idempotency key.
6. Middleware writes the send timestamp and, ideally, Volanea’s message ID back to the CRM.

The last step is not cosmetic. It makes support investigations faster. If a prospect says they did not receive the message, you can search the CRM record, find the Volanea message ID, then inspect sending and delivery status without reconstructing the workflow from logs.

Option A: Use Make as the middleware route

Make is a good fit when the email logic is straightforward and your CRM can be watched for newly created or changed contacts. In Make, a scenario begins with a trigger module that returns data bundles, then passes those bundles to subsequent modules for mapping and actions. A polling trigger commonly has a name beginning with “Watch”; its interval is configured in the scenario schedule. (help.make.com)

For an Outfunnel-to-Pipedrive implementation, configure a scenario around this sequence:

1. CRM trigger: Watch for the newly created Pipedrive person/contact produced by the Outfunnel form connection, or receive a CRM webhook through Make where your CRM connection supports one.
2. Filter: Continue only when the person has an email, the intended form_name, the correct opt-in or eligibility value, and an empty volanea_welcome_sent_at field.
3. Optional lookup: Fetch the complete CRM record if the trigger event does not include every mapped custom field you need.
4. HTTP request: Send the mapped email to Volanea.
5. CRM update: Set volanea_welcome_sent_at, volanea_message_id, and optionally volanea_send_status.

Pipedrive supports webhooks for object events, including person events. Its webhook API documentation describes object/action combinations such as create, change, and delete, and identifies person as one of the supported event object types. (developers.pipedrive.com)

Where the Volanea key belongs in Make

The Volanea secret key belongs in a protected Make connection or encrypted secret/credential facility available to the server-side scenario—not in a Webflow page, a front-end JavaScript variable, a form hidden field, an Outfunnel custom field, or an email template variable.

Use the key only in the authorization header of the server-side HTTP request:

Authorization: Bearer sk_...

If your Make HTTP configuration does not offer a credential vault appropriate for your organization, place a small server-side relay between Make and Volanea. Make can call your relay with an application-specific shared secret or signed request, and the relay can read VOLANEA_API_KEY from its deployment environment. This gives you better secret rotation, request validation, structured logging, and allow-listing than spreading the Volanea key across no-code scenarios.

There is no “Outfunnel-side” place to store the Volanea key in this integration because Outfunnel is not the component making the API request. That is a feature of the architecture, not a missing setup step.

The Volanea REST request and complete field mapping

Volanea sends a single message with POST /v1/send. The endpoint uses a secret key through Bearer authentication and supports an Idempotency-Key header for retry-safe sending. It accepts a verified sender, recipient, subject, plain-text body, and HTML body. (volanea.com)

The following server-side JavaScript is a working relay example. It accepts a normalized CRM handoff body from Make, validates the fields needed for a welcome email, maps them to a Volanea send request, and uses a stable idempotency key.

// Node.js 18+ example.
// Store VOLANEA_API_KEY and OUTFUNNEL_RELAY_TOKEN as server-side secrets.

import crypto from "node:crypto";

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

export async function sendOutfunnelWelcome(req, res) {
  if (req.headers.authorization !== `Bearer ${process.env.OUTFUNNEL_RELAY_TOKEN}`) {
    return res.status(401).json({ error: "unauthorized" });
  }

  // This is the normalized body Make sends after reading the CRM record.
  // It is deliberately flat and does not claim to be an outbound Outfunnel payload.
  const {
    crm_record_id,
    submission_id,
    email,
    first_name,
    form_name,
    email_opt_in,
    welcome_sent_at
  } = req.body;

  if (!email || !crm_record_id) {
    return res.status(422).json({ error: "email and crm_record_id are required" });
  }

  if (form_name !== "request-demo") {
    return res.status(204).end();
  }

  if (email_opt_in !== true || welcome_sent_at) {
    return res.status(204).end();
  }

  const safeName = escapeHtml(first_name || "there");
  const logicalEventId = submission_id || crm_record_id;
  const idempotencyKey = `outfunnel-request-demo:${logicalEventId}`;

  const volaneaPayload = {
    from: "hello@updates.example.com",
    to: email,
    subject: "Thanks for requesting a demo",
    text: `Hi ${first_name || "there"},\n\nThanks for your demo request. Our team will be in touch shortly.\n\n— Example Team`,
    html: `<p>Hi ${safeName},</p><p>Thanks for your demo request. Our team will be in touch shortly.</p><p>— Example Team</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",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify(volaneaPayload)
  });

  const result = await response.json();

  if (!response.ok) {
    return res.status(response.status).json({
      error: "volanea_send_failed",
      detail: result
    });
  }

  return res.status(200).json({
    crm_record_id,
    idempotency_key: idempotencyKey,
    volanea: result
  });
}

The mapping in that code is intentional:

• crm_record_id is required for traceability and as the fallback event identity.
• submission_id is preferred for idempotency because it represents the original form event.
• email becomes Volanea’s to recipient.
• first_name is used in both text and HTML content, with HTML escaping for the latter.
• form_name prevents a general “new contact” trigger from sending the demo email for every record.
• email_opt_in and welcome_sent_at are business safeguards, not API requirements.
• The Volanea from address must be on a verified sending domain you control.

For sender setup, domain verification, and the precise request/response reference, use the Volanea API setup documentation while configuring the relay.

Option B: Use Zapier as the middleware route

Zapier follows the same architectural principle: Outfunnel records the lead in the CRM, then Zapier reacts to the CRM record rather than to an imaginary Outfunnel webhook action.

A sensible Zap looks like this:

1. Trigger on the CRM event that indicates Outfunnel created or updated the relevant contact.
2. Add filters for form name, email presence, eligibility, and a blank send-state field.
3. Optionally use a formatter step to construct a deterministic idempotency key.
4. Use Webhooks by Zapier or a secure relay endpoint to make the Volanea call.
5. Update the CRM record with send state and message metadata.

For small workflows, Zapier can make the API call directly with an authorization header. For higher-value or higher-volume notification flows, a relay is usually better. It lets you authenticate Zapier to your endpoint separately from Volanea, ensure a single source of truth for message templates, log the resulting Volanea message ID, and rotate the Volanea key without editing several Zaps.

Do not put the key in a Zapier input field that business users may copy into documentation or share in screenshots. Treat transactional sending credentials as production secrets with access limited to the smallest possible group.

Use idempotency because the handoff is not exactly once

No-code scenarios, CRM webhooks, API gateways, and outbound HTTP clients can all retry. A timeout does not mean that the first request failed; it can mean the email request completed but the caller never received the response. Retrying a normal POST in that state can create duplicate customer emails.

Volanea supports Idempotency-Key on the send endpoint. Reuse the same key for the same logical email event. Do not generate a fresh random UUID on every attempt, because that tells the API each retry is a new email.

Good keys:

outfunnel-request-demo:wf_01JQ9S8R9H8M4N5P6Q7R
outfunnel-request-demo:pipedrive-person-4242

Bad keys:

welcome:jane@example.com
welcome:2026-10-10T12:30:00Z
crypto.randomUUID() // generated again on every retry

An email address is a poor standalone idempotency key because one recipient can legitimately request multiple demos or submit multiple forms. A timestamp is also poor because a retry at a different time creates a distinct key. The key should identify the event, not the delivery attempt.

Volanea documents that a key reused with a different body produces a conflict rather than silently treating two different messages as identical. Keep the request body deterministic for one idempotency key: same sender, recipient, subject, and content. (api.volanea.com)

When this breaks

This integration has several hops, and each one fails differently. Design the workflow so a failure is observable and recoverable rather than silently becoming an unsent or duplicate message.

Outfunnel retries or repeated CRM updates cause duplicate sends

A CRM record can be created once and updated later by mapping changes, source changes, enrichment, assignment rules, or a teammate. If your middleware listens to every contact update, it may send the welcome email repeatedly.

Use all three controls together:

1. Filter to the specific form or event marker stored by Outfunnel.
2. Check that volanea_welcome_sent_at is blank before sending.
3. Set a stable Idempotency-Key based on the submission ID or CRM record ID.

The CRM field stops ordinary repeat processing. The idempotency key protects the uncertain window where Volanea accepted the request but the middleware timed out before it could update the CRM. These controls solve different problems, so neither is a substitute for the other.

A webhook or HTTP call times out

If your CRM webhook, Make scenario, Zap, or relay times out, do not assume no email was sent. First inspect the relay logs or the Volanea response history using the idempotency key or returned message ID. Then retry with the same payload and same idempotency key.

Your relay should return quickly after Volanea responds. Avoid adding slow enrichment calls, large database scans, or third-party AI generation in the request path. If a workflow requires heavier work, queue it after validating and persisting the event; the queue worker can send with the same logical idempotency key.

Expected payload fields are missing

Outfunnel’s inbound Webhook Forms feature accepts flat JSON only. A field that exists in one form source may not exist in another, and new custom fields may need to be created in the destination CRM before they are available for mapping. Outfunnel’s setup guidance specifically advises creating missing destination fields and refreshing the field list. (support.outfunnel.com)

Treat missing fields differently based on their purpose:

• Missing email: stop the workflow and record an error; never send.
• Missing first_name: use a neutral greeting such as “Hello.”
• Missing submission_id: fall back to the CRM record ID, while recognizing that this identifies the CRM record rather than the original form response.
• Missing form_name: stop the workflow if form-specific routing is required.
• Missing opt-in or eligibility marker: route to review rather than sending by default.

Do not solve missing data by inserting placeholder email addresses or by turning every incoming CRM contact into a recipient.

The form is real-time, but other data is not

Outfunnel says form and meeting submissions sync in real time, while other sync behaviors can vary by app and field type, including polling intervals for some cases. (support.outfunnel.com)

That means a CRM record may appear before a nonessential enrichment field arrives. If your email requires that field, use a controlled delay, a wait/retry branch, or a CRM workflow that only marks the contact “ready to send” once all required data is present. Do not use arbitrary long delays as a substitute for a readiness condition; a field-based state is more reliable and easier to debug.

The send request is valid, but the email does not dispatch

A valid API call can still be suppressed or skipped due to recipient-level conditions such as unsubscribe status or suppression state. That is expected protection, not necessarily a transport failure. Volanea documents suppression checking as part of the send pipeline and provides suppression lookup endpoints when you need to investigate an address. (volanea.com)

In operational reporting, distinguish these outcomes:

• middleware never ran;
• middleware filtered the record deliberately;
• Volanea rejected the request as invalid;
• Volanea accepted the request but skipped the recipient due to suppression or unsubscribe state;
• Volanea queued or dispatched the message;
• the message later bounced, was delivered, or generated an engagement event.

Those categories prevent the common but unhelpful conclusion that every absent inbox message is an “Outfunnel problem.”

Deliverability and consent rules still apply

The integration path does not change the nature of the email. A receipt, password reset, demo-request confirmation, or meeting confirmation may be transactional. A promotional nurture email is marketing, even if it is triggered automatically after a form submission.

Before you activate the scenario, define the message category and the rule that permits it. A demo-request confirmation should be tightly related to the request. A marketing newsletter should use your normal subscription and unsubscribe process. If you add promotional material to a transactional email, review that decision with the team responsible for compliance and customer communications.

Also verify the sender domain before testing with real leads. Use a sender address on the domain configured in Volanea, keep the visible From name recognizable, provide a useful text alternative, and avoid putting raw CRM data into HTML without escaping it. The example relay escapes the name because a name field can contain characters that would otherwise alter the email markup.

For lead quality, validate addresses before entering an expensive or high-touch sales sequence. The email address verification tool can help screen obviously invalid addresses, but it should complement—not replace—your consent, suppression, and bounce-handling processes.

Testing checklist before activation

Test the full chain with a controlled internal address before sending to leads. Do not test only the Volanea request in isolation; most production failures occur in the mapping between the form, Outfunnel, CRM, and middleware.

• Submit the exact source form that should trigger the flow.
• Confirm Outfunnel records the submission in the expected CRM object.
• Confirm every mapped CRM field has the expected value.
• Confirm the middleware filter rejects records from unrelated forms.
• Confirm a valid record reaches the relay or Volanea endpoint.
• Confirm the sender address belongs to a verified Volanea domain.
• Confirm the email arrives with the expected subject, text body, HTML body, and personalization.
• Retry the same event deliberately and confirm only one logical email is created.
• Confirm the CRM receives the sent timestamp and Volanea message ID.
• Test a missing-email and missing-first-name case to ensure the fallback behavior is safe.

A useful final test is the “response lost” simulation: allow Volanea to accept a request, then intentionally prevent the middleware from completing its CRM update. Re-run the same workflow and verify that the same idempotency key prevents another logical send. This is the failure case that simple happy-path tests rarely expose.

Conclusion

To send email from Outfunnel with Volanea, use Outfunnel to capture and record the business event, then let a CRM-triggered middleware step make the authenticated email API request. That approach reflects how Outfunnel’s documented connectors work, avoids inventing an outbound webhook feature, and gives you a durable audit trail in the CRM.

The strongest version of the integration uses a flat, well-mapped form payload; a CRM field that identifies the originating form; a server-side Volanea key; a stable idempotency key; and a CRM write-back after the send. Build those controls first, then personalize the message. Reliable transactional email is less about the one HTTP request than about preserving the identity of the event across every system that touches it.

FAQ

Can Outfunnel call the Volanea API directly?

Not through a documented generic outbound HTTP or webhook action. Outfunnel’s documented webhook-form feature receives inbound POSTs from form tools and maps them into connected apps. Use a CRM-to-Make, CRM-to-Zapier, or CRM-to-server-side-relay handoff instead.

What Outfunnel event should trigger the email?

For this setup, the trigger is a form submission that Outfunnel records in your CRM as a contact/person or another selected CRM action. Middleware should then watch the resulting CRM event and filter it using fields such as form name and send state.

Where should I store the Volanea API key?

Store it in a server-side environment variable, a protected middleware credential store, or a dedicated relay. Do not place it in front-end JavaScript, a public form, a hidden field, an Outfunnel contact field, or any client-visible configuration.

How do I stop duplicate welcome emails?

Use a CRM field such as volanea_welcome_sent_at plus Volanea’s Idempotency-Key header. Base the idempotency key on a stable form submission ID when available, or on the CRM record ID plus the logical event name.

What if Outfunnel does not map a field I need?

Create the destination custom field in the CRM first, refresh the field list in Outfunnel, remap the form field, and submit a new test record. If the source is a webhook form, keep the incoming data as a flat JSON object rather than nested JSON.