How to Send Email From Fivetran With Volanea

Send email from Fivetran by using Fivetran Activations as the outbound layer: a new qualifying record appears in your activation dataset, Fivetran sends a configured HTTP request, and Volanea accepts that request at its transactional email endpoint. This is a direct API integration, not a native Volanea app, marketplace listing, or Fivetran connector.

The distinction matters. Fivetran’s core product moves data into a warehouse or lake; it does not turn a form submission or an application event into an email at the moment it happens. For this workflow, the email trigger is a new record in an Activations dataset that is picked up by an event sync using the Send behavior. The record can originate from an order table, a product-usage event table, a support workflow, or a model built from several synced sources.

This guide uses a practical order-confirmation example, but the same architecture works for account alerts, renewal reminders, trial-expiry notices, document-ready notifications, internal escalation messages, and post-processing receipts.

What this integration does—and what it does not

There is no native Volanea destination in Fivetran Activations and no Volanea app to install from a Fivetran marketplace. The supported direct route is Fivetran Activations’ HTTP Request destination, which can send data to services that accept ordinary HTTP requests.

That makes the data flow look like this:

1. A source system creates or updates operational data.
2. Fivetran syncs that source data to your warehouse or lake.
3. Your warehouse model produces one eligible email-event row per logical message.
4. Fivetran Activations detects the new row during an activation sync.
5. An HTTP Request destination makes a POST request to Volanea.
6. Volanea accepts the request, applies the sending-domain, suppression, contact, and delivery pipeline, then queues the transactional message.

This is a warehouse-driven email workflow. It is excellent when the warehouse is your approved source of truth and a few minutes of pipeline latency are acceptable. It is not the right pattern for a password reset, sign-in code, or payment authorization response where the application must send immediately and synchronously. Those events should call Volanea from the application backend or a queue consumer instead.

Fivetran’s older Activations Webhooks destination has been replaced for new setups by the HTTP Request destination. Do not build a new integration around the deprecated Webhooks destination when HTTP Request is available.

The real Fivetran trigger: a new activation record

The concrete trigger is not “a Fivetran webhook fires when a customer submits a form.” Fivetran Activations works from data made available in an activation source. For an event-style sync, the trigger is a new row appearing in the dataset or segment selected for the sync.

Use the Send sync behavior for email events. With that behavior, Fivetran treats the dataset as an append-oriented event log: when it identifies a qualifying new record, it sends that record to the destination. Your row needs a stable unique ID so Fivetran can distinguish a new email event from one it has already processed.

Example: order confirmation event model

Assume your warehouse has an orders table synced from your commerce system. Instead of sending directly from raw orders, build a small modeled view for email. The model should contain exactly one row for each email you intend to send.

-- analytics.order_confirmation_email_events
select
  concat('order-confirmation:', cast(order_id as string)) as email_event_id,
  cast(order_id as string) as order_id,
  customer_email as recipient_email,
  customer_first_name as recipient_first_name,
  total_amount as order_total,
  currency,
  order_created_at,
  concat('https://app.example.com/orders/', cast(order_id as string)) as order_url
from analytics.orders
where order_status = 'paid'
  and customer_email is not null
  and customer_email <> ''
  and order_id is not null;

The email_event_id is the important field. It represents one logical send, not one sync attempt. If Fivetran retries the same delivery or if the destination response is lost after Volanea has already received the request, the same event ID must still identify the same email.

A good event model also separates business eligibility from transport logic. The SQL decides whether an order is paid and has a usable email address. The HTTP request only maps an already-approved event record into a message. That separation makes it easier to audit why a message was or was not sent.

Choose the right source semantics

Before configuring the activation, decide whether the event should be append-only or state-driven:

• Append-only event: One new row equals one message. Order confirmations and document-ready notices fit this model well.
• State change: A row becomes eligible after a field changes, such as trial_status = 'expiring'. Use a stable event ID that includes the intended send version or date.
• Scheduled reminder: A daily model produces rows for customers who should receive a reminder that day. Include the reminder date or sequence number in the event ID.
• Internal alert: A modeled anomaly table emits one row per incident. Use an incident identifier plus alert type, not the current timestamp, as the stable key.

Avoid using a random UUID generated inside the model for the idempotency key. A regenerated UUID makes a repeated logical event look new, defeating retry protection and risking duplicate email.

Prerequisites before you create the destination

You need four things in place:

1. A Fivetran Activations workspace connected to an activation source containing the email-event dataset.
2. Access to create an HTTP Request destination and an event sync.
3. A Volanea secret key and a verified sending domain.
4. A dataset containing a stable unique event ID, recipient address, subject inputs, and content inputs.

