Send email from Make without a native app by connecting a Make scenario to Volanea’s REST API. The practical pattern is simple: Make receives an event through a trigger module, maps its fields into a JSON message, and posts that message to Volanea over HTTPS.

There is no Volanea app to install from the Make marketplace, and this guide does not pretend otherwise. Instead, it uses capabilities Make actually provides: the Webhooks > Custom webhook trigger to start a scenario and the HTTP > Make a request module to call an external API. That keeps the integration explicit, portable, and easy to audit.

What the Make and Volanea integration looks like

A Make automation is called a scenario. A scenario begins with a trigger module, processes one or more bundles of data, and then runs action modules in sequence. For this integration, the trigger is Webhooks > Custom webhook: an instant trigger that receives a POST request from your form, application, database automation, or another service.

The next module is HTTP > Make a request. It sends a POST request to Volanea’s transactional send endpoint:

POST https://api.volanea.com/v1/send

The full path is:

A customer submits a form, creates an order, changes a CRM record, or completes another business event.
Your source sends structured JSON to the Make Custom webhook URL.
Make creates a bundle from that webhook payload and starts the scenario.
The HTTP module maps bundle fields into Volanea’s send payload.
Volanea accepts the email request, applies sending-domain and suppression checks, then queues the message for delivery.
Make records whether the HTTP request succeeded, failed, or needs attention.

This is a good fit for transactional messages whose content depends on a workflow event: order confirmations, demo requests, account invitations, payment receipts, support acknowledgments, internal alerts, and status updates.

The important distinction is that Make coordinates the event, while Volanea is the email delivery layer. Make should decide when to send. Volanea should handle how the message is authenticated, accepted, queued, and delivered.

The concrete Make trigger: Webhooks > Custom webhook

Start the scenario with Webhooks > Custom webhook. In Make, webhooks are instant triggers: receiving a request at the webhook URL begins the scenario rather than waiting for a scheduled polling interval.

Create a new scenario, add the Webhooks app, and choose Custom webhook. Make generates a unique HTTPS endpoint. Give the webhook a descriptive name such as new-order-receipt or form-submission-confirmation, then copy its URL into the system that produces the event.

For this guide, assume a form backend posts the following payload after a customer requests a product demo:

{
  "event_id": "demo_01JQ4W2FQG9YB7M0A7P1",
  "event_type": "demo_requested",
  "submitted_at": "2026-09-22T15:42:18Z",
  "lead": {
    "email": "maya@example.com",
    "first_name": "Maya",
    "company": "Northstar Labs"
  },
  "request": {
    "product": "Workflow Analytics",
    "team_size": "25-50"
  }
}

That is the inbound payload, not the email API payload. The webhook receives it, and Make exposes the fields for mapping in later modules. In this example, the fields that matter most are:

event_id, which becomes the stable identity for the logical send.
lead.email, which becomes the recipient address.
lead.first_name, lead.company, and request.product, which personalize the message.
event_type, which can support a filter so unrelated webhook events do not send the wrong email.

Run the webhook once with a realistic test payload before configuring the HTTP module. Make needs to observe a sample request to determine the payload structure and make its fields available for mapping. This is also when you discover whether your source actually sends the expected nesting, casing, and data types.

Why a Custom webhook is a useful baseline

A native connector trigger can also start a Make scenario when the source application offers one. For example, a CRM may expose a “watch record” module or an instant trigger for a lifecycle change. But those labels and available fields differ by connector.

A Custom webhook provides a stable, source-neutral starting point. Your application controls the event payload, the event ID, and the moment at which Make receives it. That is especially valuable for important email events because you do not need to depend on a connector’s limited field set, polling delay, or plan-specific trigger behavior.

If you already use a supported application trigger, the sending half of this guide remains the same. Replace the webhook fields with that trigger’s mapped fields, but keep the Volanea request body and idempotency strategy.

Prerequisites before you send an email

Do not build the scenario first and assume the sender will work later. A transactional email request depends on a few pieces being ready before Make makes its first API call.

1. Verify the sender domain in Volanea

Your from address must use a domain that you have verified for sending in Volanea. Domain authentication is not cosmetic. It establishes the identity used to send mail and is part of the foundation for inbox placement and spoofing protection.

Use an address you control, such as hello@yourdomain.com or receipts@yourdomain.com, rather than a free mailbox domain. Keep the sender consistent for the message category. For instance, receipts should come from a receipts or billing sender, while product notifications may use a product or updates sender.

2. Create a Volanea secret API key

Volanea’s REST API uses a secret key, commonly beginning with sk_ or sk_test_. The HTTP request authenticates with that key in an Authorization: Bearer ... header.

