How to Send Email From Supermetrics With Volanea

Send email from Supermetrics with Volanea by using Supermetrics Data Activation’s DIY event connector—not a marketplace app or native Volanea connector. The connector can forward an incoming Data Activation event to Volanea’s REST API, letting a journey-triggering event become a transactional email without exposing your API key in browser code.

What this integration does—and what it does not

This is a server-to-server integration for Supermetrics Data Activation. It is useful when you already collect customer events and profile data in Supermetrics and want a specific event to create a one-to-one email through Volanea.

For example, you can send a welcome email when an account_created event arrives, a receipt after purchase_completed, or a reminder after cart_started. The event is ingested into Supermetrics Data Activation, Supermetrics evaluates the event against the DIY event connector’s filter, and the connector sends a configured HTTP request to Volanea.

There is no native Volanea app to install from a Supermetrics marketplace. There is also no generic “send an email” button in Supermetrics reporting products such as Google Sheets, Looker Studio, Excel, or the standard reporting API. The direct route described here is specifically the DIY event connector in Supermetrics Data Activation.

That distinction matters. A reporting refresh is not a customer event, and it should not silently become a transactional email trigger. Use an event-based flow when the email corresponds to an identifiable person, a deliberate business action, and a message the recipient is eligible to receive.

The Supermetrics trigger that starts the email

The concrete trigger is an incoming event in Supermetrics Data Activation—also called an engagement in Supermetrics documentation—that matches the filter configured on the DIY event connector.

A practical welcome-email example looks like this:

1. Your application creates a customer account.
2. Your backend sends an account_created event into Supermetrics Data Activation with the customer’s email address, name, and an immutable event identifier.
3. Supermetrics receives the raw event and the DIY event connector evaluates its configured filter.
4. The filter accepts events where eventName equals account_created.
5. The DIY event connector issues a POST request to Volanea’s /v1/send endpoint.
6. Volanea validates the request, applies its suppression and sending checks, and queues the email.

In Supermetrics terminology, events are time-stamped actions. They are distinct from profile attributes, which are persistent values such as loyalty tier, subscription status, or consent state. Use an event as the trigger because a welcome email is tied to a moment in time: the account was created.

Why an event is better than an audience refresh

An audience answers a continuing question such as “who currently has an active trial?” A trigger email answers a point-in-time question such as “did this person just create an account?” Those are different delivery semantics.

If you send from an audience membership update, a profile can be added again after an identity merge, a segment-rule change, or a data correction. That can be appropriate for destination synchronization, but it is risky for an email intended to be sent exactly once. An immutable event ID plus Volanea idempotency is a safer foundation for transactional messages.

Build the event around the message you actually need

Do not assume that every Supermetrics profile field will automatically be present in the raw event forwarded by the DIY connector. The connector forwards event data, and its placeholders are populated from values you make available through event ingestion and attached transformations.

For a welcome email, make the required values explicit in the event payload your own application ingests:

• eventId: a stable unique ID for this logical event, such as evt_01J...
• eventName: account_created
• email: the recipient’s email address
• firstName: the recipient’s display name
• accountId: your internal account or user identifier
• planName: an optional personalization value
• marketingConsent: an optional eligibility signal if the message is promotional rather than transactional

The important field is eventId. It gives you a durable idempotency key. If Supermetrics or a network path retries the same outbound request, Volanea sees the same key and can treat it as the same logical send rather than a new email.

Prerequisites before you configure the connector

Before building the flow, confirm that you have access to Supermetrics Data Activation and that the DIY event connector is available in the account where your events are ingested. DIY event connectors are part of the Data Activation workflow, not a feature of every reporting destination or spreadsheet add-on.

You also need a Volanea account, a secret API key, and a verified sending domain. Your from address must use a domain that is ready to send in Volanea. Review the email API reference and setup guides before putting a production sender into the connector.

Use this readiness checklist:

• A backend, server-side tracking implementation, or another trusted source sends the event into Supermetrics Data Activation.
• The event contains the recipient email and a stable event identifier.
• Your Supermetrics identity setup can associate the event with the intended known profile where applicable.
• The event is testable in a non-production environment or with test profiles.
• The Volanea sending domain is verified.
• The sender address, such as hello@example.com, belongs to that verified domain.
• The Volanea secret key is stored as a secure connector property, never in page JavaScript, a public tracking tag, or a client-visible application setting.
• The email content has a clear transactional purpose, or you have confirmed the appropriate consent and unsubscribe policy for promotional content.

