How to Send Email From Shogun With Volanea

Shogun is excellent for publishing ecommerce landing pages, but its native Form Box is not an outbound HTTP automation tool. To send email from Shogun through Volanea, use an embedded custom form that posts to middleware such as Make, then make the authenticated Volanea REST API request from that private server-side step.

The important limitation: Shogun does not offer a native Volanea integration

There is no native Volanea app, Shogun marketplace plugin, or one-click connection to install. More importantly, Shogun's documented Form Box flow is built around collecting a visitor submission and sending that submission to an email address, with an optional direct Klaviyo destination for the supported integration.

That distinction matters because a form notification is not the same thing as a programmable webhook. Shogun's standard Form Box settings let you name a form, choose where its submissions are sent, show a success message, and optionally redirect the visitor. The documented export flow stores submissions in Shogun's Form Data area and exports them as CSV files. Shogun's own support documentation also says that linking its native form to a third-party mailing list is not available without using a third-party form.

So the honest architecture is not:

1. Create a Shogun Form Box.
2. Add a Volanea API key to Shogun.
3. Tell Shogun to call Volanea.

That flow does not exist.

Instead, the reliable architecture is:

1. Add a custom HTML form to a Shogun page using Shogun's HTML element.
2. On submit, send the visitor's form data to a Make Custom Webhook or your own server endpoint.
3. Validate, normalize, and deduplicate the submission in middleware.
4. Call POST https://api.volanea.com/v1/send from middleware.
5. Keep the Volanea API key entirely outside the page source and browser.

This is still a Shogun-to-Volanea integration in practical terms: the visitor starts on a Shogun page, submits a lead or contact form, and gets the appropriate transactional email. But it is not a native direct webhook from Shogun, and treating it as one creates security and delivery problems.

What starts the email send in Shogun

The concrete trigger is a visitor submitting the embedded custom form on a published Shogun page.

Do not confuse this with a Shogun Form Box submission. A native Form Box submission goes through Shogun's documented form-submission handling and can be emailed to the address configured in the Form Box. It does not expose a documented destination URL where you can configure an outbound JSON webhook to Volanea or Make.

For this integration, the trigger is a form you own and embed through Shogun's HTML element. The page is still designed, published, and hosted in the Shogun experience, but the HTML form's submit event sends data to your middleware endpoint.

That gives you control over the payload. It also means you must own the form contract rather than assuming Shogun will emit an undocumented payload shape.

The payload is defined by your embedded form

Because the native Shogun Form Box does not provide a documented custom-webhook payload, there is no genuine Shogun-generated JSON webhook schema to copy here. The payload below is the exact JSON sent by the embedded form code in this guide.

That is a benefit, not a drawback. You can make email, first_name, and interest stable field names, add a submission identifier, and evolve the contract deliberately. Make receives the same named fields every time rather than trying to infer labels from a CSV export or an email notification.

Use descriptive, machine-friendly names for form controls. Avoid names such as field1, question_2, or labels that marketing teams frequently rename. Your middleware should be able to keep working even when you change the visible label from “What are you shopping for?” to “Tell us what you need.”

Choose the right middleware route

For a no-code implementation, Make is a practical middle layer because its Custom Webhooks module can receive requests at a generated URL and trigger a scenario immediately. The next module can use HTTP > Make a request to call Volanea.

Zapier can serve the same role with a Webhooks by Zapier Catch Hook trigger followed by an API request action. However, this guide uses Make because its scenario model makes it straightforward to inspect the incoming payload, apply filters, and control error handling in one route.

Recommended flow: embedded form to Make to Volanea

Use this pattern when you need a fast deployment and accept that your Make scenario is the workflow owner:

• Shogun HTML element: renders the lead or contact form.
• Browser: submits JSON to a Make Custom Webhook URL.
• Make Custom Webhook: parses the submission and starts the scenario.
• Make filters and tools: validate required fields and build values for the email.
• HTTP > Make a request: performs the authenticated Volanea POST /v1/send request.
• Volanea: accepts the transactional message and processes delivery asynchronously.

The Make webhook URL will be visible in the rendered page, because the browser needs somewhere to send the form. Treat that URL as public input, not as a secret. It must never be confused with your Volanea API key.

Production-hardened flow: embedded form to your endpoint to Volanea

