How to Send Email From Skyvia With the Volanea API

Skyvia can coordinate the business event, while Volanea can deliver the message. This guide explains how to send email from Skyvia without pretending there is a native Volanea app or marketplace plug-in: use Skyvia Automation’s webhook-based workflow capability and a server-side relay that calls the Volanea REST API.

The integration architecture: Skyvia, a relay, and Volanea

There is no native Volanea connector, Skyvia marketplace listing, or one-click Volanea installation to configure. That matters because a workable integration needs to be honest about where each responsibility sits.

The practical pattern is a three-part flow:

1. A source system creates an event payload, such as a new lead, completed form, paid invoice, or changed customer status.
2. A Skyvia Automation package begins at its Webhook trigger and passes the relevant data to an outbound HTTP endpoint you control.
3. Your endpoint validates the request, maps the fields, and makes the authenticated Volanea REST API request that sends the email.

This is deliberately a server-to-server design. Skyvia handles the automation boundary; the relay holds the secret and turns the event into a tightly controlled email request; Volanea handles sending and delivery infrastructure.

It can sound more involved than directly pasting an email API key into an automation request. In production, though, the relay is useful. It keeps credentials out of client-side code and event payloads, gives you a stable place to enforce recipient rules, and gives you an idempotency layer when a workflow is retried.

What starts the email in Skyvia

Skyvia Automation supports a Webhook trigger. A webhook-triggered Automation package starts when an external system makes an HTTP request to the URL Skyvia provides for that trigger. It is an inbound event to Skyvia, not a native “Volanea event” and not a record listener inside a fictional Volanea connector.

For a concrete example, use a form submission as the event that starts the send:

• A website form backend receives a request for a product demo.
• That backend posts the newly submitted contact details to the Skyvia Automation webhook URL.
• The webhook trigger starts the Automation package.
• The package forwards an approved subset of the form data to your email relay.
• The relay sends a “we received your request” transactional email through Volanea.

The same architecture applies if the originating event is a CRM record created or a deal stage changed. In those cases, use the source application’s webhook or an integration layer to post the event into the Skyvia Webhook trigger. Do not assume Skyvia watches every source table in real time; whether a specific source can emit an event depends on that source and the Skyvia feature you are using.

Define the event contract before building the automation

A common source of brittle integrations is treating the incoming event as an unstructured blob. Define the minimum contract first. For the demo-request example, the data Skyvia receives can be:

{
  "event": "demo_request.created",
  "eventId": "frm_01JQ7H8NPKM2V74D7F4AXT0S8R",
  "email": "ada@example.com",
  "firstName": "Ada",
  "company": "Analytical Engines Ltd",
  "requestedAt": "2026-09-24T10:15:00.000Z"
}

eventId is not optional in a dependable design. It gives downstream systems a stable identity for one business event. A plain timestamp is a poor substitute because two submissions can share a timestamp and one submission can be replayed later.

The address should be supplied by the server that accepted the form, not by browser code calling Skyvia or Volanea directly. That arrangement lets the form backend apply its own validation, rate limiting, CAPTCHA checks, and consent rules before an email workflow begins.

Configure Skyvia as the workflow hop

Create an Automation package with a Webhook trigger, then use the package’s HTTP-request capability to call a relay endpoint. Refer to the current Skyvia Automation documentation while configuring the package because available actions and input controls can vary by account, product edition, and plan.

The essential configuration is straightforward even though the exact package editor controls can change:

• The trigger is Webhook and accepts a POST from the system that owns the event.
• The incoming body is JSON with the event contract shown above.
• The outbound request is POST https://automation.example.com/skyvia/demo-request.
• The outbound request sends JSON and includes an integration-specific shared secret header.
• The relay returns a fast success response after it has accepted or deduplicated the event.

Your outbound request body should preserve only the fields needed for this one email. For example:

{
  "event": "demo_request.created",
  "eventId": "frm_01JQ7H8NPKM2V74D7F4AXT0S8R",
  "email": "ada@example.com",
  "firstName": "Ada",
  "company": "Analytical Engines Ltd",
  "requestedAt": "2026-09-24T10:15:00.000Z"
}

This is the real payload shape sent by the configured HTTP step in this example: JSON fields from the incoming webhook are mapped into an explicit outbound JSON body. Map each field by selecting the corresponding trigger input in Skyvia’s editor rather than relying on position or an entire unfiltered payload. In particular, map email to email and eventId to eventId; do not map a display-name field into the recipient field.

Keep the event payload boring