Decide whether the message is transactional or promotional

A signup confirmation, account-security notification, receipt, password link, and service-status notification are usually transactional messages. A newsletter, discount, product announcement, and win-back offer are promotional messages.

That classification affects more than wording. Promotional mail requires a defensible consent model and a clear unsubscribe path. Do not label a campaign as transactional merely to avoid consent checks. Supermetrics can hold consent-related profile attributes, but your event pipeline must include the eligibility signals needed to make the decision before the connector sends.

Configure the Supermetrics DIY event connector

In Supermetrics Data Activation, create a DIY event connector. This connector is designed to send raw incoming events to a custom external endpoint and supports request method, endpoint URL, authorization, headers, properties, payload templates, transformations, and filters.

Use the following request configuration as the baseline:

The connector accepts placeholders in payloads in the ${property} format. Create properties or transformations so the names used in the template—such as ${email}, ${firstName}, and ${eventId}—are available from the raw event.

Store the API key as a secure property

Create a connector property named volaneaApiKey, set its value to your Volanea secret key, and mark it Secure. Supermetrics documents secure properties specifically to prevent sensitive values from being unintentionally disclosed to other users editing the configuration.

Then use the property only in the Authorization header:

Authorization: Bearer ${volaneaApiKey}

Do not put the key in the endpoint URL, payload, event properties, or a custom field that may be exposed in logs. Bearer keys authorize sending, so anyone who obtains one may be able to send mail from your account until the key is revoked.

Add a narrow event filter

A DIY event connector can forward raw events as soon as they arrive. Without a filter, an overly broad configuration can turn every tracked action into an API call.

For this example, make the connector eligible only for an account-created event. You may also add conditions that reduce accidental sends, such as requiring a non-empty email field and an account status of active.

Do not filter based solely on a display name or a loosely formatted status string. Use values your backend controls. A small schema contract is safer than relying on analytics labels that marketers may change later.

The real request payload Supermetrics sends to Volanea

The DIY connector’s payload is a free-form request body. That means Supermetrics does not impose a hidden Volanea-specific schema: you define the JSON it sends, and placeholders are substituted with event or transformed values.

For the account_created event, configure this as the DIY connector payload:

{
  "from": "Acme Accounts <hello@example.com>",
  "to": "${email}",
  "subject": "Welcome to Acme, ${firstName}",
  "text": "Hi ${firstName}, your ${planName} account is ready. Sign in at https://app.example.com/login.",
  "html": "<p>Hi ${firstName},</p><p>Your <strong>${planName}</strong> account is ready.</p><p><a href=\"https://app.example.com/login\">Sign in to Acme</a></p>"
}

When Supermetrics receives this example event:

{
  "eventId": "evt_01JX8Q1S2A3B4C5D6E7F8G9H0J",
  "eventName": "account_created",
  "email": "maya@example.net",
  "firstName": "Maya",
  "accountId": "usr_48291",
  "planName": "Starter"
}

the outgoing request body becomes:

{
  "from": "Acme Accounts <hello@example.com>",
  "to": "maya@example.net",
  "subject": "Welcome to Acme, Maya",
  "text": "Hi Maya, your Starter account is ready. Sign in at https://app.example.com/login.",
  "html": "<p>Hi Maya,</p><p>Your <strong>Starter</strong> account is ready.</p><p><a href=\"https://app.example.com/login\">Sign in to Acme</a></p>"
}

The equivalent full REST call is below. It shows exactly what the connector should produce after placeholder substitution; the API key is represented as an environment variable only because it should never be hard-coded into application code or documentation.

curl --request POST "https://api.volanea.com/v1/send" \
  --header "Authorization: Bearer $VOLANEA_API_KEY" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: supermetrics-evt_01JX8Q1S2A3B4C5D6E7F8G9H0J" \
  --data '{
    "from": "Acme Accounts <hello@example.com>",
    "to": "maya@example.net",
    "subject": "Welcome to Acme, Maya",
    "text": "Hi Maya, your Starter account is ready. Sign in at https://app.example.com/login.",
    "html": "<p>Hi Maya,</p><p>Your <strong>Starter</strong> account is ready.</p><p><a href=\"https://app.example.com/login\">Sign in to Acme</a></p>"
  }'

