How to Send Email from Easypromos with Volanea

Easypromos email integration can mean more than exporting entrants after a promotion ends. With Easypromos’ Zapier trigger, a server-side relay, and Volanea, you can send a timely transactional message when a new participant enters a promotion—without exposing an email API key in a public campaign, landing page, or browser.

This guide uses the New Participant trigger available in the Easypromos Zapier integration. It is deliberately not presented as a native Volanea app or Easypromos marketplace installation: Volanea does not ship one. Instead, Zapier receives the Easypromos event and forwards a tightly defined payload to middleware you control; that middleware validates the request and calls Volanea’s REST email API.

What this integration does

The practical flow is:

1. A person completes an Easypromos promotion and becomes a participant.
2. Easypromos makes that participant available to Zapier through the New Participant trigger.
3. A Zap sends selected participant fields to a private HTTPS endpoint.
4. Your endpoint validates the request, decides whether an email is appropriate, and calls Volanea.
5. Volanea sends the confirmation, reward notice, follow-up, or internal notification.

That separation matters. Easypromos remains the system that collects promotion participation. Zapier handles the event connection. Your relay owns consent checks, idempotency, templates, and credentials. Volanea is the sending layer.

This is a good fit for messages that are tied to a participant action, including:

• A confirmation that an entry was received.
• A message explaining when a winner will be selected.
• A coupon or reward delivery email, where promotion rules allow it.
• An internal alert for a high-value registration.
• A follow-up sequence only for participants who gave the required marketing permission.

It is not a reason to email every entrant for unrelated marketing. A promotion entry and marketing consent can be different things. Keep the legal basis, the promotion’s terms, the checkbox wording, and the audience selection separate in your implementation.

The real Easypromos trigger: New Participant

For this setup, the event that starts a send is New Participant in Zapier’s Easypromos integration. A participant is the person recorded after completing the promotion’s participation flow. This is more specific than treating a page view, social action, or form field interaction as an email event.

Create the Easypromos promotion first, then connect the Easypromos account in Zapier and select the relevant promotion when configuring the trigger. Use a real test participant when possible. Test data is important because Easypromos promotions can collect different fields depending on the promotion configuration: one campaign may require email and name, while another may collect only social data, a custom answer, or no usable email address at all.

Do not assume every participant has an email address

An email send requires an email address, but the New Participant event does not make every promotion automatically email-ready. The available trigger fields depend on the fields and authentication options enabled for that promotion.

Before building the send path, answer these questions:

• Is email a required participant field in this specific promotion?
• Is the address supplied directly by the participant, or returned from a social-login flow?
• Is the participant eligible to receive a transactional confirmation, a marketing follow-up, or both?
• Is there a custom opt-in field that must be true before promotional email can be sent?
• Will a participant who retries or edits an entry produce another event?

If the promotion does not collect email, do not create an artificial address mapping. Send an internal alert instead, or change the promotion design only if collecting email is necessary and properly disclosed.

Why use a middleware relay instead of a direct email action

Zapier can connect an Easypromos trigger to many actions, but sending to your own relay gives you operational controls that an all-in-one no-code path often lacks. It lets you reject malformed records, prevent repeated sends, look up a reward, calculate a template variable, and preserve a durable audit record.

It also keeps the Volanea API key off the promotion front end. Neither the Easypromos participant page nor browser-side JavaScript should contain an email-provider credential. Anyone who can view the page, inspect network traffic, or access a public configuration can potentially copy a client-visible key.

Architecture and field mapping

The safe architecture is not “Easypromos browser to Volanea.” It is an event pipeline:

Easypromos promotion
  → Zapier: New Participant
  → Zapier Webhooks POST action
  → your HTTPS relay
  → Volanea REST API
  → recipient inbox

Zapier is the adapter in this route. The JSON that reaches your relay is a payload you explicitly construct in the Zapier Webhooks action from the New Participant output. That is useful because it gives the relay a stable contract even when an Easypromos promotion has different optional custom fields.

Map only fields you actually need. For a basic entry confirmation, use a participant identifier, promotion identifier, email, name, and an optional marketing-permission value. Do not forward every answer, IP-related field, social profile value, or free-text response merely because it is available.

Recommended relay payload

In Zapier, add a Webhooks action after New Participant and configure it to POST JSON to an HTTPS endpoint such as https://automation.example.com/easypromos/participant. Map the trigger tokens into this exact request body:

{
  "event": "easypromos.new_participant",
  "participant_id": "{{New Participant Participant ID}}",
  "promotion_id": "{{New Participant Promotion ID}}",
  "email": "{{New Participant Email}}",
  "name": "{{New Participant Name}}",
  "marketing_opt_in": "{{New Participant Marketing Opt In}}",
  "created_at": "{{New Participant Created At}}"
}

