Send transactional email from Zapier without relying on Zapier’s limited built-in sender: use a Webhooks by Zapier action to call Volanea’s REST API directly. This guide shows the honest integration pattern, the JSON Zapier sends to Volanea, and how to test, secure, and operate it in production.

The important distinction: this is not a native Zapier app integration

Volanea does not currently provide a native Zapier app that you install, connect, and select as a standard Zap action. There is no Volanea action named Send Email inside Zapier, and there is no special Volanea connection screen to authorize.

The practical alternative is still straightforward. A Zap begins with an event from the app you already use—such as a new form submission, payment, CRM record, support ticket, or database row—then a Webhooks by Zapier action sends an HTTP POST request to Volanea’s email API. Volanea receives that request and queues the transactional email.

That distinction matters because it changes where each responsibility lives:

  • Zapier detects the business event and maps data from earlier steps.
  • Webhooks by Zapier serializes that mapped data into an HTTP request.
  • Volanea authenticates the request, applies sending-domain and suppression checks, renders or accepts the message content, and dispatches the email.
  • Your team defines what counts as a transactional event, which recipient receives it, and how duplicate sends are prevented.

The result is not a workaround that pretends to be a native integration. It is a standard API-to-API automation: transparent, portable, and useful whenever an application can trigger a Zap.

What Email by Zapier does—and does not—send

The phrase “Send Email From Zapier” can refer to Email by Zapier, Zapier’s own email tool. It can send messages on Zapier’s behalf, but it is not a webhook source that emits one fixed outbound email payload for another provider to consume.

In other words, there is no official Email by Zapier webhook body such as this:

{
  "to": "person@example.com",
  "subject": "Your receipt",
  "body": "Thanks for your order"
}

That example may look reasonable, but it would be invented if presented as an Email by Zapier payload. Email by Zapier performs its own send action. It does not hand off a universal message object to Volanea or another email API.

Email by Zapier also has product-specific constraints that make it a poor fit for many production transactional workflows. Zapier documents send limits for the tool, does not allow a customizable From address for Email by Zapier messages, and includes a required unsubscribe-style footer for compliance. Those behavior choices can be appropriate for internal alerts, but they are usually not suitable for password resets, receipts, account notices, or other messages that must come from your authenticated sending domain.

To send through Volanea instead, replace the Email by Zapier sending step with a Webhooks by Zapier step. Your trigger data becomes the source of the Volanea message fields.

The payload that actually matters

The exact input data available in a Zap depends on its trigger. A Typeform trigger, for example, exposes different fields from a Stripe payment, HubSpot contact, Shopify order, or custom Catch Hook.

The payload you control is the outbound request body constructed in Webhooks by Zapier. For a simple order-confirmation workflow, the request body sent to Volanea can look like this:

{
  "from": "notifications@updates.example.com",
  "fromName": "Acme Store",
  "to": ["customer@example.com"],
  "subject": "Your order #1042 is confirmed",
  "html": "<p>Hi Maya,</p><p>Thanks for your order. Your confirmation number is <strong>#1042</strong>.</p>",
  "text": "Hi Maya,\n\nThanks for your order. Your confirmation number is #1042."
}

This is the shape to design, test, and maintain. In the live Zap, static sample values are replaced by mapped values from the trigger, such as a customer email, first name, order number, and item list.

Before you build the Zap

A successful HTTP request is not the same thing as a deliverable email. Complete the email-infrastructure work before troubleshooting the automation itself.

First, create or select a Volanea project and generate a secret API key. Volanea API requests authenticate with the Authorization: Bearer <key> header, so treat the key like a password that can send mail from your account. Do not put it into browser JavaScript, a public form, a public repository, or a client-side mobile application.

Second, verify the sending domain you plan to use. The from address in the request needs to belong to a verified domain unless you are using test mode. Use a specific transactional subdomain when that fits your sending model—for example, updates.example.com or notify.example.com—rather than mixing receipts and password resets with every other mail stream by default.

Third, choose a sender identity that recipients recognize. notifications@updates.example.com can work well for system notices, while support@example.com may be better if you expect replies. If replies should go elsewhere, use the API’s replyTo field rather than asking recipients to reply to an unmonitored mailbox.

