How to Send Email From Stripo With Volanea

Stripo is excellent for designing responsive email HTML, while Volanea is built to deliver messages through an email API. To send email from Stripo with Volanea, treat the two products as distinct parts of one workflow: design and export in Stripo, then hand the exported HTML to a trusted server that calls Volanea.

That distinction matters. Stripo is not a contact database, automation platform, or event-triggered outbound-email system. It creates email templates. Volanea sends a specific message to a specific recipient when your application, backend, or campaign service makes an authenticated API request.

The important limitation: Stripo does not directly trigger a Volanea send

There is no native Volanea app, marketplace listing, or one-click Stripo-to-Volanea sending plugin. More importantly, a normal Stripo template does not contain the information an email-delivery API needs to make a safe send: a recipient address, a verified sending identity, a delivery purpose, suppression checks, and application-level authorization.

Stripo's meaningful action in this workflow is the editor's Export action. A user designs an email, sets its subject line and preheader, then exports the finished HTML or uses an available ESP export path. That is a template handoff, not an event such as “new contact created,” “form submitted,” or “deal stage changed.”

As a result, there is no universal Stripo outbound webhook payload that can be mapped directly to a Volanea email send. Stripo does not maintain the recipient list that Volanea would require, and you should not pretend that an exported design is itself a campaign-send instruction.

The practical architecture is:

1. A marketer or developer creates and approves an email in Stripo.
2. They export the HTML version of that template.
3. Your application stores that HTML in source control, object storage, a CMS, or a template table.
4. A trusted backend combines the template with recipient and business data.
5. The backend calls Volanea's REST API to send the resulting message.

This approach is less magical than a marketplace button, but it is safer, easier to audit, and far more useful for production email.

What actually starts an email send

The concrete trigger for delivery should happen in the system that owns the business event and recipient data, not inside the Stripo editor.

For transactional email, common real triggers include a user submitting a form, completing a purchase, requesting a password reset, or creating an account. For campaigns, a trigger might be a marketer pressing “send campaign” in your internal tool after audience selection and approval. Those events create a server-side instruction that includes both the recipient and the Stripo-created template version.

For example, an account-creation service might create this internal send job after a successful signup:

{
  "event": "user.created",
  "template": "welcome-v3",
  "recipient": {
    "email": "maya@example.com",
    "firstName": "Maya"
  },
  "data": {
    "dashboardUrl": "https://app.example.com/dashboard"
  }
}

That JSON is your application's payload, not a payload sent by Stripo. Making that boundary explicit prevents a common implementation mistake: exposing a delivery API key in a visual email editor or assuming a template export knows who should receive it.

Why the trigger belongs in your application

Your application can answer questions Stripo cannot answer on its own:

• Is this recipient opted in for this category of mail?
• Has the recipient previously unsubscribed or bounced?
• Is the sender domain verified and appropriate for this mail type?
• Is this event a transactional notification or promotional content?
• Has this exact event already caused a send?
• Which approved version of the template should be used?

Those are delivery and compliance decisions. Keeping them in a backend service gives you a reliable place to implement them before Volanea receives the request.

Build the Stripo template for a production handoff

A Stripo design is most portable when it is treated like a release artifact. Before exporting, complete the copy, preview the mobile layout, add meaningful link URLs, set the subject line and preheader, and send test messages through your normal QA process.

Use recognizable template names and versions. For example, welcome-v3, invoice-receipt-v5, and october-product-update-v2 are more useful than final-final-new. The template name becomes a stable reference in your application and makes it possible to answer which content a recipient actually received.

Use variables deliberately

Stripo can help you design a template with placeholder content, but your sending application must decide how those placeholders are rendered. Avoid treating arbitrary customer values as safe HTML. Names, account labels, product titles, and support messages should be HTML-escaped before being inserted into HTML markup.

A simple welcome template might contain placeholders such as:

<h1>Welcome, {{firstName}}</h1>
<p>Your workspace is ready.</p>
<p><a href="{{dashboardUrl}}">Open your dashboard</a></p>

Your backend should render the template only with an allowlisted data object. Do not let a browser submit raw html, from, to, or subject fields directly to an endpoint that can call Volanea. That would turn a helpful template endpoint into an open relay or an injection risk.

Keep a source copy outside the editor