Volanea’s send endpoint is POST /v1/send. It accepts a JSON message with sender, recipient, subject, and message content, and supports an Idempotency-Key header for safe retries. One send request can address one recipient or up to 50 recipients, but event-triggered lifecycle mail should normally use one recipient per event.

Field mapping, line by line

The mapping is intentionally direct:

Keep from static unless you have a carefully governed reason to switch among verified senders. Letting event data choose the sender address is a common way to create domain-verification failures, inconsistent branding, or header-injection risks.

If you need dynamic content beyond a short email, consider using a stored Volanea template and passing variables rather than embedding a large HTML document in the Supermetrics connector. That keeps marketing copy, layout changes, and email rendering work out of the event-routing configuration.

Authentication and secret handling

The Volanea API key belongs on the Supermetrics server-side connector configuration, stored as a Secure property. It does not belong in the browser-side tracking script, a public website configuration object, an email link, or an event payload sent from an untrusted client.

A browser-visible key is not merely a configuration mistake. A visitor can inspect JavaScript bundles, network requests, local storage, tag-manager values, or source maps. If the key is exposed, an attacker could send unwanted messages, consume sending capacity, damage your domain reputation, or use your infrastructure for phishing.

Why the Data Activation connector is a safer boundary

The DIY event connector runs as a server-to-server integration. The recipient’s browser does not receive the Volanea secret key simply because the user created an account or submitted a form.

However, server-side does not mean “trust every input.” The source event still needs validation before it reaches Supermetrics. If an unauthenticated endpoint accepts arbitrary email, firstName, and eventId values, an attacker could cause email sends through a legitimate connector.

Protect the upstream event source by requiring application authentication, validating email syntax, enforcing event schemas, rate-limiting event creation, and generating eventId values on the server. Your browser may request an account creation, but your backend should be the system that decides an account was actually created and emits the trusted event.

Rotate keys deliberately

Use a dedicated Volanea key for this connector rather than sharing a broad production key across unrelated tools. A dedicated key makes audit trails and emergency rotation much cleaner.

When rotating the key, update the secure property, test one controlled event, and then revoke the old key only after confirming that the new request is authorized. Avoid a rotation process that leaves two long-lived keys active indefinitely.

Make the email flow idempotent

Email APIs use POST, and a client may not know whether a timed-out request reached the server. A connector can retry after a timeout; a network device can reset a connection after Volanea has accepted the request; an operator can reprocess an event. Without idempotency, each of those cases can create a second welcome email.

Volanea supports the Idempotency-Key header on sends. Use one stable value for one logical email. In this guide, that is:

supermetrics-${eventId}

The first attempt and every retry of the same account-created event must use the exact same key. A different event for the same person must use a different key. Do not build the key from a timestamp generated at delivery time, because a retry will get a different timestamp and defeat deduplication.

Good and bad idempotency keys

Good:

• supermetrics-evt_01JX8Q1S2A3B4C5D6E7F8G9H0J
• welcome-usr_48291-account-created-2026-10-14T12:00:00Z when that exact identifier is generated and persisted by your backend
• A deterministic hash of an immutable event ID and message type

Bad:

• welcome-${email} because a user may legitimately receive another welcome-like message after a new account is created
• Date.now() because it changes on every retry
• A random UUID generated inside the connector for each request attempt
• The subject line, because copy edits should not make an old event send again

Idempotency prevents duplicate processing of the same request. It does not replace business logic. You should still make sure that the upstream service emits account_created only after the account is committed successfully.

Test the integration before activating it

Do not begin with live signup traffic. Start with a test profile and a mailbox you control.

A practical test sequence