Treat the key as a credential with permission to send email for the Volanea project. It is not a browser token, a public form value, or a value that belongs in JavaScript delivered to a visitor.

3. Decide what makes one send unique

Email APIs receive requests over networks that can time out or be retried. A send may be accepted by Volanea even when Make does not receive the response quickly enough to know that it was accepted.

For that reason, select a stable business-event ID before you configure the scenario. In this guide, demo_01JQ4W2FQG9YB7M0A7P1 is the event identity. Every retry of this same demo-request confirmation must reuse the same idempotency value rather than create a new one.

4. Prepare a test inbox

Use an inbox you can inspect during setup. Test the API request, the recipient mapping, the display name, subject, plain-text fallback, links, and message rendering before activating the scenario for production events.

For the broader endpoint reference, request options, and setup material, see the Volanea API documentation.

Configure HTTP > Make a request to call Volanea

After the Custom webhook module, add the HTTP > Make a request module. This is the outbound HTTP capability that replaces a native Volanea Make app.

Configure the request with the following values:

HTTP setting	Value
URL	`https://api.volanea.com/v1/send`
Method	`POST`
Body type	JSON / application JSON
Header	`Authorization: Bearer YOUR_VOLANEA_SECRET_KEY`
Header	`Content-Type: application/json`
Header	`Idempotency-Key: make-demo-{{1.event_id}}`

The exact numbered token shown in the idempotency header assumes the webhook is module 1 in the scenario. In Make, map the actual event_id output from your Custom webhook module. The result should be a deterministic value such as:

make-demo-demo_01JQ4W2FQG9YB7M0A7P1

Do not use the current timestamp as the idempotency key. Do not generate a new random UUID inside a retry path. Both choices cause the same underlying business event to look like a brand-new email request on every rerun.

The working request body and field mapping

Set the HTTP request body to JSON and map the webhook fields into the Volanea payload as shown below. This is the concrete message Make sends to Volanea after it replaces the {{...}} mapping expressions with values from the webhook bundle.

{
  "from": "Northstar Labs <hello@yourdomain.com>",
  "to": "{{1.lead.email}}",
  "subject": "Thanks for your interest in {{1.request.product}}",
  "html": "<p>Hi {{1.lead.first_name}},</p><p>Thanks for asking about <strong>{{1.request.product}}</strong>. Our team will follow up with {{1.lead.company}} shortly.</p><p>— Northstar Labs</p>",
  "text": "Hi {{1.lead.first_name}},\n\nThanks for asking about {{1.request.product}}. Our team will follow up with {{1.lead.company}} shortly.\n\n— Northstar Labs"
}

When Make processes the sample event, the outgoing JSON becomes:

{
  "from": "Northstar Labs <hello@yourdomain.com>",
  "to": "maya@example.com",
  "subject": "Thanks for your interest in Workflow Analytics",
  "html": "<p>Hi Maya,</p><p>Thanks for asking about <strong>Workflow Analytics</strong>. Our team will follow up with Northstar Labs shortly.</p><p>— Northstar Labs</p>",
  "text": "Hi Maya,\n\nThanks for asking about Workflow Analytics. Our team will follow up with Northstar Labs shortly.\n\n— Northstar Labs"
}

Volanea’s single-message endpoint is POST /v1/send. It accepts one recipient or up to 50 recipients in a request, and supports an Idempotency-Key header for retry-safe sends. For a workflow confirmation that belongs to one person, use one recipient and one event-specific idempotency key.

Why include both HTML and text

HTML is usually where branding, hierarchy, buttons, and layout live. Plain text is still important because it gives recipients and mail clients a useful fallback when HTML is disabled, simplified, or rendered poorly.

Keep the text version genuinely readable. Do not paste HTML markup into it. A concise text message also makes it easier to inspect the actual meaning of the email during QA.

Filter before the HTTP module

Add a filter between the webhook and the HTTP request when the same webhook receives more than one event type. A simple rule such as event_type equals demo_requested prevents an unrelated event from becoming a demo confirmation.

Filters are a safety boundary, not just a convenience. Without one, a future payload change or a broad webhook endpoint can turn an internal update, failed form validation, or test event into customer-facing mail.

Keep the Volanea API key on the Make side only

In this setup, the Volanea secret key lives in the Authorization header configuration of the HTTP > Make a request module inside the Make scenario. It travels from Make to api.volanea.com over HTTPS as part of the server-side API call.

It must never be inserted into client-visible configuration. That includes browser JavaScript, a public form’s hidden input, a static-site environment value exposed at build time, a mobile application bundle, screenshots, shared scenario exports, or a webhook payload sent by an untrusted client.

