How to Send Email From LoyaltyLion With Volanea

Loyalty programmes create moments worth acknowledging, but the event that creates a reward or adds a customer is not automatically an email-delivery system. This guide shows how to send email from LoyaltyLion with Volanea through a server-side Zapier flow, with explicit mapping, secure authentication, and safeguards for duplicate events.

What this integration does

This integration connects a LoyaltyLion event to Volanea’s email-sending API. A practical example is a welcome message when LoyaltyLion creates a new customer, but the same design can be adapted to other LoyaltyLion events exposed in Zapier, such as a reward or transaction event when available in an account.

The important architectural point is that this is not a native Volanea app inside LoyaltyLion. LoyaltyLion does not provide a Volanea marketplace installation or a place to paste Volanea sending settings as a built-in provider. Instead, Zapier acts as middleware:

1. LoyaltyLion creates a customer.
2. LoyaltyLion’s New Customer Zapier trigger supplies the customer data to the Zap.
3. A Zapier Code step validates and reshapes that data.
4. A Webhooks by Zapier step makes a server-to-server POST request to Volanea.
5. Volanea accepts the message for delivery and returns a response to the Zap.

This separation is useful even beyond the initial use case. LoyaltyLion remains the source of truth for loyalty membership and activity. Volanea remains the email infrastructure responsible for accepting the message, applying the sending domain configuration, and delivering it. Zapier owns the orchestration between the two systems.

For a developer-managed implementation, the same pattern can move to a small endpoint on a worker, serverless function, or application backend. That is often the better long-term route when message volume, conditional logic, or audit requirements outgrow a no-code workflow.

Why use middleware rather than a direct LoyaltyLion HTTP request?

An outbound HTTP request needs three things: an event source, an HTTP client, and a protected place for credentials. In this setup, the LoyaltyLion Zapier app supplies the event source and Zapier’s webhook action is the HTTP client.

That distinction matters because a browser-based loyalty widget is not an appropriate place to call an email API. Putting a Volanea API key in storefront JavaScript, a public theme setting, a loyalty-page snippet, or any client-visible configuration would expose a credential that can send mail under your account. A visitor could inspect the page, extract the key, and use it outside your intended workflow.

Zapier runs the action on its servers after the LoyaltyLion trigger fires. The Volanea API key is therefore used in a server-side request rather than shipped to the customer’s browser. An administrator can still view and change the Zap configuration, so use the minimum practical scope, restrict administrative access to Zapier, and rotate the key if an administrator leaves or a credential is exposed.

A middleware route also creates a useful control point. You can validate an address, reject incomplete events, select a template based on loyalty state, add an idempotency key, and record a message identifier before Volanea is called. Those controls are awkward or impossible in a direct client-side integration.

The LoyaltyLion trigger: New Customer

For the workflow described here, use LoyaltyLion’s Zapier trigger named New Customer. It runs when a customer is added to LoyaltyLion. That is the concrete event that starts the email send; it is not a generic “form submitted” event and it should not be confused with a customer merely viewing the loyalty page.

In Zapier, create a new Zap and choose LoyaltyLion as the trigger app. Select New Customer, connect the LoyaltyLion account when Zapier asks, then test the trigger with a real or test customer record. Do not build mappings from a guessed sample alone. The fields exposed by a connected account can vary with the data LoyaltyLion has for that customer and with the trigger version.

Decide what the new-customer email means

A new LoyaltyLion customer is not always equivalent to a new ecommerce customer. A merchant may import existing customers, migrate loyalty data, connect a customer after an account event, or create test records. Before turning the Zap on, decide which meaning should trigger communication.

For example, a loyalty welcome email may be appropriate for a genuinely new programme enrolment. It may be inappropriate for a historical import, because thousands of old records could create a large, confusing email burst. If imports or migrations are possible, add a Zapier Filter before the send step, or pause the Zap while importing and reconcile records afterward.

Also establish whether the message is transactional or promotional in your policy and in the recipient’s jurisdiction. “You joined the programme” may be operational confirmation in some contexts, while a message that promotes offers or future buying is marketing. Loyalty points and member status do not by themselves override consent requirements.