1. Create the DIY event connector with the endpoint, secure property, headers, payload, and narrow filter.
2. Use a test sender address on a verified Volanea domain.
3. Ingest one account_created event with a real test email and a known eventId.
4. Confirm the connector substituted the expected values in the outgoing payload.
5. Confirm the email appears in the recipient inbox and in Volanea’s send activity.
6. Submit the same event again with the same eventId.
7. Confirm it does not produce a second delivered email.
8. Submit a different event ID for a different test profile.
9. Confirm that a new email is sent normally.
10. Test missing fields, such as no firstName or no planName, before real traffic can encounter them.

For missing optional values, do not let a literal placeholder such as ${planName} reach the recipient. Use an attached transformation that supplies a fallback, or simplify the copy so the optional field is not required. For instance, “Your account is ready” is safer than “Your ${planName} account is ready” if plan assignment can happen later.

Test the negative path too

A reliable implementation is not only one that sends. It is one that refuses to send when the event is unsafe or incomplete.

Test these conditions deliberately:

• An event with no recipient email
• An event that does not match account_created
• An event from a test environment
• An event with an invalid or malformed recipient address
• A request with an invalid Volanea key
• A request whose sender domain has not been verified
• A duplicate event ID

Document which system owns remediation for each failure. Your application team may own source-event quality, the Supermetrics owner may own connector filters and transformations, and the email owner may own domain verification and sender policy.

When this breaks

Every integration needs a failure model. This one has two boundaries: event delivery into Supermetrics and the outbound HTTP call from the DIY connector to Volanea.

Retries create duplicate sends

A timeout does not prove that Volanea failed to process the request. Supermetrics may retry the outbound request, or an operator may replay an event after investigating an incident.

Symptom: recipients receive duplicate welcome or receipt emails.

Likely cause: the connector sends a new idempotency key for every retry, or no Idempotency-Key is configured.

Fix: use the immutable source event ID in Idempotency-Key, keep it unchanged for retries, and retain source-event records long enough to investigate duplicates. Do not generate a new key in a transformation that runs once per attempt.

The webhook request times out

The DIY event connector is making an HTTP request to a third-party API. If the endpoint does not return promptly, the request may time out even though Volanea eventually accepts it—or it may fail before delivery.

Symptom: intermittent failures, repeated connector attempts, or a mismatch between Supermetrics logs and sent-message records.

Likely cause: transient network trouble, a Volanea API outage, a DNS problem, or an unexpectedly slow downstream dependency.

Fix: keep the payload small, avoid synchronous calls from your email flow to unrelated systems, use idempotency, and monitor both sides. If the request cannot reliably complete within the connector’s execution limits, route the connector to a small middleware endpoint that immediately validates and records the event, then sends to Volanea asynchronously.

That middleware pattern is also useful when you need richer HTML rendering, database lookups, consent checks, custom audit logs, or queue-based retry controls that are more advanced than a connector template.

Required fields are missing on some events or subscriptions

The DIY connector only substitutes values that exist in the event data or attached transformations. A profile may be known in one data source but still lack a field in the particular raw event being forwarded.

Symptom: blank names, unrendered placeholders, invalid recipient errors, or copy such as “Hi ,”.

Likely cause: the event schema did not include the field, an attached transformation was not applied, or the relevant Data Activation capability is not enabled in the workspace or plan.

Fix: treat email and eventId as required at ingestion; provide defaults for optional values; create a test matrix for each event source; and confirm availability of Data Activation and DIY event connectors for the applicable Supermetrics subscription before designing a production dependency around them.

Do not paper over a missing email value by falling back to a generic address. That turns a data-quality issue into a privacy issue.

Authentication fails with 401 or 403

Symptom: Volanea rejects the request immediately.

Likely cause: a revoked key, a copied key with whitespace, a non-secure property referenced incorrectly, or a malformed Authorization header.

Fix: verify that the connector sends Authorization: Bearer <secret-key>, confirm the secure property value without placing it in logs, and rotate the key if its exposure is possible. Also confirm that the connector sends to the production endpoint with a production-capable secret, not a test key used in the wrong environment.

The sender is rejected

Symptom: Volanea accepts authentication but the send fails because of the sender.

Likely cause: the from address does not use a verified domain, an event unexpectedly changed the sender, or the selected sender is not approved for the account.

Fix: keep from static in the connector payload and complete domain authentication before enabling live triggers. Use a dedicated sending subdomain if you want to isolate this application stream from other mail programs.

A journey condition never produces the expected event