A customer should be able to submit this to your Make webhook:

{
  "event_id": "demo_01JQ4W2FQG9YB7M0A7P1",
  "lead": {
    "email": "maya@example.com"
  }
}

They should never be able to submit this:

{
  "volanea_api_key": "sk_live_example_secret_key"
}

The first payload contains business data. The second contains an account-level sending credential. Those are fundamentally different classes of data.

Access controls matter inside Make too

Anyone who can edit the HTTP module can potentially change the recipient mapping, sender, destination URL, or credential-bearing header. Limit scenario editing rights to people who need them, review scenario changes, and rotate the Volanea key if it is exposed in a copied blueprint, an audit log, or an accidentally shared screen recording.

Use a separate test key and production key where your workflow design permits it. Test events should not share the same sending identity and operational consequences as live customer messages.

Also secure the inbound webhook. A Make Custom webhook can be protected with an API key, and your sending application should authenticate requests to the webhook rather than leave the endpoint open to arbitrary callers. Otherwise, a discovered webhook URL could be abused to create scenario executions or attempt email sends.

Make the email content safe to map

Mapping values from an event directly into an email is powerful, but it creates two responsibilities: validate recipient data and avoid treating arbitrary text as trusted HTML.

Validate the recipient before sending

At a minimum, require a non-empty recipient field and make sure the workflow is not using an internal placeholder such as unknown, n/a, or a bare first name in place of an email address. A filter can stop obvious bad values before they reach Volanea.

For higher-value sends, validate addresses before accepting them into the workflow. A lightweight email address verification tool can help catch obvious address-quality problems before a campaign or transactional path repeatedly sends to invalid data.

Do not mistake validation for consent. A syntactically valid address is not automatically an address that should receive marketing email. Transactional mail should be tied to the event that just happened; promotional content needs its own consent and unsubscribe design.

Escape user-supplied HTML values

The sample message maps first_name, company, and product into HTML. That is acceptable only when the values are controlled or sanitized. If a form lets someone submit <img> tags, HTML entities, or unexpected markup, placing the raw value inside the html field can break the message or create misleading content.

A safer pattern is to use a stored Volanea template for polished, repeatable email layouts and pass only the variables the template expects. Stored templates reduce the amount of HTML embedded in Make and make design changes easier to review. They do not eliminate the need to validate the values you pass into variables.

Keep email intent close to the triggering event

A good transactional email answers a clear question: what happened, what does the recipient need to know, and what should they do next? The demo-request confirmation in this guide confirms receipt and sets an expectation for follow-up.

Avoid turning one event into several loosely related emails. If a form submission should create a confirmation, an internal sales alert, and a CRM task, make those separate scenario branches with separately named idempotency keys. That gives each action an auditable purpose and prevents a retried internal alert from duplicating the customer confirmation.

Prevent duplicate sends when Make retries

The most important production detail in this integration is idempotency. Make scenarios can run again because a module fails, an incomplete execution is retried, a webhook sender retries after a timeout, or an operator replays a run while investigating an issue.

Without protection, one demo request can become two confirmation emails. The risk is highest when the HTTP request reached Volanea successfully but the response did not make it back to Make. From Make’s point of view, the request may look uncertain; from the recipient’s point of view, the email already arrived.

Use one idempotency key per business event

Create the Idempotency-Key from a stable ID produced before Make begins its outbound request. In the example:

make-demo-{{1.event_id}}

Every attempt to send the confirmation for demo_01JQ4W2FQG9YB7M0A7P1 must use exactly:

make-demo-demo_01JQ4W2FQG9YB7M0A7P1

A genuinely new demo request receives a new event ID and therefore a new idempotency key. The key identifies the email action, not the recipient. One person may legitimately submit two different requests and receive two distinct confirmations.

Do not derive it from mutable content

Avoid key formats based only on the email address, subject line, or current date. A recipient can have multiple valid sends, while a subject line can change during an edit. These values are not durable identities for the action.

The best source is an immutable ID from the application that owns the event: an order ID, form submission ID, ticket ID, invoice ID, or database record event ID. If your source does not create one, add it before posting to Make.

Treat scenario replay as a production action

Make’s execution history is valuable for debugging, but replaying a run can repeat effects. Before replaying a scenario that includes an email request, verify that the same idempotency key remains mapped. If you changed the payload materially, decide whether it represents a corrected resend or a new message.

For a corrected message that should send again, use a new business action ID deliberately and document why. Do not casually alter the body while reusing a key intended for the original message.

When this breaks: diagnose the Make-to-Volanea hop