For higher-volume forms, sensitive submissions, or strict abuse controls, put a small server endpoint between the page and Volanea. A serverless endpoint on your existing application, Cloudflare Worker, Vercel function, or similar platform can verify an anti-bot token, rate-limit requests, create a durable submission record, and send the message using Volanea.

This route has an important operational advantage: your application can return a response to the visitor quickly while queuing email work safely. It also gives you a database-backed idempotency record rather than relying only on a transient automation run.

If you do not want to write backend code, Make is appropriate. If the form sends account information, order changes, personal data, or a meaningful volume of emails, a small owned endpoint is usually the more durable design.

Build the form in Shogun

In Shogun, add an HTML element to the page where the form should appear. Paste the markup below and replace https://hook.us1.make.com/REPLACE_WITH_YOUR_WEBHOOK_ID with the Custom Webhook URL Make gives you.

The form performs basic browser validation, creates a unique client-side submission ID, and posts JSON to Make. The submission_id is used later to create a stable Volanea Idempotency-Key, so a repeated submit does not automatically become another email.

<form id="volanea-lead-form" novalidate>
  <label>
    First name
    <input name="first_name" type="text" autocomplete="given-name" required>
  </label>

  <label>
    Email address
    <input name="email" type="email" autocomplete="email" required>
  </label>

  <label>
    What are you interested in?
    <select name="interest" required>
      <option value="">Choose one</option>
      <option value="product-help">Product help</option>
      <option value="wholesale">Wholesale</option>
      <option value="restock-alert">Restock alerts</option>
    </select>
  </label>

  <label>
    Message
    <textarea name="message" rows="4"></textarea>
  </label>

  <button type="submit">Send request</button>
  <p id="form-status" role="status" aria-live="polite"></p>
</form>

<script>
  const form = document.getElementById('volanea-lead-form');
  const status = document.getElementById('form-status');
  const makeWebhookUrl = 'https://hook.us1.make.com/REPLACE_WITH_YOUR_WEBHOOK_ID';

  form.addEventListener('submit', async (event) => {
    event.preventDefault();

    if (!form.reportValidity()) return;

    const fields = new FormData(form);
    const payload = {
      submission_id: crypto.randomUUID(),
      event: 'shogun.embedded_form.submitted',
      submitted_at: new Date().toISOString(),
      page_url: window.location.href,
      first_name: String(fields.get('first_name') || '').trim(),
      email: String(fields.get('email') || '').trim().toLowerCase(),
      interest: String(fields.get('interest') || '').trim(),
      message: String(fields.get('message') || '').trim()
    };

    status.textContent = 'Sending…';

    try {
      const response = await fetch(makeWebhookUrl, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(payload)
      });

      if (!response.ok) throw new Error(`Webhook returned ${response.status}`);

      form.reset();
      status.textContent = 'Thanks — check your inbox shortly.';
    } catch (error) {
      console.error(error);
      status.textContent = 'We could not submit the form. Please try again.';
    }
  });
</script>

When a visitor submits the form, Make receives this payload shape:

{
  "submission_id": "a4d8710d-cf78-4209-b954-a9aeece781fb",
  "event": "shogun.embedded_form.submitted",
  "submitted_at": "2026-10-13T17:42:19.027Z",
  "page_url": "https://store.example/pages/wholesale",
  "first_name": "Avery",
  "email": "avery@example.com",
  "interest": "wholesale",
  "message": "Could you send your wholesale catalog?"
}

The payload is intentionally flat. Flat JSON maps cleanly in Make, is easy to inspect in scenario history, and avoids the mistakes that often occur when automation tools flatten arrays or nested objects.

Configure Make to receive the Shogun submission

Create a new Make scenario and select Webhooks > Custom webhook as the first module. Create a new webhook, give it a descriptive name such as Shogun lead form, and copy the URL into the embedded form above.

Run the scenario once in Make's testing mode, then submit the form from your published Shogun page. Make should capture a sample payload and expose fields including submission_id, email, first_name, interest, and message for mapping in later modules.

Add validation before sending email

Do not send email merely because a webhook arrived. A public page can be submitted by bots, users can bypass browser validation, and malformed data can be posted directly to a public webhook URL.

At minimum, add filters that require:

• email is present and contains a plausible email address.
• first_name is present if the email copy requires it.
• interest matches one of the values your form actually emits.
• submission_id is present.
• event exactly equals shogun.embedded_form.submitted.