Volanea’s send endpoint is POST https://api.volanea.com/v1/send. It accepts a secret key using an Authorization: Bearer header, and it supports an Idempotency-Key header for safe retries. A verified sender is required: do not use an arbitrary address in the from field merely because it looks appropriate for the message.

If you have not created the key, verified the sending domain, or tested a basic API request yet, start with the Volanea API reference and setup guides. Domain verification and sender alignment should happen before you point a production activation at the endpoint. Otherwise, a perfectly configured Fivetran sync can still fail at the final email-send step.

Prepare content deliberately

Fivetran’s HTTP Request destination is useful for mapping data into an API request, but it is not a full email-template authoring environment. Keep the message payload straightforward:

• Put static sender details in the request body.
• Map a warehouse column to the recipient.
• Map a warehouse column or a fixed value to the subject.
• Provide both HTML and text content where practical.
• Keep generated HTML simple and validated upstream.
• Do not place sensitive personal data in query parameters.

For complex templates, locale-specific copy, attachments, conditional blocks, or richer business rules, use a small middleware endpoint. Fivetran can still trigger the endpoint, but the middleware can look up a Volanea template, validate the record, build the message, and retain an audit record before calling Volanea.

Create the Volanea HTTP Request destination in Fivetran

In Fivetran Activations, go to Destinations, choose New Destination, and select HTTP Request. Give the destination a recognizable operational name such as Volanea Transactional Email – Production.

Choose Manual authentication. Volanea uses a secret API key rather than OAuth, so manual headers are the appropriate configuration.

Set the base URL to:

https://api.volanea.com

Then add these destination-level headers:

When adding the Authorization header, enable Fivetran’s secret option for the header value. This masks the secret in the destination configuration after it is saved.

Where the API key belongs

The Volanea key belongs in the HTTP Request destination’s Manual authentication header configuration, stored as a secret value. It should not be stored in:

• a browser application bundle;
• a client-side environment variable such as NEXT_PUBLIC_* or VITE_*;
• a warehouse table or dbt model;
• an event payload column;
• a query parameter;
• a subject line, HTML body, or log annotation;
• a shared spreadsheet or copied code sample.

A Volanea secret key authorizes sending activity. If it leaks into a public frontend or client-visible configuration, anyone who obtains it may be able to submit mail through your account. Keeping it in the Fivetran destination secret field limits exposure to the server-side service that makes the outbound request.

Use a dedicated key for this integration rather than reusing a key from an unrelated application. That gives you a clean rotation path: update the HTTP Request destination with the replacement secret, test the destination, then revoke the old key once the new configuration is proven.

Configure the event sync and field mapping

Next, create a sync that uses your email-event dataset and the HTTP Request destination.

Choose the Send behavior. In this pattern, Fivetran detects new dataset records and sends each new record as an action. Configure email_event_id as the event’s stable unique identifier. For initial setup, select the option that starts from future records rather than backfilling historic records unless you intentionally want to send every historical event.

A backfill choice is not a harmless test setting. If your model contains 100,000 past paid orders and you choose to backfill, Fivetran can attempt to generate 100,000 confirmation emails. For a production email workflow, start with a narrowly filtered test dataset or with new records only.

Request configuration

Configure the HTTP request as follows:

• Method: POST
• Path: /v1/send
• Content type: JSON
• One request per event record: yes
• Idempotency key: map the stable email_event_id field to the Idempotency-Key request header if the request editor supports per-record header mapping.

The exact request body is configured through Fivetran’s mapping interface. Select columns from your dataset rather than pasting unverified template syntax from another automation product. The result of the mapping for one order-event row should be the following JSON shape.

POST /v1/send HTTP/1.1
Host: api.volanea.com
Authorization: Bearer sk_live_your_volanea_secret_key
Content-Type: application/json
Idempotency-Key: order-confirmation:ORD-10482

{
  "from": "receipts@example.com",
  "to": "alex@example.net",
  "subject": "Your order ORD-10482 is confirmed",
  "html": "<p>Hi Alex,</p><p>Thanks for your order <strong>ORD-10482</strong>.</p><p>Total: USD 49.00</p><p><a href=\"https://app.example.com/orders/ORD-10482\">View your order</a></p>",
  "text": "Hi Alex,\n\nThanks for your order ORD-10482.\nTotal: USD 49.00\n\nView your order: https://app.example.com/orders/ORD-10482"
}

Here is the field mapping that produces that payload:

The payload above is the actual HTTP message Volanea receives after Fivetran resolves the record’s mapped fields. It is not a generic Fivetran webhook envelope. HTTP Request sends the request you configure; therefore, your configured JSON body is the payload shape.

Test with a single controlled event