Finally, decide whether the workflow is truly transactional. A confirmation requested by a customer, a password reset, a service interruption notice, and an invoice are transactional. A weekly product announcement or a promotional discount is not simply made transactional because it was triggered in Zapier. Separating the two helps preserve both user expectations and sending reputation.

For the endpoint, authentication model, send fields, templates, and event behavior, keep the email API reference and setup guides nearby as you configure the workflow.

The architecture: Zap trigger to Volanea API

A reliable implementation has a simple request path:

Business event in an app
        ↓
Zap trigger
        ↓
Optional Filter / Formatter / lookup steps
        ↓
Webhooks by Zapier: POST request
        ↓
POST https://api.volanea.com/v1/send
        ↓
Volanea validates and dispatches the message

The optional steps are often where the quality of the automation is decided. A Filter can stop a send unless an order is paid, a contact has consent, a ticket priority is urgent, or a user’s email field exists. A Formatter can normalize a name, create a readable date, or calculate a value. A lookup step can retrieve a CRM field or template variable that was not present in the original trigger.

Do not treat the email step as a place to repair bad event data. If the trigger can produce an empty recipient, an unescaped HTML fragment, an unconfirmed order, or a duplicate event, address that before the request reaches the sending API.

A concrete example workflow

Suppose a payment platform creates a Zap whenever a payment succeeds. The trigger exposes fields such as:

{
  "payment_id": "pay_8pW7m",
  "customer_email": "maya@example.com",
  "customer_name": "Maya Chen",
  "invoice_number": "INV-1042",
  "amount": "49.00",
  "currency": "USD"
}

The Zap should not send this whole object to Volanea. It should map only the information needed to form an email. The outgoing send request might become:

{
  "from": "billing@example.com",
  "fromName": "Acme Billing",
  "to": ["maya@example.com"],
  "subject": "Receipt for invoice INV-1042",
  "html": "<p>Hi Maya Chen,</p><p>We received your payment of $49.00 USD for invoice <strong>INV-1042</strong>.</p>",
  "text": "Hi Maya Chen,\n\nWe received your payment of $49.00 USD for invoice INV-1042."
}

That narrower mapping is intentional. It avoids leaking unrelated payment data into email logs, makes the message easier to audit, and gives you a single predictable contract between Zapier and Volanea.

Configure Webhooks by Zapier to call Volanea

In the Zap editor, add an action after the trigger and any validation or formatting steps. Search for and select Webhooks by Zapier. Zapier provides POST, PUT, and GET options for common request formats, plus Custom Request for cases that need a fully specified request body or custom headers.

For this use case, select Custom Request. It is the clearest option because the Volanea send request needs a JSON body and authorization header, and the recipient field is an array even when you are sending one message to one person.

Configure the action as follows:

  1. Set the request method to POST.
  2. Set the URL to https://api.volanea.com/v1/send.
  3. Set the payload type to JSON or use a raw JSON request body, depending on the Webhooks by Zapier configuration presented in your Zap.
  4. Add the Authorization header with the value Bearer YOUR_VOLANEA_SECRET_KEY.
  5. Add Content-Type: application/json if Zapier does not set it automatically for the selected JSON payload type.
  6. Add the request body shown below, replacing sample values with fields from earlier Zap steps.
  7. Test with a mailbox you control before publishing the Zap.

Copyable Custom Request body

The following JSON is a working Volanea message body. Use the mapped-data picker in Zapier to insert values from your trigger where this example shows placeholders.

{
  "from": "notifications@updates.example.com",
  "fromName": "Acme",
  "to": ["{{customer_email}}"],
  "subject": "Welcome, {{first_name}}",
  "html": "<p>Hi {{first_name}},</p><p>Your account is ready.</p>",
  "text": "Hi {{first_name}},\n\nYour account is ready."
}

The placeholders above are explanatory. Do not type literal double-brace tokens unless your Zap step actually supplies them that way. In Zapier, insert the available data token for the recipient email or name from the prior step.

A production request also needs headers:

Authorization: Bearer sk_your_secret_key
Content-Type: application/json

The API key must remain a secret. Zapier stores action configuration inside the Zap, so restrict Zap editing access to people who should be able to send email and view configured credentials. If your organization needs tighter separation, use the proxy pattern later in this guide.

Why Custom Request is useful here

Zapier’s standard POST action is convenient for simple flat form-style or JSON data. Custom Request is the better fit when you need a nested JSON array, empty fields handled deliberately, or customized headers. The to value in the Volanea request is an array, which is a common reason to choose Custom Request rather than trying to force a structured value through a flat key-value form.

It also makes debugging easier. You can compare the final JSON shown in Zapier’s test result with the payload documented in Volanea’s API reference. If the request fails, you have one explicit body and one explicit header set to inspect.

A complete API request outside Zapier

Before introducing Zapier variables, verify your sender, API key, and request shape with a direct request. This isolates email setup from automation setup.

curl --request POST "https://api.volanea.com/v1/send" \
  --header "Authorization: Bearer $VOLANEA_API_KEY" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: receipt-pay_8pW7m" \
  --data '{
    "from": "billing@example.com",
    "fromName": "Acme Billing",
    "to": ["maya@example.com"],
    "subject": "Receipt for invoice INV-1042",
    "html": "<p>Hi Maya,</p><p>We received your payment of <strong>$49.00 USD</strong>.</p>",
    "text": "Hi Maya,\n\nWe received your payment of $49.00 USD."
  }'

The POST /v1/send endpoint can send one message to one address or up to 50 addresses in a send request. For most Zap-triggered transactional messages, use a one-recipient to array. It keeps the event-to-message relationship clear and avoids accidentally exposing one recipient’s address to another recipient.

The html field contains the rich version of the message, while text provides a readable fallback for text-only clients and recipients who prefer plain email. Include both. A bare HTML-only send may appear acceptable in a quick test, but a text part improves accessibility, resilience, and the utility of the message when HTML is disabled.

Prevent duplicate transactional emails

Automations are usually at-least-once systems, not exactly-once systems. A source app can resend an event, a Zap can be replayed after a transient problem, or a human can rerun a task while investigating a failure. If every repeat creates a new email, customers receive duplicate receipts, alerts, or reset notices.

Volanea supports safe retries using the Idempotency-Key header. Give every logically unique email a stable key derived from the business event—not from the current time.

For the payment example, a good idempotency key is:

receipt-pay_8pW7m

For an account verification flow, it might be:

verify-user_12345-verification_67890

For a support-ticket notification, it might be:

urgent-ticket_5541-status_open

A poor idempotency key includes a timestamp generated on every Zap run, because each retry becomes a different key and defeats deduplication. A poor key also uses only the customer email, because one customer may legitimately receive multiple receipts or multiple alerts.

Add the idempotency header in the Zap

In the Webhooks by Zapier headers configuration, add:

Idempotency-Key: receipt-{{payment_id}}

Again, use the actual mapped payment ID token available in your Zap rather than typing the illustrative placeholder literally. The key must be deterministic: the same original payment event should create the same key whenever the automation retries it.

If the source system has a globally unique event ID, use that. If it only has an object ID and an event type, combine them. For example, invoice-paid-INV-1042 is more expressive and safer than just INV-1042 if the same invoice can trigger several distinct message types across its lifecycle.

Make dynamic email content safe and useful

The most common Zapier email mistake is not an API failure. It is inserting raw source data into a message without deciding how it should be formatted, escaped, or constrained.

A customer name is usually low risk, but an open-ended support ticket description, form answer, or internal note can contain quotation marks, angle brackets, line breaks, pasted HTML, or sensitive information. When such values are inserted into an HTML email, they can break markup or display unintended content.

Use a deliberate content strategy

Choose one of these approaches for each workflow:

  • Short fixed copy with mapped values: Best for receipts, status changes, login alerts, and confirmations. Map only values such as first name, order number, date, and amount.
  • A reusable Volanea template: Best when the layout is shared across many workflows or needs to be updated without editing each Zap. The API can send using a templateId instead of carrying full markup in every request.
  • A server-side renderer or proxy: Best when dynamic content is complex, must be sanitized, contains loops such as order items, or requires authorization checks before sending.