Inspect the actual trigger fields first

The test panel is the authority for the fields that your Zap receives. Commonly useful customer attributes include an identifier, email address, and name-related fields, but you should map only fields shown by the test event from your connected LoyaltyLion account.

That practice avoids two frequent mistakes:

• Mapping an email field that is absent for guest, imported, or incomplete customer records.
• Treating a display name as a stable identifier when the LoyaltyLion customer ID is the suitable value for deduplication and tracing.

Use the LoyaltyLion customer ID as the internal event reference when the trigger exposes it. Keep the email address as a delivery address, not as the sole identity key. Email addresses can change; an immutable provider record ID is usually more useful for investigating later sends.

Build the Zapier flow safely

A dependable first version uses four or five steps, not just a trigger followed by a webhook. The extra validation step makes failures observable and prevents an incomplete record from becoming a malformed API request.

Recommended step order

1. Trigger: LoyaltyLion — New Customer. Test it with a representative record containing an email address.
2. Filter by Zapier. Continue only if the trigger’s email field exists and is not blank. Add any programme, store, import, or consent conditions that apply to your policy.
3. Code by Zapier. Normalize fields and construct the Volanea JSON payload.
4. Webhooks by Zapier — Custom Request. Send the prepared JSON to Volanea.
5. Optional logging step. Write the LoyaltyLion customer ID, Volanea response ID, and status to an internal sheet, database, or incident channel.

The Filter is deliberately before the Code and webhook steps. A missing destination is a data-quality condition, not a transient delivery failure. Retrying it will not turn an empty address into a usable one.

If you want a light first-pass check on recipient quality, run the address through Volanea’s email address verification tool before sending. Verification is a helpful signal, not a substitute for consent, suppression management, or a clear message purpose.

Normalize before you render

Treat trigger data as untrusted integration input. Trim the address, remove control characters from a name, provide a safe fallback for a missing first name, and avoid putting raw values into HTML without escaping them.

A Code by Zapier step is useful because it produces an explicit object for the next step. It also lets you create a deterministic idempotency key from the LoyaltyLion customer ID. That key becomes important when Zapier retries a task after a timeout or when an upstream event is delivered more than once.

Use the code editor’s input-data fields to map the exact fields from your trigger test. The sample below assumes inputs named customer_id, email, and first_name; those are Code-step input names you create, not a claim that every LoyaltyLion trigger payload uses those exact property names.

// Code by Zapier (JavaScript)
// Create these input-data mappings in the step UI:
// customer_id -> the LoyaltyLion customer ID from New Customer
// email       -> the LoyaltyLion customer email field
// first_name  -> the LoyaltyLion first-name field, if exposed

const customerId = String(inputData.customer_id || '').trim();
const email = String(inputData.email || '').trim().toLowerCase();
const firstName = String(inputData.first_name || '').trim();

if (!customerId) throw new Error('LoyaltyLion customer ID is missing');
if (!email || !email.includes('@')) throw new Error('Customer email is missing or invalid');

const safeName = firstName.replace(/[&<>"']/g, (character) => ({
  '&': '&amp;', '<': '&lt;', '>': '&gt;', '"': '&quot;', "'": '&#39;'
}[character]));
const greeting = safeName ? `Hi ${safeName},` : 'Hi,';

const payload = {
  from: 'Loyalty Team <loyalty@example.com>',
  to: [email],
  subject: 'Welcome to our rewards programme',
  html: `<p>${greeting}</p><p>Your rewards account is ready. Sign in to see your points and available rewards.</p>`,
  text: `${safeName ? `Hi ${firstName},` : 'Hi,'}\n\nYour rewards account is ready. Sign in to see your points and available rewards.`,
  tags: [
    { name: 'source', value: 'loyaltylion' },
    { name: 'event', value: 'new_customer' }
  ]
};

return {
  loyaltylion_customer_id: customerId,
  idempotency_key: `loyaltylion-new-customer-${customerId}`,
  volanea_payload: JSON.stringify(payload)
};