Export the completed HTML and store it where your engineering and release workflow can track it. For many teams, that means a Git repository. For a marketing team that releases content more frequently, it may mean object storage plus a database record containing the template ID, version, approval status, subject, and preheader.

The stored record should identify the exact exported asset. A useful template record looks like this:

{
  "id": "welcome-v3",
  "source": "stripo",
  "status": "approved",
  "subject": "Welcome to Example",
  "preheader": "Your workspace is ready to use.",
  "htmlAsset": "s3://email-templates/welcome-v3.html"
}

That record is the bridge between a Stripo export and an operational Volanea send.

The payload: what Stripo exports and what Volanea needs

Because Stripo is the design/export layer in this setup, the item it produces is the rendered email HTML, along with the subject, preheader, and any assets referenced by the design. It does not inherently produce a recipient-specific REST request to Volanea.

Volanea, by contrast, needs a delivery payload. At minimum, that generally includes a verified sender, recipient, subject, and HTML body. Your server is responsible for mapping the exported template and the business-event data into that payload.

Here is a complete Node.js example. It loads HTML exported from Stripo, replaces two controlled placeholders, and makes the Volanea request from the server. The messageKey is an idempotency value generated from the underlying business event; it is not a random value generated on every retry.

// send-welcome-email.mjs
import fs from "node:fs/promises";
import crypto from "node:crypto";

const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;

if (!VOLANEA_API_KEY) {
  throw new Error("VOLANEA_API_KEY is required");
}

function escapeHtml(value) {
  return String(value)
    .replace(/&/g, "&")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/\"/g, "&quot;")
    .replace(/'/g, "&#039;");
}

async function sendWelcomeEmail({ userId, email, firstName, dashboardUrl }) {
  // This file is the HTML exported from Stripo and committed after approval.
  const stripoHtml = await fs.readFile("./templates/welcome-v3.html", "utf8");

  // Field mapping from application event data to Stripo placeholders.
  const html = stripoHtml
    .replaceAll("{{firstName}}", escapeHtml(firstName))
    .replaceAll("{{dashboardUrl}}", encodeURI(dashboardUrl));

  // A deterministic event key prevents a retry from becoming a second welcome email.
  const messageKey = crypto
    .createHash("sha256")
    .update(`welcome-email:${userId}`)
    .digest("hex");

  // Field mapping from the approved Stripo template and app event to Volanea.
  const volaneaPayload = {
    from: "Example Team <hello@updates.example.com>",
    to: [email],
    subject: "Welcome to Example",
    html,
    headers: {
      "X-Message-Key": messageKey,
      "X-Template-Version": "welcome-v3"
    }
  };

  const response = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": messageKey
    },
    body: JSON.stringify(volaneaPayload)
  });

  if (!response.ok) {
    throw new Error(`Volanea send failed: ${response.status} ${await response.text()}`);
  }

  return response.json();
}

await sendWelcomeEmail({
  userId: "usr_123",
  email: "maya@example.com",
  firstName: "Maya",
  dashboardUrl: "https://app.example.com/dashboard"
});

The mapping in that example is intentional:

Before deploying, compare the endpoint and optional idempotency-header support with the current email API reference and setup guides. API credentials, sending domains, and available message fields should be configured according to the account's current documentation.

Where the Volanea API key belongs

The Volanea API key belongs only in a server-side secret store or environment variable. In the example, it is read as process.env.VOLANEA_API_KEY, which means the key is available to the backend process but is never shipped to the visitor's browser.

Do not put the key in any of these places:

• A Stripo template's HTML, CSS, JavaScript, or custom block.
• A public frontend environment variable such as NEXT_PUBLIC_* or VITE_*.
• A browser-side fetch call.
• A link query string, form field, spreadsheet, or client-visible configuration object.
• A repository committed to source control.

A sender API key authorizes delivery. Anyone who can extract it can potentially send mail as your account, consume quota, damage the reputation of your sending domain, or create an abuse incident. Moving the key to a server is not merely tidier architecture; it is a critical access-control requirement.

Safe secret handling patterns

For a small application, use a hosting provider's encrypted environment-variable facility. For larger deployments, use a dedicated secrets manager and grant the sending service access through a workload identity or narrowly scoped runtime role.

Rotate keys when staff changes, when a credential could have been exposed, or on a deliberate schedule. Keep separate development and production credentials so a staging test cannot accidentally deliver from your production sending identity.

A practical middleware route for campaign tools