For a basic confirmation, writing HTML in the Zap is reasonable. Keep it compact, use simple table-free markup unless you need more elaborate email-client support, and maintain a matching text version. For a branded receipt or a message with product-line items, tax calculations, translations, or personalized recommendations, a template or small application endpoint is usually easier to maintain.

Avoid putting secrets or private data into email content

Do not send API tokens, complete payment details, raw form submissions containing sensitive data, or internal notes that a customer should not see. Email is not a private database transport. It can be forwarded, indexed, retained by mailbox providers, or read from a device that is no longer under the recipient’s control.

For account actions, prefer a short-lived secure link to an authenticated page over including sensitive information in the body. For invoices and records, include an identifier and a secure destination where the recipient can retrieve details after authentication.

When to use a secure proxy instead of direct Zapier-to-Volanea sending

The direct Webhooks by Zapier approach is excellent for many small and medium-complexity workflows. It has one trade-off: the Volanea secret key is configured in the Zap action. That is manageable when Zap access is appropriately restricted, but it may not meet every team’s security or engineering requirements.

A proxy changes the flow:

Zapier → your protected webhook endpoint → Volanea API

Your endpoint stores the Volanea secret key in an environment variable or secret manager. Zapier authenticates to your endpoint with a separate shared secret or signed verification mechanism. The endpoint validates the inbound payload, builds the Volanea message, sets idempotency, and calls POST /v1/send.

Here is a minimal Node.js-style handler that demonstrates the transformation:

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

  if (request.headers.get("x-zapier-secret") !== process.env.ZAPIER_SHARED_SECRET) {
    return new Response("Unauthorized", { status: 401 });
  }

  if (!event.customer_email || !event.payment_id) {
    return new Response("Missing required event data", { status: 400 });
  }

  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": `receipt-${event.payment_id}`
    },
    body: JSON.stringify({
      from: "billing@example.com",
      fromName: "Acme Billing",
      to: [event.customer_email],
      subject: `Receipt for invoice ${event.invoice_number}`,
      html: `<p>Hi ${escapeHtml(event.customer_name || "there")},</p><p>We received your payment of <strong>${escapeHtml(event.amount)} ${escapeHtml(event.currency)}</strong> for invoice ${escapeHtml(event.invoice_number)}.</p>`,
      text: `Hi ${event.customer_name || "there"},\n\nWe received your payment of ${event.amount} ${event.currency} for invoice ${event.invoice_number}.`
    })
  });

  return new Response(await response.text(), {
    status: response.status,
    headers: { "Content-Type": "application/json" }
  });
}

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

The proxy is not required just because you use Zapier. Use it when you need stronger credential isolation, server-side validation, complicated templating, HTML escaping, recipient authorization, centralized audit records, or integration tests under version control.

Test the complete workflow before publishing

A single test proves less than most teams assume. Test the request path, the rendered message, and the delivery path separately.

Start with a recipient mailbox you control. Confirm that the API accepts the request and that the email appears with the expected From address, subject, HTML, and text fallback. Check the received message in both desktop and mobile mail clients if the format matters.

Then test unhappy paths intentionally:

  1. Send an event with a missing email field and verify a Filter or validation step stops it.
  2. Send an event with an invalid address and verify the Zap does not silently mark the workflow as business-successful.
  3. Replay the exact same event and confirm the idempotency key prevents a second message.
  4. Send a name or field containing quotation marks and angle brackets to check whether the HTML remains intact.
  5. Test a recipient who is suppressed or unsubscribed where that should affect the message category.
  6. Confirm that the From domain is authenticated and that the final message headers align with your expected sender identity.

Zapier’s test data may not perfectly match a live trigger. After publishing, create one controlled real event and review the Zap history, the Volanea send record, and the inbox result together. This gives you a full trace from business event to recipient experience.

Troubleshooting common failures

The API returns an authentication error

Check that the request uses the correct format:

Authorization: Bearer sk_your_secret_key