Replace example.com with a domain you have authenticated for sending in Volanea. Do not use a sender address merely because it looks plausible. The sending domain and sender address need to match the identity configured in your account.

Make the Volanea REST API request

In the next Zap step, choose Webhooks by Zapier and select Custom Request. Configure a POST request to the Volanea email-send endpoint documented for your account. Keep the API URL and request schema aligned with the current Volanea API reference rather than copying an old example into production. The email API setup guides are the place to confirm endpoint, authentication, supported fields, and response behavior before activating the Zap.

The request below illustrates the request shape to use when your Volanea account’s API reference specifies the /v1/emails send endpoint and bearer-token authentication. Paste the output of the preceding Code step into the raw JSON body. In the Webhooks action, map the Code step’s volanea_payload output as the body value.

curl --request POST 'https://api.volanea.com/v1/emails' \
  --header 'Authorization: Bearer YOUR_VOLANEA_API_KEY' \
  --header 'Content-Type: application/json' \
  --header 'Idempotency-Key: loyaltylion-new-customer-LOYALTYLION_CUSTOMER_ID' \
  --data '{
    "from": "Loyalty Team <loyalty@example.com>",
    "to": ["member@example.net"],
    "subject": "Welcome to our rewards programme",
    "html": "<p>Hi Alex,</p><p>Your rewards account is ready. Sign in to see your points and available rewards.</p>",
    "text": "Hi Alex,\n\nYour rewards account is ready. Sign in to see your points and available rewards.",
    "tags": [
      {"name": "source", "value": "loyaltylion"},
      {"name": "event", "value": "new_customer"}
    ]
  }'

The field mapping is intentional:

In Zapier’s Custom Request configuration, set the URL to the documented endpoint, method to POST, and the Content-Type header to application/json. Add Authorization as a request header with the bearer token, then map the prepared volanea_payload string to the raw request body. If the Webhooks interface offers a “data” field instead of a raw body mode, do not inadvertently wrap the JSON string inside another object; inspect the task history to confirm the outbound body is the expected JSON object.

Keep the key out of the message data

The Volanea key belongs in the authentication header of the Webhooks by Zapier action, or in a secret facility used by your approved middleware. It does not belong in the Code step output, the email HTML, a query parameter, a public site environment variable, or a LoyaltyLion customer property.

Avoid logging the full request headers in a spreadsheet, Slack notification, or error handler. Those secondary systems frequently have broader access than the integration itself. If a task-history screenshot is needed for support, redact the authorization value first.

For larger teams, a dedicated backend is safer than sharing a Zap edit role widely. That backend can store the Volanea key in a managed secret store, expose no key to Zapier, and accept a narrowly authenticated request from the workflow. It can also enforce sender allowlists and event schemas centrally.

Design the email for loyalty events

The first loyalty email should answer a narrow question: what happened, what can the member do now, and where should they go? A welcome message does not need a live points balance if that balance is not included in the New Customer event. Claiming a value you do not have is worse than sending a clear general welcome.

A solid welcome message normally contains:

• The programme or merchant name the recipient recognizes.
• A concise confirmation that the loyalty account is ready.
• One primary next action, such as viewing rewards or signing in.
• Support contact information or a link to account help.
• Appropriate subscription, preference, and legal content for the message classification and market.

If you need dynamic points, tiers, referral URLs, or reward redemption details, do not assume the New Customer trigger carries them. Add a backend lookup using the appropriate LoyaltyLion API capability, or trigger from an event that actually contains the needed state. A lookup must also handle timing: immediately after account creation, related calculations may not yet be complete.

Prefer templates as the message grows

Inline html is transparent for an initial test but can become hard to maintain. With multiple locales, brands, or conditional sections, use a template system supported by your sending workflow and pass only the variables that are needed. Keep the event reference and customer ID in metadata or tags, not in a visible email unless there is a support reason to show it.

Version the copy deliberately. A task retry days later should ideally render the same event-specific message, not an unrelated campaign that happened to replace the current template. If exact historical reproduction matters, save a template version identifier in your integration log.