Every workflow has failure modes. The useful question is not whether a failure can happen, but how you distinguish a source-data problem, a Make execution problem, and an email API problem without sending duplicates during troubleshooting.

Make retries and duplicate sends

Symptom: A recipient reports two confirmations, or you see multiple executions associated with one source event.

Likely cause: The webhook source retried its request, Make retried an incomplete execution, or an operator replayed a run. If each HTTP request used a new idempotency key, Volanea correctly sees them as separate sends.

Fix: Preserve the original event ID from the source and derive the Idempotency-Key from it. Inspect the scenario history to confirm that all attempts for the same business event used the same key. Do not solve this with a time-delay alone; delays reduce symptoms but do not establish exactly-once business intent.

Webhook timeouts and uncertain outcomes

Symptom: The sender of the webhook reports a timeout, while the Make scenario may still have started or the email may already have been accepted.

Likely cause: The upstream application expected a quick response, but Make queued or processed the event asynchronously, or the scenario took longer than the sender’s timeout window.

Fix: Design the source-to-Make webhook contract around an event ID and at-least-once delivery. If the sender retries, Make may receive the same event again; that is acceptable only when downstream sends are idempotent. Keep the scenario focused so the email request is not held behind slow enrichment, large file processing, or unrelated actions.

If the upstream system needs a synchronous, immediate business response, do not use an automation workflow as the only critical path. Send through application middleware first, then notify Make asynchronously for secondary workflow work.

Payload fields missing on some plans or triggers

Symptom: The scenario worked in testing but later sends messages with blank names, missing company values, or an empty recipient field.

Likely cause: The source application’s Make connector may expose different fields depending on its trigger type, subscription plan, object permissions, or API version. A polling trigger may also return a narrower record than an instant event. This is not a reason to guess values in the email body.

Fix: Inspect the actual bundle from a failing execution. Add filters that stop the send when required values such as email, event_id, or a needed order ID are blank. If the source connector cannot provide the necessary data reliably, add a lookup step using the source record ID, or switch to a Custom webhook payload that your application controls.

Build a fallback for optional fields. For example, if first_name is unavailable, use a neutral greeting such as “Hello” rather than rendering Hi , in customer mail.

HTTP 401 or 403 responses

Symptom: The HTTP module returns an authentication or authorization failure.

Likely cause: The Authorization header is missing, malformed, uses an old key, or the sender domain has not been verified for the Volanea project.

Fix: Confirm the header begins with Bearer followed by the current secret key, with no extra quote marks or whitespace copied from a password manager. Confirm the from address belongs to a verified sending domain. Rotate a compromised key rather than trying to keep using it.

HTTP 400 responses

Symptom: Volanea rejects the request as invalid.

Likely cause: A required field is missing, the recipient mapping is blank, the body is not valid JSON, or a mapping token was typed as literal text rather than selected from the Make output panel.

Fix: Compare the HTTP module’s input bundle with the final request body. Test the payload with known static values first, then restore one mapped field at a time. Validate the JSON structure after any edits to quotation marks, line breaks, or HTML.

The email was accepted but not seen

Symptom: The HTTP module succeeds, but the recipient says nothing arrived.

Likely cause: Acceptance is not the same as inbox placement. The address could be suppressed, the recipient’s server could defer delivery, the message could be filtered, or the address itself could be incorrect.

Fix: Check the Volanea message and delivery event records rather than relying only on Make’s successful HTTP status. Confirm the sender domain, recipient address, subject, and event timeline. Do not automatically reroute a failed email through another sender without identifying the reason; that can create duplicate or inconsistent customer communication.

Test the scenario before turning it on

A reliable test checks more than whether Make shows a green checkmark. It verifies the actual end-to-end behavior from event receipt through delivered message content.

Use this checklist:

Send a sample JSON payload to the Make Custom webhook.
Confirm the webhook module exposes the expected event_id, recipient, and personalization fields.
Verify the filter permits only the intended event type.
Inspect the HTTP module’s outgoing URL, method, headers, and JSON body.
Confirm the Authorization header is present but never copied into customer-facing data.
Confirm the Idempotency-Key is based on the event ID.
Open the received email in a test inbox and review HTML, text fallback, sender display name, links, and subject.
Submit the exact same event again and confirm it does not create an unintended second logical send.
Submit a different event ID and confirm it produces a new email.
Test missing required fields and verify that the scenario stops before calling Volanea.

It is useful to test both a happy path and a deliberately bad path. A workflow that succeeds only with perfect source data is not ready for production.

Add observability where it helps

Keep the source event ID visible in your scenario logs, CRM note, database record, or internal notification. When a recipient asks about a message, that ID lets you correlate the source event, Make execution, idempotency key, and Volanea send record.