A filter is not a complete anti-abuse system, but it prevents ordinary malformed requests from generating messages. For a public high-traffic form, add rate limiting and bot protection upstream of Make or use an owned server endpoint that can verify a CAPTCHA or turnstile token.

Keep the response behavior simple

The browser waits for the webhook request to complete. Avoid adding slow enrichment calls before Make acknowledges the inbound request if your automation platform makes that possible. Third-party API lookups, CRM searches, and large branching workflows can make a contact form feel broken even when the email eventually sends.

If the confirmation email is important but not needed for the visitor's immediate page interaction, return success quickly and let the email send continue in the background. The UI copy should promise the correct outcome: “Check your inbox shortly” is more accurate than “Email sent” because acceptance by the API is not the same as final inbox delivery.

Map the Make webhook payload to Volanea

Add an HTTP > Make a request module after your validation filters. Configure it as a POST request to:

https://api.volanea.com/v1/send

Set the request headers in the Make HTTP module:

Authorization: Bearer YOUR_VOLANEA_API_KEY
Content-Type: application/json
Idempotency-Key: shogun-form-{{submission_id}}

The exact Make mapping token syntax shown in the UI can differ depending on how Make renders module references, but the values must come from the Custom Webhook's captured fields. The key point is that submission_id becomes part of the Idempotency-Key and the Volanea secret is a static credential configured only inside the server-side automation step.

Use this JSON body in the HTTP module. Replace the double-braced field values with the mapped values selected from Make's data panel.

{
  "from": "Acme Store <hello@updates.example.com>",
  "to": "{{email}}",
  "subject": "We received your {{interest}} request",
  "html": "<p>Hi {{first_name}},</p><p>Thanks for your request about <strong>{{interest}}</strong>.</p><p>Our team will follow up shortly.</p>",
  "text": "Hi {{first_name}},\n\nThanks for your request about {{interest}}. Our team will follow up shortly.",
  "replyTo": "support@example.com",
  "tags": [
    "source:shogun",
    "event:lead-form"
  ]
}

This is the field mapping:

Volanea's send endpoint supports an Idempotency-Key header for POST /v1/send. Use it. Without it, a retry after a network ambiguity can create two confirmation emails for one form submission.

For stored templates, replace the inline subject, html, and text fields with the appropriate template request supported by your Volanea account and pass the mapped form values as template variables. Keep the first version inline while testing: it is easier to inspect, and you can move to a template after the payload contract is proven. For endpoint details, authentication, and available fields, consult the Volanea API reference and setup guides.

Where the Volanea API key belongs

The Volanea API key belongs in Make's server-side HTTP request configuration or, preferably, in a credential/connection mechanism that limits access to authorized workflow editors. It does not belong in Shogun page settings, the HTML element, a JavaScript variable, a hidden form field, or an environment-like value injected into the browser.

Anything delivered to a visitor's browser can be inspected. A hidden input is not secret. Minified JavaScript is not secret. A value placed in a data attribute is not secret. If a Volanea API key appears in the page's HTML, browser developer tools, page source, or network requests, anyone who finds it may be able to use it to send email from your authenticated domain.

In the embedded code above, the Make webhook URL is visible because it has to be called from the browser. The Volanea key is absent. That separation is the minimum security boundary:

• The browser may know the webhook destination.
• Make may know the Volanea API key.
• Volanea receives the authenticated send request.
• Visitors must never receive the Volanea API key.

Treat the webhook URL as public input

A webhook URL is not a replacement for authentication. Even if it is long and difficult to guess, it is exposed to every browser that loads the page. A bad actor can copy it and submit arbitrary payloads.

Reduce the impact by validating fields, limiting scenario access, monitoring volume, and using bot protection. The strongest option is an owned endpoint in front of Make or Volanea that can rate-limit by IP, require an anti-bot token, reject unexpected origins where appropriate, and keep an audit record.

Also use a sending address on a domain you have authenticated in Volanea. A correct API call cannot compensate for an unverified sender domain, and a confirmation email should use a recognizable From identity that aligns with the store the visitor just interacted with.

Send both a visitor confirmation and an internal notification

Most Shogun form flows need two distinct messages:

1. A visitor confirmation that acknowledges the request.
2. An internal notification so a sales, support, or wholesale team can act.

Do not send one email with the visitor and team members all included as recipients. That exposes addresses and mixes two different audiences. Create two Volanea sends instead, each with its own subject, content, tags, and idempotency key.

For example, the visitor confirmation can use:

Idempotency-Key: shogun-form-confirmation-{{submission_id}}

The internal alert can use:

Idempotency-Key: shogun-form-team-alert-{{submission_id}}

The visitor email should be brief and expected. The team alert can include the submitted message, page URL, timestamp, and interest category. Keep user-provided content escaped or encoded before placing it inside HTML. A visitor's message is untrusted input; do not concatenate it directly into an HTML email body without escaping special characters.

Example internal notification payload

{
  "from": "Acme Store Forms <forms@updates.example.com>",
  "to": "sales@example.com",
  "subject": "New Shogun wholesale request from {{first_name}}",
  "html": "<h2>New wholesale request</h2><p><strong>Name:</strong> {{first_name}}</p><p><strong>Email:</strong> {{email}}</p><p><strong>Interest:</strong> {{interest}}</p><p><strong>Page:</strong> {{page_url}}</p><p><strong>Message:</strong> {{message}}</p>",
  "text": "New wholesale request\nName: {{first_name}}\nEmail: {{email}}\nInterest: {{interest}}\nPage: {{page_url}}\nMessage: {{message}}",
  "replyTo": "{{email}}",
  "tags": [
    "source:shogun",
    "recipient:internal",
    "event:lead-form"
  ]
}

Set the internal alert's replyTo only after validating that the submitted value is a valid email address. That lets your team reply directly to the lead while keeping the visible From address on your authenticated sending domain.

When this breaks: failures specific to this hop

The integration has three hops: the browser on a Shogun page, your webhook middleware, and Volanea. Troubleshooting becomes much faster when you identify which hop actually failed.

Duplicate sends from retries

Shogun's documented native Form Box flow does not expose a custom outbound webhook retry policy, so do not claim that “Shogun retried the Volanea webhook” in this setup. In this architecture, duplicates are more likely to come from a visitor double-clicking Submit, a browser retry after a poor network connection, Make retrying a failed HTTP module, or someone replaying the public webhook request.

The fix is a stable idempotency key. Generate one submission_id for a single client submission and reuse it for every retry of that same email operation. The key must not be regenerated inside Make for each attempted request. If it is, Volanea correctly sees every retry as a different send request.

For separate message types, scope the key by purpose as shown earlier. A visitor confirmation and internal alert should have different keys because they are intentionally different messages. Two attempts to send the same visitor confirmation should share the same key.

Webhook timeouts and slow forms

A browser request can fail even if the middleware eventually completes its workflow. For example, the visitor may lose connectivity after Make receives the payload but before the browser receives the response. If your page says “Try again,” the visitor may submit a second time.

Design for that ambiguity. The page should disable the submit button while a request is in progress, display a noncommittal error message on failure, and rely on idempotency rather than assuming the browser knows whether an email was accepted.

Keep the synchronous path short. Do not make a Shogun form wait for CRM enrichment, inventory checks, AI processing, or a chain of downstream APIs before returning a success response. Those belong after the core lead capture and confirmation-email step.

Missing or renamed payload fields

There is no published Shogun plan-specific outbound-webhook payload schema for native forms because the documented native form feature is not a custom webhook sender. Therefore, avoid building a workflow around assumptions such as “this Shogun plan always includes field X in its webhook.”

With the embedded form route, you control the payload. Missing fields generally mean one of four things: the HTML field name changed, an optional field was left empty, an old published page version is still live, or a caller posted directly to the public webhook.

Use explicit defaults in Make. For example, set a fallback greeting such as there when first_name is empty, but reject the request when email or submission_id is missing. Include an event field and validate it exactly so unrelated webhook traffic cannot accidentally take the send-email route.

The email request is accepted but no inbox message appears

An accepted send request is not the same as inbox placement. Delivery can be affected by recipient suppression, a malformed recipient address, the sending domain's authentication state, recipient-server filtering, or a mailbox's spam controls.

Start with the Volanea send record and event data. Confirm that the API accepted the message, inspect the recipient address, and verify that your From domain is authenticated. Then distinguish a bounce or suppression from a delivery event, and distinguish delivery from an open. This prevents teams from treating every “I did not see it” report as an API outage.

Make scenario errors

Make can receive a webhook successfully and still fail on the Volanea HTTP step. Capture the outgoing status code and response body in scenario history, but do not log full API keys or raw personal data more broadly than necessary.