Deliverability and identity prerequisites

An API call that returns success means Volanea accepted the request; it is not a guarantee that the recipient will read the email. Inbox placement depends on sending identity, domain authentication, reputation, message content, recipient engagement, and downstream mailbox-provider decisions.

Before enabling the Zap, authenticate the sending domain in Volanea and publish the DNS records it provides. Do not guess DNS hostnames or values from an article: copy the records from the Volanea domain-setup flow exactly, then verify them there. Configure alignment and an appropriate DMARC policy for your domain as part of the broader sending programme.

Keep loyalty operational mail separate from broad promotional bursts where practical. That does not mean sending from a deceptive alternate identity; it means using sensible streams, tags, monitoring, and message intent so a sudden campaign does not obscure the performance of account and reward communications.

Test with a real receiving mailbox

A successful Zap test only proves that the request was constructed. It does not prove that the message rendered correctly or that the authenticated sender displays as expected. Test with at least one mailbox you control and check:

• The From display name and address.
• Mobile and desktop rendering.
• Plain-text readability.
• Links, including any account destination.
• Spam-folder placement and authentication results where visible.
• Whether the event tags and response identifiers appear in your Volanea reporting.

Use a deliberately created test LoyaltyLion customer for this exercise. Then delete or clearly label it according to your data-retention policy so it does not contaminate reporting or receive future programme messages.

When this breaks

Every hop has a different failure mode. A LoyaltyLion trigger can have incomplete fields, Zapier can retry or time out, and Volanea can reject a request because the sender or payload is invalid. Treating all of these as “email failed” makes diagnosis slow.

Retries can create duplicate sends

Zapier may retry a failed task, particularly when an outbound request times out or a temporary response occurs. A timeout is ambiguous: Volanea may have received and queued the message while the middleware did not receive the response. Sending the same request again without deduplication can create two welcome emails.

That is why the example derives Idempotency-Key from loyaltylion-new-customer- plus the LoyaltyLion customer ID. Use a stable key for the specific event, not a random value generated on every retry. Verify in the current Volanea API documentation how idempotency is supported and how long an idempotency key is retained. If your selected endpoint does not support that header, implement deduplication in your own middleware or datastore before making the send call.

Do not use the email address alone as the deduplication key. Two customers can share a family inbox, and one customer can legitimately change addresses. The LoyaltyLion record ID is the better event anchor when it is available.

Webhook and request timeouts

An API timeout does not necessarily mean an API failure. Check Zapier task history first: identify the exact request time, the HTTP status if present, and whether the subsequent retry used the same idempotency key. Then check Volanea’s send activity using the timestamp, recipient, tags, and any returned message ID.

Avoid inserting slow, synchronous work between the trigger and send. Address enrichment, complex database queries, and calls to several other systems increase the chance of timeout. If you move to custom middleware, acknowledge the incoming event quickly, put work on a queue, and process the send asynchronously with a durable idempotency record.

Some records may not contain an email address

A LoyaltyLion customer record can be incomplete from the perspective of an email send. Imported, guest, privacy-restricted, or otherwise partial records may not expose a usable email value to the Zap. The exact fields available can also depend on the connected account, data model, and trigger sample.

The answer is not to invent an address or route a customer ID into the to field. Use a Filter to stop blank addresses, log the skipped customer ID, and investigate the source data. If an email is required for programme membership in your business process, fix the upstream capture path rather than treating the delivery failure as a Volanea issue.

Sender and schema errors

A 4xx response commonly indicates a request that should be corrected before retrying: an unauthorized key, malformed JSON, invalid recipient format, unverified sender, or unsupported field. Retrying unchanged input can create unnecessary tasks without solving the problem.

A 5xx response or network error is more likely transient, but still requires idempotency protection. Alert on repeated failures and keep enough context to reproduce the event: LoyaltyLion customer ID, event time, non-secret request body, HTTP outcome, and Volanea response identifier. Never include the bearer token in that record.