The text in double braces is a mapping instruction, not a literal Easypromos API payload. Select the corresponding fields from the New Participant test record in Zapier. If your trigger exposes a differently named field—for example, a custom consent answer—use that field rather than inventing a value.

The resulting request received by your relay has a concrete, predictable shape like this:

{
  "event": "easypromos.new_participant",
  "participant_id": "p_8c8e2e31",
  "promotion_id": "promo_summer_draw_2026",
  "email": "riley@example.net",
  "name": "Riley Chen",
  "marketing_opt_in": "yes",
  "created_at": "2026-10-03T14:21:09Z"
}

This distinction is important: the Easypromos record drives the Zap trigger, while the Webhooks action sends the contract that you define. If a promotion has no Name field, send an empty string or omit it and make the relay handle that case. Do not make a downstream email fail because a nonessential personalization field is unavailable.

A minimal field-mapping table

Treat the participant ID and promotion ID together as the source event identity. An email address is not a reliable idempotency key: one person may enter two different promotions, and multiple legitimate participants may share a mailbox.

Send the Volanea email from server-side code

The following Node.js example implements the private relay. It accepts the Zapier POST body, requires a shared webhook secret, validates the fields, prevents a duplicate participant send, and makes the Volanea REST call.

Set the Volanea endpoint and key only as server environment variables. The example uses VOLANEA_API_URL rather than hard-coding a host so that the deployment follows the current endpoint documented in the email API reference and setup guides. Set it to the documented Volanea email-send URL for your account.

import express from "express";

const app = express();
app.use(express.json({ type: "application/json" }));

const sentEvents = new Set(); // Replace with Redis or a database in production.

app.post("/easypromos/participant", async (req, res) => {
  // Put this secret in the Zapier Webhooks action request headers:
  // X-Integration-Secret: <a long random value>
  if (req.get("X-Integration-Secret") !== process.env.EASYPROMOS_ZAPIER_SECRET) {
    return res.status(401).json({ error: "Unauthorized webhook" });
  }

  const {
    event,
    participant_id: participantId,
    promotion_id: promotionId,
    email,
    name = "",
    marketing_opt_in: marketingOptIn,
    created_at: createdAt
  } = req.body ?? {};

  if (event !== "easypromos.new_participant") {
    return res.status(400).json({ error: "Unexpected event" });
  }

  if (!participantId || !promotionId || !email) {
    return res.status(422).json({
      error: "participant_id, promotion_id, and email are required"
    });
  }

  // One confirmation per participant per promotion, even if Zapier retries.
  const idempotencyKey = `easypromos:${promotionId}:${participantId}:entry-confirmation`;
  if (sentEvents.has(idempotencyKey)) {
    return res.status(200).json({ status: "already_processed" });
  }

  const safeName = String(name).trim() || "there";
  const isMarketingEligible = String(marketingOptIn).toLowerCase() === "yes";

  // This example sends a transactional entry confirmation. Do not turn this
  // into a marketing send merely because an address was collected.
  const volaneaPayload = {
    from: {
      email: process.env.VOLANEA_FROM_EMAIL,
      name: process.env.VOLANEA_FROM_NAME
    },
    to: [{ email, name: String(name).trim() || undefined }],
    subject: "We received your promotion entry",
    html: `<p>Hi ${escapeHtml(safeName)},</p>
           <p>We received your entry for promotion ${escapeHtml(promotionId)}.</p>
           <p>Entry time: ${escapeHtml(createdAt || "not supplied")}.</p>`,
    text: `Hi ${safeName},\n\nWe received your entry for promotion ${promotionId}.\nEntry time: ${createdAt || "not supplied"}.`,
    tags: ["easypromos", "entry-confirmation"],
    metadata: {
      easypromos_participant_id: participantId,
      easypromos_promotion_id: promotionId,
      marketing_opt_in_at_event: isMarketingEligible
    }
  };

  const response = await fetch(process.env.VOLANEA_API_URL, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": idempotencyKey
    },
    body: JSON.stringify(volaneaPayload)
  });

  const responseBody = await response.text();
  if (!response.ok) {
    console.error("Volanea send failed", response.status, responseBody);
    return res.status(502).json({ error: "Email provider rejected the send" });
  }

  sentEvents.add(idempotencyKey);
  console.info("Entry confirmation accepted", {
    participantId,
    promotionId,
    providerResponse: responseBody
  });

  return res.status(202).json({ status: "accepted" });
});

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

app.listen(process.env.PORT || 3000);