Some teams want a marketer-facing workflow rather than a direct call from application code. In that case, build a small internal campaign service between Stripo and Volanea.

The campaign service should accept only a template identifier and a selected audience identifier. It should retrieve the approved HTML itself, render the allowed merge data, enforce audience rules, and call Volanea. This is much safer than allowing a browser to post arbitrary HTML and recipient addresses.

A simple internal request might look like this:

{
  "templateId": "october-product-update-v2",
  "audienceId": "customers-us-opted-in",
  "requestedBy": "marketing@example.com"
}

The service can then create a campaign job, snapshot the recipient audience, and enqueue one delivery job per recipient. If you use an automation product such as Make or Zapier elsewhere in your stack, let it call this internal campaign endpoint after an approval event. Do not give that automation a broad Volanea key in a client-facing step, and do not make the Stripo export itself the send trigger.

Why an approval stage is valuable

Campaign mail has a different risk profile from a password-reset or receipt email. Add an approval state before an audience send, especially when the content was recently exported from a design tool.

A useful process is:

1. Design and test the email in Stripo.
2. Export and register a versioned HTML asset.
3. Preview the rendered content with representative merge data.
4. Send a seed test to internal reviewers.
5. Mark the template approved.
6. Create the campaign audience and take a recipient snapshot.
7. Queue sends through the Volanea-backed service.

The snapshot matters because a campaign should have a defined audience at the moment it is approved. Otherwise, a late data import or preference change can produce surprising results between review and delivery.

Transactional and campaign mail need different controls

The same exported Stripo HTML can be used in different types of email, but the sending rules should differ.

A transactional message is connected to an action the recipient took or an account relationship that requires a notice. Examples include verification links, payment receipts, account alerts, and support updates. It should be sent promptly and should not be blocked behind a large marketing queue.

Campaign email is promotional or editorial content distributed to an audience. It needs consent handling, an unsubscribe mechanism, frequency controls, audience exclusions, and a more deliberate review workflow.

Separate template identity from email category

Do not rely on the template name alone to determine whether a message is transactional. A template called account-update could be a required security notice or a marketing announcement depending on the calling event.

Instead, set a category in your sending service and enforce category-specific policy. For example, a marketing job can require an opted-in audience and an unsubscribe link, while a transactional job can require a recognized application event and a smaller sender allowlist.

This separation also improves deliverability analysis. If marketing engagement falls, you can investigate campaign content and list quality without confusing the result with password-reset delivery.

When this breaks: failure modes in this specific handoff

A Stripo-to-Volanea workflow has multiple boundaries: template export, asset storage, rendering, job creation, and the delivery API call. Troubleshoot the boundary that failed rather than treating every problem as an email-provider problem.

A retry causes duplicate email

Retries are necessary when a network request times out or a worker crashes after submitting a request. But a retry can create duplicates if the first request reached Volanea and the response was lost.

Use a stable idempotency key generated from the underlying event, such as password-reset:<reset-token-id> or receipt:<invoice-id>. Store the event-to-message result in your database before marking the job complete. Never generate a new random idempotency value for every attempt; that defeats the purpose.

For campaign sends, deduplicate at two levels: one campaign-recipient record per campaign and recipient, plus a stable message key derived from that record. This prevents queue retries, operator clicks, and automation reruns from creating multiple messages.

The API request times out

A timeout does not prove that Volanea did not receive the request. First look up the job using your own event key, template version, recipient, and delivery logs. If the job may have been accepted, retry with the same idempotency key rather than issuing a fresh unrelated send.

Keep the HTTP request short and asynchronous from the perspective of your web application. A signup request should create a send job and return after the account is created; a worker can then render and deliver the welcome email. This protects the user experience from temporary email API latency.

A template field is missing

The export can succeed while runtime rendering fails. A customer may have no first name, an expected URL may be unavailable, or an imported field may use a different name than the template expects.

Define defaults for optional values, such as there when firstName is absent. For required values, fail the job before calling Volanea and send it to an operational review queue. Never silently deliver an email containing raw placeholders such as {{firstName}} or a broken {{dashboardUrl}} link.

This is also where plan and product differences matter. Do not assume that every Stripo workspace, export format, integration option, or collaboration feature is available to every account. Validate the specific export route available in your Stripo plan during implementation, and keep the final rendered HTML in your own controlled storage rather than making delivery depend on an editor session.