Monitoring and operational ownership

Assign an owner for the whole flow, not only for the Zap. Marketing or loyalty teams may own copy and eligibility rules; a developer or operations owner may own API credentials, domain authentication, and incident response. Both need access to an understandable record of what happened.

A useful integration log contains the following fields:

• LoyaltyLion customer ID and trigger timestamp.
• Normalized recipient address, stored only where your privacy policy permits.
• Event name, such as new_customer.
• Idempotency key.
• Volanea request result and message identifier.
• Retry count and final disposition: sent, skipped, or failed.

Review this log after launch. Look for unexpected spikes, a high skipped-address rate, repeated customer IDs, or a sudden increase in API errors. Those patterns often reveal imports, changed trigger schemas, an expired key, or a newly unverified sender before recipients report a problem.

Set a measured alert threshold. One malformed imported record may be routine; a run of authorization failures requires immediate action because all future sends will fail until the credential or configuration is corrected.

Alternatives for more complex loyalty communication

Zapier is a practical route for one event and one message, especially while validating the programme experience. It is not always the final architecture.

A custom middleware service is a better fit when you need high throughput, strict ordering, detailed audit logs, multi-step customer lookups, advanced template selection, or custom retries. The service can receive the permitted LoyaltyLion event source, persist an event record, calculate eligibility, then call Volanea with controlled rate limits and idempotency.

An ecommerce or customer-data platform can also be the appropriate event source if it has the canonical consent state or richer lifecycle context. In that design, do not send the same welcome email from both the ecommerce source and LoyaltyLion. Pick one source of truth for each message type and document it.

For teams comparing API email providers, evaluate more than the initial integration screen. Look at sender-domain control, API documentation, observability, rate limits, credential management, suppression behavior, and the operational cost of handling retries. The relevant question is whether the infrastructure supports your event model reliably, not whether a logo appears in a marketplace.

Launch checklist

Before switching the Zap on, run through this checklist with a test record and then with a controlled production record:

1. Confirm the trigger is LoyaltyLion New Customer and understand what creates a customer in your account.
2. Inspect the real trigger sample and map its actual customer ID, email, and optional name fields.
3. Add a filter for a nonblank email and any consent or import exclusions required by your policy.
4. Authenticate the Volanea sending domain and use a verified from address.
5. Store the Volanea API key only in Zapier’s server-side request authentication or approved secret storage.
6. Use a stable idempotency key tied to the LoyaltyLion customer ID and event.
7. Test content, links, sender display, and delivery at a mailbox you control.
8. Verify task history and Volanea activity can be correlated with tags and identifiers.
9. Define an alert owner and a procedure for key rotation, duplicate sends, and missing addresses.

After activation, watch the first live events rather than assuming the test represents every record. The first edge case is usually a missing field or an unexpected import, and catching it early is much easier than repairing a batch of duplicate or incomplete messages.

FAQ

Does Volanea have a native LoyaltyLion integration?

No native LoyaltyLion marketplace app or Volanea plugin is required for this approach. The integration described here uses LoyaltyLion’s Zapier trigger, Zapier’s server-side webhook action, and Volanea’s REST API.

What LoyaltyLion event starts the email?

This guide uses the LoyaltyLion Zapier trigger named New Customer. It starts when a customer is added to LoyaltyLion. Confirm the exact trigger fields in your own Zap test before publishing the workflow.

Where should the Volanea API key be stored?

Store it in the server-side authentication header of the Webhooks by Zapier action, or in a secret store used by custom middleware. Never put it in storefront JavaScript, a public theme setting, email content, or a LoyaltyLion customer field.

How do I stop duplicate welcome emails?

Use the LoyaltyLion customer ID to create a stable idempotency key for the send and verify Volanea’s current idempotency behavior for your endpoint. Also log each event and investigate timeouts before manually rerunning tasks.

What if the LoyaltyLion trigger has no email address?

Filter out blank or invalid email values before the Volanea request. Log the customer ID as skipped and correct the upstream customer-data process; do not fabricate a recipient address or retry unchanged missing data.