The object under volaneaPayload is the field mapping that turns the Easypromos participant event into an email. email becomes the recipient, name becomes optional recipient and greeting data, and the two source IDs become metadata for support and reporting. Keep the send classification intentional: the code above is an entry confirmation, not a blanket marketing campaign.

In production, replace the in-memory Set with a persistent store. Redis, Postgres with a unique constraint, or a queue/database combination can safely remember that promotion_id + participant_id + message type was already sent across process restarts and multiple server instances.

Configure secrets and authentication safely

There are two separate secrets in this design, and they belong in different places.

First, the Volanea API key belongs only in your middleware environment—such as a deployment platform’s encrypted environment-variable store, a secret manager, or a server-side runtime configuration. It must not live in Easypromos custom code, a public page, a browser bundle, a URL parameter, or a Zapier field that is exposed to an untrusted user.

Second, the relay should require a shared webhook secret from Zapier. Put a long random value in the Webhooks action’s request header, for example X-Integration-Secret. Store the expected value as EASYPROMOS_ZAPIER_SECRET in the same server-side secret store. This does not replace HTTPS; it adds an application-level check so that an arbitrary internet client cannot invoke the email endpoint.

What lives on the Easypromos side

With the Zapier route, no Volanea credential is stored in Easypromos. Easypromos supplies the New Participant event to the connected Zapier account. The Zapier action contains the relay URL, selected field mappings, and the relay-specific shared secret header.

That architecture is preferable to attempting to place a Volanea bearer token in a participant-facing configuration. The participant page is client-visible by definition. A leaked sending key can be abused to send email, damage sender reputation, and create unexpected cost.

Limit the blast radius

Use separate Volanea credentials or projects for development and production where available. Use a verified From address that belongs to your organization, and do not accept a from value from the Easypromos payload. The sender identity should be controlled by your server.

Similarly, do not let participant data choose arbitrary HTML, subject lines, recipient lists, or tags. A custom answer can be useful for personalization, but it should be escaped and inserted only into approved template locations. The sample escapes HTML because participant-supplied names are untrusted input.

Consent, eligibility, and message type

A common implementation mistake is to turn every new participant event into a marketing email. The technical trigger is immediate, but permission is not automatically implied by the event.

An entry confirmation is generally connected to the participant’s action: it confirms receipt, communicates the promotion timeline, or provides the promised next step. A newsletter, product promotion, or unrelated discount is a separate purpose. If your campaign has an opt-in control, map that exact answer into marketing_opt_in and make the marketing branch explicit.

For example, the relay can always send a narrowly scoped entry receipt while only adding a participant to a future marketing audience when the consent value is the affirmative value configured in that promotion. Keep a record of the promotion ID, participant ID, consent result, and event time. That gives support staff context when a person asks why they received a message.

Before enabling the Zap, test these scenarios:

1. A participant with a valid email and no marketing opt-in.
2. A participant with a valid email and affirmative opt-in.
3. A participant record with no email field.
4. A repeated event for the same participant.
5. A malformed request sent directly to the relay without the secret.
6. An address that is syntactically valid but cannot receive mail.

For imports, reward fulfillment, or high-value sends, consider checking addresses with the free address verification tool before delivery. Verification is not a substitute for consent, but it can reduce obvious address-quality issues.

When this breaks

This pipeline has two network hops before an email is accepted: Easypromos to Zapier, then Zapier to your relay, followed by your relay to Volanea. Treat each hop as fallible.

Retries can create duplicate-send attempts

A webhook action can be retried when Zapier does not receive a successful response, when a connection is interrupted, or when a prior request times out. A retry may arrive after Volanea already accepted the first send. Without idempotency, the recipient may receive two entry confirmations.

The relay addresses that in two layers. It uses a source-derived idempotency key, and it passes the same key with the provider request. Persist the key before or atomically with the send state in a real database. A robust table might have a unique key on promotion_id, participant_id, and message_type, plus states such as pending, accepted, and failed.

Do not mark a message permanently sent before you know the provider accepted it. Conversely, do not simply retry every provider error indefinitely: some errors are permanent, such as an invalid recipient or an unverified sender identity.

Webhook timeouts can be misleading

A relay that renders a slow template, waits on a database lock, or blocks on a provider response can exceed an automation platform’s timeout. The caller may report a failure and retry even though the email request completed shortly afterward.

Keep the synchronous endpoint small. Validate, create or find the idempotency record, enqueue work, and return a successful response quickly. A background worker can call Volanea and update the final state. If you choose the simpler synchronous approach shown above, set conservative timeouts, log the provider response, and maintain idempotency.

Payload fields may be absent