Supermetrics journeys can use behavioral and time-based conditions. A behavioral condition requires a new relevant event to arrive; a time condition alone can progress when its time is reached. Combining them incorrectly can leave a profile waiting for a later event that never arrives.

Symptom: no email is sent even though a profile appears eligible in a dashboard.

Likely cause: the journey’s entry or branch logic expects a fresh event after the profile reaches that step, while the event happened earlier.

Fix: test the journey with an event timeline, define the entry condition as the actual trigger moment, and use a delay step when the intended behavior is “wait, then send” rather than “wait until another behavior occurs.”

Operational guidance for production

Treat the connector configuration as production code. It determines who receives email, what they receive, and when a send occurs.

Keep a lightweight change process for:

• Event schema changes
• Connector filters and transformations
• Email sender changes
• Subject-line or template changes
• Consent-policy changes
• API-key rotations
• New environments or test-to-production promotion

Use a naming convention that identifies the business action and environment, such as prod-account-created-volanea-welcome. A clear name is especially valuable when multiple teams operate journeys, audiences, data sources, and email programs in the same Supermetrics account.

Monitor both the trigger and the result. On the Supermetrics side, watch event ingestion volume, connector activity, and filter behavior. On the Volanea side, watch accepted sends, bounces, suppressions, delivery events, and complaint signals. A sudden drop in sends may be a broken event pipeline; a sudden increase may be an accidental broad filter or duplicate event source.

Finally, preserve an audit trail outside the email itself. Store the source event ID, recipient, message type, and Volanea result in an internal log or database where your support and engineering teams can answer: “Why did this person receive this message?” That question is inevitable in a mature lifecycle-email program.

Direct connector vs. middleware

The direct DIY connector route is the simplest setup when the email can be constructed from the incoming event and a static sender. It avoids an additional service and keeps the path short.

Use a middleware service instead when you need one or more of the following:

• Server-side database lookups before sending
• Complex conditional content or localization
• A template-rendering system managed in source control
• Stronger schema validation than connector transformations provide
• A dedicated dead-letter queue and custom retry policy
• Centralized per-message audit logging
• A way to combine multiple upstream systems before sending
• A policy that keeps email-provider credentials out of third-party automation configuration

The direct path is not inherently less secure if the key is held as a secure property and the event source is trusted. Middleware is a better fit when business logic becomes substantial. Do not build middleware merely to reproduce a static JSON transformation; do build it when the email decision needs application context that Supermetrics does not have.

Conclusion

To send email from Supermetrics with Volanea, use Supermetrics Data Activation’s DIY event connector as a server-to-server event forwarder. The trigger is a raw incoming event—such as account_created—that matches the connector filter. The connector maps event fields into Volanea’s POST /v1/send JSON body, keeps the Volanea key in a secure property, and uses the source event ID as the Idempotency-Key.

The most important design decision is not the HTTP request. It is the event contract: include a stable event ID, the recipient address, the message data you truly need, and eligibility signals that are evaluated before a send. With that contract in place, the connector can deliver a simple, maintainable transactional-email flow without pretending a native Supermetrics marketplace integration exists.

FAQ

Does Volanea have a native Supermetrics integration?

No. This setup uses Supermetrics Data Activation’s DIY event connector to make a server-to-server HTTP request to Volanea’s REST API. There is no Volanea marketplace app or native connector to install for this flow.

What triggers the email in Supermetrics?

A raw incoming Data Activation event, also called an engagement, triggers the connector when it matches the connector filter. For example, an event where eventName equals account_created can send a welcome email.

Where should the Volanea API key be stored?

Store it as a Secure property in the Supermetrics DIY event connector and reference it in the Authorization: Bearer ... header. Never include it in browser code, public configuration, tracking events, or a client-side tag manager variable.

How do I prevent duplicate emails after a retry?

Set Idempotency-Key to a stable value derived from the immutable source event ID, such as supermetrics-${eventId}. Every retry of that same logical event must use the same key.

Can I use this for marketing campaigns?

Technically, the connector can send any configured message, but promotional email needs a valid consent and unsubscribe strategy. Use event-triggered direct sends primarily for transactional or lifecycle messages, and ensure marketing eligibility is represented in your event or profile data before sending.