Create a test row with an internal or disposable recipient address. Give it a distinct event ID such as order-confirmation:TEST-0001. Run the sync and check three places:

1. The Fivetran sync run history for a successful destination action.
2. The Volanea send log for the accepted message.
3. The recipient inbox and spam folder for the rendered message.

Then run the same logical event again with the same idempotency key. The goal is not to receive a second message; it is to prove that a retry is safe. After that, create another test row with a different event ID and verify that it results in a separate send.

Why idempotency is mandatory for email actions

An HTTP success path is deceptively simple: Fivetran sends a request, Volanea replies, and Fivetran marks the action complete. Production failure paths are less tidy.

For example, Volanea may accept and queue the message, but a network interruption can prevent Fivetran from receiving the response. Fivetran may retry because it cannot know whether the remote system completed the action. Without idempotency, that retry can create a second email.

The Idempotency-Key header gives Volanea a stable identifier for the logical send. Repeating the same request with the same key is treated as a retry of the same operation rather than a new email request.

Build the key from business identity

Use a key tied to the event’s meaning:

order-confirmation:ORD-10482

For other workflows:

trial-expiry:customer_4931:2026-10-04
invoice-ready:inv_88291
security-alert:user_104:login_01JQ5Z
weekly-digest:customer_4931:2026-W40

Do not use an ephemeral execution identifier, the Fivetran sync-run ID, or a newly generated random UUID. Those values identify an attempt, not the message. A retry should reuse the business event’s key.

If you intentionally need to resend a corrected receipt, create a new semantic key, such as order-confirmation:ORD-10482:v2, and make the message clearly explain the correction. Idempotency should prevent accidental duplicates, not block intentionally distinct communication.

When this breaks: troubleshoot the Fivetran-to-Volanea hop

The most useful troubleshooting question is: did Fivetran fail before making the request, did Volanea reject the request, or did Volanea accept it but the email later fail to deliver? Those are different layers with different evidence.

Fivetran retries create duplicate-looking sends

A retry can occur after a timeout, connection interruption, or response-handling failure. The destination may have sent the request even though Fivetran records the action as failed or incomplete.

Prevention: map a deterministic email_event_id to Idempotency-Key. Never generate a new key on every attempt. Keep the same request body for a given key where possible; changing the body while reusing an idempotency key can make diagnosis difficult.

Diagnosis: search the Volanea send log by recipient, subject, and time window. Compare the event ID to the Fivetran sync run. If duplicate messages have different idempotency keys, the problem is usually upstream event construction, not provider retry behavior.

HTTP request timeouts or non-2xx responses

A timeout does not prove that Volanea did not receive the request. Treat it as an unknown outcome. Inspect the Volanea send log before manually replaying a record.

For an explicit non-2xx response, inspect the response details in Fivetran’s sync history. Common causes include a malformed JSON body, missing required message fields, an invalid recipient value, an unverified sender domain, or an invalid API key.

Prevention: test the same payload outside the activation before production rollout, use both HTML and text, and make sender addresses static and verified. Keep large or complex content out of an initial direct mapping until the simple send path works.

Payload fields are missing or blank

Fivetran does not invent or enrich email fields. The HTTP request only has access to fields in the activation dataset and fields you map into the request. If a customer name, order URL, or recipient address is blank at the destination, inspect the dataset row first.

Do not assume Fivetran is silently omitting fields because of an unspecified plan limitation. The practical plan and workspace question is whether your account has access to Activations and the HTTP Request destination. Once the activation exists, missing values are typically a modeling, source-data, schema, permission, or mapping issue.

Use these checks:

• Confirm the column appears in the selected activation dataset.
• Confirm the destination mapping references that exact column.
• Check whether the source system populated the field before Fivetran’s ingestion cutoff.
• Verify the warehouse model did not turn a value into NULL through a join or cast.
• Add validation to exclude rows with blank recipient addresses or required content fields.
• Test with one row whose values are unmistakably populated.

For critical communication, add an upstream validation status column such as is_email_ready. Filter the activation model to is_email_ready = true rather than relying on the send endpoint to discover every data-quality issue.

The sender is refused

If Volanea rejects the request because the from address is not on a verified sending domain, fix the sender configuration rather than substituting a personal mailbox. A verified organizational domain protects deliverability, aligns your email identity, and makes operational ownership clear.

Use a role address such as receipts@, notifications@, or support@ on a verified domain. Keep the sender static in the destination mapping unless you have a controlled, verified set of sender domains.

The send was accepted but no email arrives

Acceptance is not the same as inbox placement. Volanea may accept the message while suppression rules, mailbox-provider filtering, bounces, or recipient-side policies affect final delivery.