For retryable network and temporary service failures, configure controlled retries and retain the same idempotency key. For invalid request errors, do not retry blindly. A 4xx response caused by an invalid recipient, malformed payload, or unauthorized credential needs a configuration fix, not repeated sends.

Test before publishing the Shogun page

Test the complete path with a real inbox you control. Do not test only by running the Make HTTP module manually, because that skips the browser-to-webhook leg where field names, CORS behavior, and submission handling often fail.

Use this checklist:

1. Publish the Shogun page or preview it in an environment where the HTML embed runs.
2. Submit a valid email address and confirm Make captures the expected payload fields.
3. Confirm the Make filter allows the valid submission through.
4. Inspect the Volanea request: From address, recipient, subject, text body, HTML body, reply-to, tags, and idempotency key.
5. Verify the message arrives in the test inbox.
6. Submit the same request twice while retaining the same submission ID in a controlled test, and confirm it does not produce duplicate mail.
7. Submit an invalid or incomplete request and confirm it does not reach Volanea.
8. Check the page on mobile, where a custom form's spacing, labels, and error state may behave differently.

Do not use a personal address for production smoke tests if the page is publicly accessible and could produce frequent alerts. Create a dedicated test mailbox or an internal alias with clear monitoring ownership.

Operational practices that keep the integration maintainable

A Shogun landing page tends to change more often than backend email logic. Marketing teams alter copy, add fields, launch campaigns, duplicate pages, and A/B test variants. Your integration should tolerate those changes without silently sending bad messages.

First, maintain a small field contract. Document the required incoming fields, allowed values for select menus, default behavior for optional values, and which email templates consume each field. Put this in your implementation notes beside the Make scenario name.

Second, keep the public form event separate from the email payload. The form event says what happened: shogun.embedded_form.submitted. The Volanea send payload says what email to send. That separation lets you route the same form submission to a CRM, spreadsheet, warehouse, or analytics system without changing the transactional email request.

Third, use tags consistently. A tag such as source:shogun makes it possible to distinguish Shogun-generated mail from receipts, account notifications, and application emails. Add a campaign or page identifier only if it will be used operationally; uncontrolled tag values based on full URLs can become noisy.

Finally, review the economics of the workflow as your volume grows. Each no-code automation run and each transactional email may have separate usage implications. If a landing page begins generating significant volume, moving the middleware logic into a lightweight owned endpoint can reduce complexity while giving you more exact control over validation, logging, and deduplication. Review transactional email sending costs and plan details before scaling the automation to a high-volume acquisition flow.

Conclusion

The correct way to send email from Shogun with Volanea is not to look for a nonexistent marketplace app or expose an email API key inside a page builder. Shogun's native forms are designed for form collection and email notifications, not for arbitrary outbound HTTP requests to an email API.

Use an embedded custom form on the Shogun page, send its defined JSON payload to Make or an owned endpoint, validate the submission, and call Volanea from that server-side layer. Keep the API key private, use Idempotency-Key for every transactional send, and separate visitor confirmations from internal notifications.

That architecture gives your team a polished Shogun page without sacrificing the security, delivery controls, and observability expected from a transactional email system.

FAQ

Can I connect Shogun's native Form Box directly to Volanea?

No documented native Form Box setting sends arbitrary outbound HTTP requests to Volanea. The documented options center on emailing submissions, exporting form data, and a supported Klaviyo integration. Use an embedded third-party or custom form plus middleware instead.

Does the Volanea API key go in Shogun?

No. Never put a Volanea API key in Shogun page HTML, JavaScript, hidden fields, or any client-visible setting. Put it in the server-side Make HTTP step or, preferably for sensitive or high-volume use cases, in your own backend environment.

Why do I need an idempotency key for a form confirmation email?

Form submits can be repeated by a double-click, browser retry, automation retry, or an ambiguous network timeout. A stable Idempotency-Key lets Volanea treat repeated requests for the same logical email as one send operation.

Can I use Zapier instead of Make?

Yes. Use Webhooks by Zapier with a Catch Hook trigger to receive the embedded form payload, then use an API request action to call Volanea. The same security rules apply: the webhook URL can be public, but the Volanea API key must remain server-side.

What should I do if a submitted lead never receives the confirmation?

Check the embedded form request first, then Make scenario history, then the Volanea send result and delivery events. Confirm the sender domain is authenticated, the recipient address is valid, the request was not suppressed, and that an accepted API request was not mistaken for confirmed inbox delivery.