Do not use an SMTP credential in place of an API key. Do not add extra quotation marks around the key. If you regenerated or rotated the key, update the configured Zap or, preferably, the secret held by your proxy.

The API accepts the request but the message does not arrive

An accepted send request is the beginning of delivery, not proof of inbox placement. Check the Volanea send status and event data for bounces, suppressions, complaints, or delivery outcomes. Then inspect the recipient’s spam folder and the message headers in a test inbox.

Also verify that the sender domain is authenticated and that the From address uses that domain. A mismatch between the planned sender identity and the verified domain is a common configuration issue.

Zapier reports invalid JSON

This often happens when dynamic data introduces unescaped quotation marks, line breaks, or HTML into a raw JSON body. For short static messages, use mapped fields only where values are simple. For richer content, use a Volanea template or a proxy that serializes JavaScript objects with JSON.stringify.

Do not manually concatenate untrusted source text into raw JSON. JSON serialization exists precisely to escape characters safely.

The same recipient receives two emails

First, determine whether two separate business events occurred. If not, inspect Zap task history for retries, replays, or duplicate source events. Add an Idempotency-Key based on the source event ID, then verify that every retry sends the same key.

If multiple distinct message types can be associated with one source object, include the message type in the key. For example, order-1042-confirmation and order-1042-shipped should not conflict.

The email comes from the wrong identity

Do not use Email by Zapier when the requirement is to send from your own authenticated domain. Use the Volanea REST request and set the appropriate from and optional fromName fields. Make sure that address belongs to the verified sending domain configured in Volanea.

Operating the workflow as it grows

Once a Zap is sending production email, treat it as part of your application infrastructure rather than a one-off no-code experiment. Name the Zap for the business event and message type, record the owner, and document the event ID used for idempotency.

Use separate workflows or clearly separated branches for materially different message classes. A receipt, a password reset, and a marketing nurture email have different content rules, urgency, consent implications, and failure consequences. Combining them into one sprawling Zap makes it hard to reason about behavior during an incident.

Review volume and cost as the workflow scales. An automation that works well for ten manual orders per day may need a different design at thousands of events per hour, particularly if it includes lookup steps, per-recipient branching, or complex dynamic content. Review transactional email sending costs and plan limits alongside your expected event volume before a launch rather than after an unexpected spike.

Finally, build an operational response for failures. Decide who receives alerts when the Zap errors, how a failed business event is replayed safely, and how the idempotency key prevents that replay from becoming a duplicate email. The technical request is only one part of a dependable transactional-email system.

Conclusion

To send transactional email from Zapier using Volanea, do not look for a native Volanea app or attempt to forward a fictional Email by Zapier payload. Start with the event that matters, map its fields in a Zap, and use Webhooks by Zapier to send a JSON POST request to https://api.volanea.com/v1/send.

Keep the request narrow, authenticate it with a Volanea API key, use a verified From domain, include HTML and text content, and add an idempotency key based on the original event. For more complex workflows, put a small protected proxy between Zapier and Volanea so secrets, validation, rendering, and audit logic remain under your control.

FAQ

Can I install a Volanea app in Zapier?

No. Volanea does not currently have a native Zapier app installation flow. Use Webhooks by Zapier to call Volanea’s REST API, or send the Zap data to your own endpoint that calls the API.

Does Email by Zapier send a webhook payload to Volanea?

No. Email by Zapier sends email through Zapier’s own email tool; it does not emit a universal outgoing email JSON payload for Volanea. The request body is built in your Webhooks by Zapier action from data produced by the Zap trigger.

What Volanea endpoint should Zapier call?

Use POST https://api.volanea.com/v1/send for a transactional send. Authenticate the request with Authorization: Bearer <your-secret-key> and send a JSON message body.

Should the Volanea API key live directly in Zapier?

It can for a restricted, simple workflow, but a proxy is safer when you need stronger secret isolation, server-side validation, complex content rendering, or centralized logging. Never expose the key in front-end code or public webhook URLs.

How do I stop Zapier retries from sending duplicate email?

Send a stable Idempotency-Key header derived from the source event, such as a payment, order, or ticket event ID. Do not generate a new time-based key for each retry.