Check the Volanea message record and delivery events, then confirm the recipient has not unsubscribed or been suppressed. For transactional notifications, do not repeatedly override bounce or complaint suppressions just to force delivery; those protections exist to preserve sender reputation.

Direct HTTP Request versus middleware

The direct Fivetran-to-Volanea request is the simplest route when every event maps cleanly to a short, self-contained transactional email. It has fewer moving parts, no extra server to operate, and keeps the API key in Fivetran’s secret destination configuration.

A middleware endpoint is the better design when your email logic becomes application logic. Examples include:

• selecting templates by locale, account tier, or product;
• rendering complicated HTML with robust escaping;
• looking up additional data not available in the warehouse model;
• sending attachments;
• branching to multiple recipients with business-specific rules;
• recording an immutable audit trail before delivery;
• enforcing custom rate limits or approval workflows;
• validating payload signatures or adding internal authorization checks.

In that architecture, Fivetran still uses HTTP Request, but it posts to your endpoint instead of directly to Volanea. The endpoint validates the Fivetran request, deduplicates on email_event_id, renders the message, and calls Volanea using a server-side secret.

Do not introduce middleware merely to hide a key if Fivetran’s secret header field already meets your governance requirements. Introduce it when it provides meaningful control over message construction, auditing, or reliability.

Operating the workflow over time

Treat this activation as a production integration, not as a dashboard automation. The key operational artifacts are the event model, destination configuration, idempotency convention, sender identity, and monitoring process.

Document the following for the team that owns it:

• dataset name and SQL model location;
• exact eligibility rules for a row to become an email event;
• the stable event-ID format;
• static sender address and owning team;
• Volanea key owner and rotation procedure;
• expected Fivetran sync schedule and acceptable latency;
• test recipient and rollback procedure;
• alert thresholds for failed actions or sudden send-volume changes.

Monitor both sides. Fivetran tells you whether an activation action was attempted and whether the destination request succeeded. Volanea tells you whether it accepted the message and what happened in the email delivery lifecycle. Neither system alone gives the complete picture.

It is also worth monitoring unexpected volume. A join change in a warehouse model can multiply rows and turn one intended confirmation into many events. Add uniqueness tests on email_event_id, recipient-address validation, and a sensible volume review before changing the model. If you need to forecast sending costs as volume grows, review transactional email pricing alongside your expected activation volume.

A production readiness checklist

Before enabling the sync for real customer data, verify every item below:

• A single modeled row represents exactly one logical email.
• email_event_id is stable, unique, and derived from business identity.
• The initial sync is configured to avoid an unintended historical backfill.
• The HTTP Request destination uses POST /v1/send.
• The Volanea key is stored as a secret destination header value.
• The Authorization header uses Bearer authentication.
• Content-Type is application/json.
• Idempotency-Key maps to email_event_id.
• The from address belongs to a verified Volanea sending domain.
• Every eligible record has a valid recipient address.
• Both HTML and text message bodies render correctly.
• One test event succeeds end-to-end.
• A replay with the same event ID does not create a second email.
• A new event ID does create a distinct message.
• Fivetran sync failures and Volanea delivery issues have named owners.

Conclusion

To send email from Fivetran with Volanea, build the workflow around Fivetran Activations—not a nonexistent native plugin. A new row in an activation dataset is the real trigger, an event sync with Send behavior turns that row into a configured HTTP request, and Volanea’s POST /v1/send endpoint turns the request into transactional email.

The reliable version of this integration is built on three decisions: use a clean event model, keep the Volanea API key in Fivetran’s secret header configuration, and send a deterministic Idempotency-Key for every logical message. Those choices make warehouse-driven email useful without turning a retry, a model change, or a network timeout into an inbox incident.

FAQ

Does Volanea have a native Fivetran destination?

No. Volanea does not provide a native Fivetran app, marketplace listing, or connector for this workflow. Use Fivetran Activations’ HTTP Request destination to call Volanea’s REST API directly.

What exactly triggers the email in Fivetran?

For an event sync using Send behavior, the trigger is a new qualifying record in the selected activation dataset or segment. It is detected during an Activations sync, not at the instant a person submits a form in the original application.

Where should the Volanea API key be stored?

Store it in the HTTP Request destination’s Manual authentication header configuration and mark the header value as secret. Do not include it in a dataset, browser app, query string, or mapped request payload.

How do I stop duplicate emails when Fivetran retries?

Map a stable business event ID, such as order-confirmation:ORD-10482, to Volanea’s Idempotency-Key header. Reuse that same key for a retry of the same logical message.

Should I use Fivetran for password resets or login codes?

Usually no. Those messages need application-time delivery and immediate response handling. Call Volanea directly from your backend, authentication provider action, or queue worker instead of waiting for warehouse ingestion and an activation sync.