Images or links fail after export

An email can render perfectly in the editor while its assets fail in a mailbox. Check that images use publicly reachable HTTPS URLs, that links use their intended production domains, and that tracking parameters do not break existing query strings.

Run an HTML preview and send seed messages to major mailbox providers before approving a large campaign. A message body that is technically accepted by an API can still have layout, clipping, image, or link problems in recipient clients.

The sender is rejected or authentication is weak

Your from address must use a domain configured for sending. If a message is rejected, verify the sender identity and the domain's authentication setup before repeatedly retrying the same request.

Keep the visible sender consistent with the mail type. Product notices, support mail, and marketing updates may deserve different local parts or subdomains, but they should all be intentional and authenticated. Sudden, unexplained changes in sender identity are bad for recipient trust and can complicate deliverability troubleshooting.

Testing the complete path before production

Test more than the API's success response. A successful response means the API accepted a request; it does not guarantee that the template is personalized correctly, images load, links work, or a recipient should have received the message.

Create a small test matrix that covers:

• A normal recipient with every merge field populated.
• A recipient missing optional profile data.
• Values containing apostrophes, ampersands, angle brackets, and accented characters.
• A long subject line and a mobile-width preview.
• A duplicate delivery attempt using the same event ID.
• A deliberately invalid sender or malformed recipient to confirm failures are visible.
• An opted-out marketing recipient to confirm suppression logic works.

Log a correlation ID for every step: the business event, template version, recipient record, queue job, Volanea response, and any provider message identifier returned by the API. Those records make it possible to tell whether an issue originated in content preparation, your application, or delivery.

Operational practices that protect deliverability

A polished Stripo template does not by itself create good inbox placement. Deliverability is the outcome of technical authentication, recipient expectations, content quality, sending consistency, list hygiene, and complaint handling.

Start with a small, engaged audience for a new campaign stream. Avoid importing old or uncertain addresses and immediately sending a high-volume campaign. Remove hard bounces from future campaign targeting, honor unsubscribes promptly, and investigate complaint spikes rather than simply increasing volume.

For transactional mail, make content immediately recognizable and keep the sender stable. For marketing mail, make the reason for receiving the message clear and provide a straightforward way to opt out. If an address enters your system from a form or third-party source, verify its quality before it enters a campaign audience; Volanea's email address verification tool can be useful as one check in that broader process.

Choosing the right integration boundary

It can be tempting to search for a direct visual-tool connection because it appears faster. But the best boundary is usually the one that preserves the responsibilities of each system.

Stripo should own visual design, responsive email construction, and template review. Your application or campaign service should own recipients, consent, data rendering, scheduling, and authorization. Volanea should own the authenticated delivery request and delivery infrastructure.

That division means a designer can improve a template without receiving access to delivery credentials, while an engineer can change sending policy without editing a layout. It also means that an accidental template change cannot automatically send to an entire customer list.

Conclusion

To send email from Stripo with Volanea, do not look for a nonexistent native send button. Export the approved Stripo design, store and version its HTML, then let a server-side application render approved data and make the authenticated Volanea API request.

The result is a workflow that is secure, testable, and appropriate for both transactional and campaign mail. Most importantly, it keeps the Volanea API key and recipient decision-making out of client-visible template tooling, where they do not belong.

FAQ

Can Stripo send directly to Volanea?

Not as a native Volanea marketplace integration or a recipient-aware automated send flow. Use Stripo to create and export the template, then use a backend or campaign service to send the rendered email through Volanea.

What is the Stripo trigger for this integration?

The Stripo-side action is a manual template Export. It produces a design artifact, not a recipient-specific send event. The actual delivery trigger should be a backend business event, such as account creation, purchase completion, or campaign approval.

Should I put my Volanea API key in a Stripo template?

No. Store it only in a server-side secret or encrypted environment variable. A key included in browser-visible code, exported HTML, or a template configuration can be exposed and abused.

How do I prevent duplicate messages after a timeout?

Create a deterministic idempotency key from the underlying event or campaign-recipient record, persist the send state, and use the same key on retries. Do not create a new random key for each retry.

Can I use one Stripo template for transactional and marketing email?

You can reuse the visual structure, but your sending service should enforce different rules. Marketing messages need consent, suppression, and unsubscribe controls, while transactional messages should be tied to a legitimate application event.