Do not put an HTML document, raw API key, or arbitrary user-entered object into the Skyvia payload. A small event contract is easier to version and safer to log.

If you later need a new field, such as a product name, add it as an optional named property and make the relay supply a reasonable fallback. Removing or renaming an established property is a breaking change. Versioning with an event name such as demo_request.created.v2 is clearer than silently changing the meaning of company.

The Volanea request that actually sends the email

The relay, not Skyvia and not a browser, should hold the Volanea API key. The following Node.js example accepts the payload forwarded by Skyvia, checks the shared secret, deduplicates the event, maps the fields, and calls Volanea’s REST email-send endpoint.

Before deploying, set the sending domain and sender address in Volanea and verify the exact endpoint, required headers, and current request schema in the email API reference and setup guides. The example uses a JSON REST request with a Bearer API key and keeps all message construction on the server.

import express from "express";
import crypto from "node:crypto";

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

const {
  SKYVIA_RELAY_SECRET,
  VOLANEA_API_KEY,
  VOLANEA_FROM = "Acme Team <hello@notify.example.com>"
} = process.env;

// Use Redis, Postgres, or another durable store in production.
const processedEvents = new Set();

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

app.post("/skyvia/demo-request", async (req, res) => {
  const suppliedSecret = req.get("x-skyvia-relay-secret") || "";
  const expectedSecret = SKYVIA_RELAY_SECRET || "";

  if (!expectedSecret || !crypto.timingSafeEqual(
    Buffer.from(suppliedSecret.padEnd(expectedSecret.length)),
    Buffer.from(expectedSecret)
  )) {
    return res.status(401).json({ error: "unauthorized" });
  }

  const { event, eventId, email, firstName, company, requestedAt } = req.body;

  if (event !== "demo_request.created") {
    return res.status(400).json({ error: "unexpected event" });
  }
  if (!eventId || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email || "")) {
    return res.status(422).json({ error: "eventId and a valid email are required" });
  }

  if (processedEvents.has(eventId)) {
    return res.status(202).json({ status: "already_accepted", eventId });
  }

  const safeName = escapeHtml(firstName || "there");
  const safeCompany = escapeHtml(company || "your team");
  const submittedAt = escapeHtml(requestedAt || "");

  const volaneaPayload = {
    from: VOLANEA_FROM,
    to: [email],
    subject: "We received your demo request",
    html: `
      <p>Hi ${safeName},</p>
      <p>Thanks for requesting a demo. We received your request for ${safeCompany}.</p>
      <p>Our team will be in touch shortly.</p>
      <p style="color:#666;font-size:12px">Request received: ${submittedAt}</p>
    `,
    text: `Hi ${firstName || "there"},\n\nThanks for requesting a demo. We received your request for ${company || "your team"}. Our team will be in touch shortly.`,
    headers: {
      "X-Source-Event": eventId
    }
  };

  const response = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Accept": "application/json"
    },
    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_request" });
  }

  processedEvents.add(eventId);
  console.info("Email accepted", { eventId, responseBody });
  return res.status(202).json({ status: "accepted", eventId });
});

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

The meaningful field mapping is in volaneaPayload:

Do not use user-provided data for from, a reply-to address, raw headers, or arbitrary HTML. Keep those values under application control. Otherwise a form submission can become a route for header abuse, misleading mail, or unsafe markup in your own template.

Keep Volanea authentication out of Skyvia and the browser

The Volanea API key belongs in a server-side secret store, such as a cloud-function environment variable, a managed secrets service, or the encrypted configuration facility provided by your hosting platform. In the example, it is read as VOLANEA_API_KEY from process.env.

Do not embed it in any of these places:

• Website JavaScript, mobile app code, or a public form configuration.
• A URL query string, which may be retained in proxies, browser history, analytics, and logs.
• A Skyvia webhook body or a field copied from the originating record.
• An email template, a repository, a support ticket, or a screenshot.

A key in client-visible configuration is effectively public. Anyone with it can potentially send mail from your account, consume your sending allowance, harm domain reputation, or use the account for phishing. Rotating a leaked key is necessary, but it does not undo mail that was already sent.

The relay also needs its own authentication. The x-skyvia-relay-secret header in the example is a simple shared secret between the configured Skyvia HTTP request and the relay. Store that secret in Skyvia’s secure connection or secret configuration if your plan exposes one; otherwise, prefer a middleware product with protected credential storage instead of placing it in a record field or public client app.

For stronger verification, use a signed request scheme if the product initiating the first webhook supports it. A signature with a timestamp and body hash protects against tampering and helps reject replayed requests. A static header alone should be rotated periodically and treated as a credential.