Easypromos promotion configuration determines what participant information exists. A Name field, email field, custom consent field, and timestamp may not all be present in every plan, promotion type, or test record. Zapier also only exposes fields that the trigger supplies for the connected promotion.

Handle missing optional values deliberately. Name can fall back to a neutral greeting. An absent custom opt-in must mean “not eligible for marketing,” not “yes.” An absent email must stop the recipient send and create an internal log or alert. Do not use an empty string as a recipient and hope the provider catches it.

Field changes can silently break mappings

If a promotion manager renames, removes, or replaces a custom question, Zapier mappings can become blank or point to a different answer. Make the contract visible in code and documentation. Log the names of missing required fields, but avoid logging full participant records or email content unnecessarily.

Review the Zap after changing promotion settings. Submit a new test entry and inspect exactly what reaches the relay. This is especially important when duplicating promotions: a copied campaign can have superficially similar fields but different internal mappings.

Deliverability decisions still belong to the sender

Connecting a promotion event to an API does not guarantee inbox placement. Delivery depends on sender authentication, list quality, complaint rates, recipient engagement, and the relevance of the message.

Use a From domain that your organization controls and authenticate it according to the Volanea setup guidance. Keep the entry receipt recognizable: the sender name, subject, and body should make clear which promotion generated it. A subject such as “We received your promotion entry” is usually clearer than a vague marketing-style subject line.

Separate transactional confirmations from promotional follow-ups in your sending design. They may have different consent requirements, audiences, content, and performance expectations. Add source metadata such as easypromos_participant_id so that a support team can trace a message without putting sensitive promotion answers into the email headers or subject.

Watch for these signals after launch:

• A sudden rise in missing-email rejections, which may mean a promotion field changed.
• Duplicate confirmation complaints, which often indicate retry logic without idempotency.
• Spam complaints or unsubscribes from follow-up email, which can indicate a consent mismatch.
• A high bounce rate from a single promotion, which can point to low-quality entries or a confusing email field.

Alternatives and when to use them

The Zapier-plus-relay route is appropriate when you want an event-driven confirmation and do not need a native Volanea listing inside Easypromos. It is also the safer route when the promotion is managed by non-developers but the sending credentials and business rules need engineering control.

A direct custom integration may be appropriate only if your Easypromos plan and specific promotion configuration provide an outbound HTTP capability you have confirmed in your account, and if it can securely authenticate to a server you operate. Even then, send to your relay—not directly to Volanea with a bearer key—so the email credential remains server-side.

For low-volume internal notifications, you can keep the same New Participant trigger and post to a simple serverless function. For a large promotion, use a queue and worker. Queues absorb bursts when thousands of participants enter near a deadline and prevent a short provider slowdown from causing automation timeouts.

If the need is a one-time post-promotion newsletter rather than an immediate entry confirmation, export or sync only the appropriately consented audience, clean and segment it, then send a deliberate campaign. Event-driven automation is not inherently better; it is better when the timing is genuinely useful to the participant.

Launch checklist

Before turning the Zap on for a live promotion, complete this checklist:

• Confirm that the Easypromos trigger is New Participant for the intended promotion.
• Submit a real test entry and inspect the trigger output.
• Map only required fields into the relay JSON contract.
• Require email only if the promotion actually collects it.
• Define whether the message is transactional or marketing.
• Store the Volanea API key only in server-side environment variables.
• Add a private relay secret in the Zapier request header.
• Use a persistent idempotency store keyed by promotion and participant.
• Verify the From identity and test a real inbox at several mailbox providers.
• Test missing fields, duplicate delivery, provider failure, and an invalid address.
• Document who owns the Zap, the relay deployment, and sender-domain changes.

Once live, keep a small audit record for every event: the source IDs, event time, decision taken, idempotency key, provider acceptance result, and error code if one occurred. Avoid retaining more participant data than you need to operate and support the integration.

FAQ

Does Volanea have a native Easypromos plugin?

No. This integration uses Easypromos’ Zapier connection and a server-side relay; it is not an Easypromos marketplace app or native Volanea plugin.

What starts the email send?

The send starts from the New Participant trigger in Zapier’s Easypromos integration. Your Zap maps the participant record into a POST request to your relay.

Where should the Volanea API key be stored?

Store it only in your server or serverless environment’s secret manager or encrypted environment variables. Do not put it in a public Easypromos page, browser code, URL, or participant-visible configuration.

How do I prevent duplicate confirmation emails?

Create a persistent idempotency record using the Easypromos promotion ID, participant ID, and message type. Return a successful result for already-processed events so a retry does not create another send.

Can I email every new promotion participant with marketing?

Not automatically. Send marketing only when the participant has given the appropriate permission for that purpose. A promotion entry alone is not a universal marketing subscription.