Avoid placing sensitive content in IDs or headers. An event ID should be an opaque reference, not an email address, full name, password-reset token, or form response.

Choose direct Make sending or middleware deliberately

Calling Volanea directly from Make is the right design when Make is the trusted workflow boundary and the email is a normal automation outcome. It is compact, requires no custom server, and keeps field mapping visible in the scenario.

Use a middleware endpoint between Make and Volanea when you need stronger controls than an automation scenario should own. Examples include per-tenant authorization, complex HTML escaping, server-side data lookups, rate limiting, attachment generation, custom audit records, or strict business rules around what may be emailed.

A middleware design looks like this:

Source event → Make Custom webhook → Make HTTP request → Your server endpoint → Volanea POST /v1/send

The server endpoint validates the payload, applies policy, creates or retrieves the idempotency key, and sends through Volanea. Make still orchestrates the workflow, but the server owns the sensitive and complex send logic.

This is not automatically better. It adds infrastructure, monitoring, deployment, and another failure boundary. Choose it because you need its control plane, not because direct HTTP is somehow less legitimate.

Operational practices that keep the integration reliable

Once the first test message works, the work shifts from setup to operating a dependable system. A few habits prevent small workflow edits from becoming customer-facing email incidents.

Separate transactional and promotional intent

Use this Make-to-Volanea route for messages directly caused by an individual action or service event: a receipt, confirmation, security alert, account notice, or requested update. Keep bulk promotional sending, subscription preference management, and campaign logic in a workflow designed for marketing consent.

This distinction helps your team make better decisions about timing, content, suppression handling, and expectations. A person who completed a purchase expects a receipt. They do not necessarily expect an unrelated sales message because a workflow happened to have their address.

Keep the scenario narrow

A scenario with a single purpose is easier to test and safer to replay. Rather than creating one huge “all notifications” scenario, build focused flows such as order-receipt, demo-confirmation, and support-request-acknowledgment.

Focused scenarios also make idempotency naming clearer. make-order-order_12345 tells an operator much more than a generic random string does when they investigate a customer question.

Review mappings after source changes

Fields can disappear, rename, change type, or move deeper into an object when a source system updates its webhook format or connector. After changing a form, CRM workflow, backend event schema, or Make module, run fresh test data through the scenario.

Do not assume that a field token remains valid just because it is still visible in the editor. Confirm the actual received bundle and the actual outgoing email payload.

Monitor delivery separately from automation success

A successful Make run means Make completed its HTTP action. It does not guarantee that the recipient read the message, that the remote mailbox accepted it, or that it landed in the inbox.

Use Make to monitor automation failures and Volanea to monitor email lifecycle outcomes. That separation prevents a misleading operational conclusion: “the automation was green, so the recipient definitely received the email.”

Conclusion

To send email from Make with Volanea, use a Webhooks > Custom webhook as the concrete scenario trigger and HTTP > Make a request as the outbound API client. Send a JSON message to POST https://api.volanea.com/v1/send, authenticate with a Volanea secret key in the server-side Authorization header, and map only the fields you have validated.

The integration becomes production-ready when you add the details around the request: a verified sender domain, a stable Idempotency-Key derived from the source event, filters for missing data, testing for webhook retries, and clear ownership of delivery monitoring. Make can coordinate the event; Volanea can handle the email infrastructure; your event ID keeps a retry from becoming a duplicate customer email.

FAQ

Does Volanea have a native Make app?

No. This integration uses Make’s built-in Webhooks > Custom webhook trigger and HTTP > Make a request module to call Volanea’s REST API directly. There is no marketplace-install flow required or implied.

What Make trigger should start the email send?

Use Webhooks > Custom webhook when your application, form backend, or another service can POST an event to Make. If you use a source-specific Make trigger instead, map that trigger’s event fields into the same Volanea HTTP request.

Where should I store the Volanea API key in Make?

Place it in the Authorization: Bearer ... header configuration of the HTTP module in the Make scenario. Keep it out of browser code, form payloads, public configuration, and any client-visible environment variables.

How do I stop Make retries from sending duplicate emails?

Set Volanea’s Idempotency-Key header to a stable value derived from the source event ID, such as make-order-{{1.event_id}}. Reuse that exact key for every retry of the same logical email.

Can I use this flow for a form submission confirmation?

Yes. Post the form event to a Make Custom webhook, filter for valid submissions, map the submitter’s email and form fields into the Volanea JSON payload, and send a transactional confirmation. Validate required fields and use a stable submission ID as the idempotency key.

How to Send Email From Make With Volanea