Why a relay is better than a direct API call

If your Skyvia account has an HTTP request action that can attach protected headers, you may be tempted to call Volanea directly from the Automation package. That can be appropriate for a low-risk internal notification, but it should be a conscious decision rather than the default.

A relay adds several controls that workflow configuration alone often cannot provide cleanly:

Validation and policy

The relay can reject malformed recipient addresses, cap message size, allow only approved sender identities, and enforce an event allowlist. It can check whether a contact has opted out of non-transactional communications before sending. It can also use an address-verification step before a high-volume import; Volanea provides a free email address verification tool for checking individual addresses.

Template ownership

A code-based template makes subject lines, sender identities, plain-text alternatives, and HTML escaping reviewable in source control. Skyvia remains the place where the business event flows, while the application owns message content and email policy.

Observability and recovery

The relay can log the event ID, a hashed recipient identifier, provider response status, and message identifier without logging the whole body or a secret. It can queue a transient failure for retry without making the source system wait for a provider response.

That separation makes incident analysis much easier. You can answer whether Skyvia received the event, whether it reached the relay, whether the relay accepted it once, and whether Volanea accepted the send request.

When this breaks: failures at the Skyvia-to-email hop

Every automation crossing a network boundary eventually encounters a timeout, malformed input, or replay. Design for those outcomes before enabling a customer-facing message.

Skyvia retries can cause duplicate sends

An HTTP request can succeed at Volanea while the response back to Skyvia is lost or delayed. From Skyvia’s perspective, the action may look failed and be retried. If every retry immediately calls the send endpoint, one form submission can produce two or more confirmation emails.

The eventId check is the first defense. In real deployment, replace the in-memory Set with a durable record keyed by event ID. Store the state before or during the send attempt, use an atomic insert or unique constraint, and keep enough information to distinguish these states:

1. The event has never been accepted.
2. The relay accepted it and is still attempting delivery.
3. Volanea accepted the email request.
4. The attempt failed before provider acceptance and may be retried safely.

Do not mark an event complete merely because Skyvia invoked the relay. Mark it after the relay has a provider acceptance result, or use a queue with an idempotent worker. The right behavior after an ambiguous provider timeout depends on the provider’s idempotency support and your product’s tolerance for a duplicate versus a missing message.

Webhook and request timeouts

A webhook-triggered package and an outbound HTTP action are both subject to request timeouts. Long-running synchronous work is fragile: template generation, CRM lookups, file creation, and provider calls can exceed the workflow’s available time.

Respond quickly from the relay with 202 Accepted once the event has been validated and durably queued or deduplicated. Then send asynchronously. This reduces the chance that Skyvia retries because it did not receive a timely response, and it prevents a temporary Volanea API slowdown from blocking the entire Automation run.

Use short, explicit connection and total-request timeouts in the worker. Retry only failures that can plausibly recover, such as network errors and some 5xx responses. Do not blindly retry a 4xx validation error: an invalid from identity or malformed recipient will not become valid because you ask again.

Payload fields may be absent

Not every source event includes every field, and Skyvia feature availability can differ by plan or configured action. A field that exists in a test webhook can be absent in a later source-system event. Empty strings, null, and missing properties should be handled separately.

For the confirmation email, email and eventId are required; reject the request if either is missing. firstName and company are optional; use safe fallbacks. Do not create a message addressed to an empty value, the literal string undefined, or an unreviewed fallback address.

Keep the relay’s validation errors actionable. A 422 response stating that eventId and a valid email are required is useful. A generic 500 is not. Where Skyvia exposes run history, correlate failures using the event ID rather than publishing recipient addresses in logs.

Authentication failures and secret rotation

A 401 from the relay usually means the Skyvia-to-relay secret is absent, wrong, or rotated on only one side. A provider authentication failure usually means the Volanea API key is missing, invalid, revoked, or loaded from the wrong environment.

Rotate in stages when possible: add a new accepted relay secret, update Skyvia, verify a test event, then remove the old secret. For the Volanea key, update the server-side secret, deploy or restart the worker as required by your platform, send a controlled test, and revoke the previous key only after the new one is working.

Test the workflow without emailing real customers

Build the flow with a test recipient you control and a sender identity configured for a non-production environment. Make the test event clearly identifiable in the subject or metadata, but do not put a raw secret in the test payload.

A useful test sequence is:

1. Post a valid sample payload to the Skyvia Webhook trigger and verify the Automation run starts.
2. Verify the relay receives the expected fields and rejects a request with an invalid shared secret.
3. Confirm one accepted Volanea API request results from one event ID.
4. Repeat the exact same event ID and confirm the relay returns an already-accepted result rather than sending again.
5. Remove email, then remove eventId, and confirm both failures are explicit and safe.
6. Simulate a slow or failed provider response and confirm Skyvia does not generate uncontrolled duplicate mail.

Test HTML and text output in multiple mail clients. A message that looks correct in a browser can have poor contrast, clipped content, or broken layout in an inbox. Keep transactional templates conservative: semantic HTML, simple tables where needed for compatibility, useful preheader text, and a plain-text alternative.

Deliverability implications of automation-triggered mail

Automating an email send does not change email authentication or recipient expectations. The sender domain still needs the DNS records and authentication required by your email provider, and messages still need to be relevant to the event that triggered them.

For a demo request, a confirmation email is normally transactional because it confirms an action the recipient just took. A weekly sales campaign sent to every new lead is a different category of communication and should follow consent, suppression, and campaign policies appropriate to your jurisdiction and audience.

Separate message streams where your sending setup supports it. Password resets, payment receipts, product alerts, and marketing messages have different urgency, engagement patterns, and complaint risk. A sudden automation bug that sends a promotional template to thousands of records can affect the reputation needed for important account emails.

Use a recognizable sender, a truthful subject, and content tied directly to the event. Avoid inserting unvalidated CRM text into subject lines. Track acceptance and delivery events in your email system, but remember that provider acceptance is not identical to inbox placement or a human reading the message.

Alternatives when a direct Skyvia HTTP step is not available

Account capabilities and plans matter. If your Skyvia plan does not expose the outbound HTTP capability needed to call a relay, do not try to work around that limitation by exposing a Volanea key in a public form or by claiming a native integration exists.

Use middleware that can securely receive an event and make authenticated HTTP requests, such as a small serverless function or an automation service with protected connection credentials. The sequence remains the same:

Source event -> Skyvia Webhook trigger or source webhook -> secure middleware -> Volanea REST API

If Skyvia cannot make the outbound request on your account, the middleware can receive the source event directly and optionally notify Skyvia separately for data synchronization. Keep the email-sending path independent from a nightly data-sync job when the user expects an immediate confirmation.

The decision is less about avoiding code and more about control. A no-code middleware route can be reasonable for low volume if it offers secret storage, retry visibility, and a way to prevent duplicates. A serverless relay is often the better choice when you need custom templates, event logging, allowlists, queueing, or strong idempotency.

Production checklist

Before turning on a Skyvia-driven send, verify the full path rather than only the happy path.

• Confirm that the source system sends the expected JSON to the Skyvia Webhook trigger.
• Confirm that the Skyvia package forwards only required fields to the relay.
• Store the Volanea API key only in server-side secrets.
• Authenticate the Skyvia-to-relay request with a protected credential or signature.
• Require a stable eventId and enforce durable idempotency.
• Validate recipient addresses and escape every user-controlled value rendered into HTML.
• Use an approved, authenticated sender domain and a plain-text message alternative.
• Return quickly from the relay and move slow sends to a queue where possible.
• Log event IDs and provider outcomes without recording keys or unnecessary personal data.
• Test retries, missing fields, unauthorized requests, and provider failure responses.

This pattern gives you a controlled way to send email from Skyvia while keeping the actual email API credential and delivery logic where they belong: on a secure server boundary.

FAQ

Can I install Volanea from the Skyvia marketplace?

No. This integration does not rely on a native Volanea Skyvia app or marketplace plug-in. It uses a Skyvia Automation Webhook-triggered workflow plus an authenticated HTTP relay that calls the Volanea REST API.

What Skyvia trigger starts the email flow?

In this guide, the Skyvia Automation Webhook trigger starts the package when the source system posts a form-submission event. A CRM-created-record or stage-change event can use the same pattern if the originating system can deliver that event to the webhook.

Should I put my Volanea API key in the Skyvia payload?

No. Keep the key in a server-side secret store used by the relay. Never expose it in browser code, a webhook payload, a source record, a query string, or a public configuration file.

How do I stop retries from sending duplicate emails?

Include a unique eventId in every event and enforce idempotency in a durable database or queue. If Skyvia retries after a timeout, the relay should recognize the same event ID and return an accepted or already-processed response instead of making another provider send request.

What if optional Skyvia fields are missing?

Treat them as optional in the relay and use safe defaults. Treat recipient email and event ID as required, reject malformed events with a clear 422 response, and do not send to an empty or fallback recipient address.