How to Send Email From Shopify With Volanea

Send email from Shopify with Volanea by using Shopify Flow’s Send HTTP request action. There is no native Volanea Shopify app or marketplace installation flow: Shopify Flow can call Volanea’s REST API directly when an eligible Shopify event occurs.

This guide builds a practical order-confirmation workflow. Its concrete Shopify trigger is Order created, which starts when a customer places an order or when a paid draft order converts into an order. Flow receives the GraphQL Admin API order object, renders the Liquid variables you configure, and sends the resulting JSON to Volanea’s POST /v1/send endpoint.

That distinction matters. You are not wiring a browser form to an email API, and you are not exposing a key in theme code. Shopify runs the automation server-side, Flow holds the secret, and Volanea receives one authenticated API request for each qualifying order.

What this Shopify-to-Volanea integration does

The workflow has four moving parts:

1. Shopify Flow trigger: Order created starts the workflow after an order is placed.
2. Optional conditions: Flow checks whether the order has an email address and whether it matches the kind of order that should receive this message.
3. Send HTTP request action: Flow makes a POST request to Volanea with an Authorization header, an idempotency key, and a JSON email payload.
4. Volanea delivery pipeline: Volanea accepts the message, checks sending rules and suppressions, then processes and dispatches the transactional email.

This pattern is useful for emails that Shopify’s built-in notifications do not cover cleanly: a custom internal alert, a request for a high-value order review, a post-purchase instruction message, a notification tied to a specific order tag, or a manually designed order acknowledgement.

It is not necessarily a replacement for every Shopify notification. Shopify’s own order confirmation is already deeply connected to checkout and order status. Use this integration when you need a message that belongs in your own transactional-email workflow, needs a different sender identity, or needs logic that is easier to manage in Flow.

The direct route is available only when your store can use Shopify Flow’s Send HTTP request action. Shopify documents that action for Grow, Advanced, and Plus plans. Shopify Flow itself is available more broadly, but a Basic-plan store cannot use this direct outbound HTTP step. In that case, use a middleware route such as Zapier or Make, or have a custom app/server receive Shopify webhooks and call Volanea from the server.

The real Shopify trigger: Order created

For this guide, select Order created as the Flow trigger. Shopify defines this trigger as starting a workflow when a customer places an order, or when a draft order is marked paid and converted into an order.

The trigger provides an order object. Flow variables are not a generic REST webhook payload copied from Shopify into a request automatically. Instead, Flow gives the workflow access to fields from Shopify’s GraphQL Admin API object, and you decide which values go in the HTTP request body.

For an order email, the fields you will usually use are:

• order.id — Shopify’s stable GraphQL order ID; use it to create a repeatable idempotency key.
• order.name — the human-readable order name, such as #1042.
• order.email — the email associated with the order.
• order.customer.firstName — the customer’s first name when a customer record is available.
• order.totalPriceSet.shopMoney.amount — the amount in the shop currency, if your message needs it.
• order.currencyCode — the order currency code.

Do not assume every nested field exists for every order. A guest checkout can have an order email but no customer record. Some data is populated asynchronously after creation. Shopify explicitly cautions that fields on orders can be unavailable when a workflow first runs, particularly fields populated asynchronously. Choose Order created for a simple immediate acknowledgement, but choose a later trigger when your message depends on a later event such as payment, fulfillment, or risk analysis.

When to choose a different Shopify Flow trigger

The best trigger follows the business event—not merely the closest-looking object.

Use Order created when you need an acknowledgement or internal notification as soon as the order is placed. Use Order paid when the email must only go after payment is marked paid. Use Order fulfilled for shipment-related instructions. Use Order risk analyzed when the message depends on Shopify’s risk assessment being available.

That timing choice prevents a common automation error: an email says an order is ready for fulfillment before payment clears, or it attempts to render fulfillment information that does not exist yet.

Prerequisites before you create the workflow

Set up the sending side before building Flow. A workflow can be syntactically correct and still fail because its sender is not ready to send.

You need:

• A Shopify store on Grow, Advanced, or Plus for Flow’s direct Send HTTP request action.
• The free Shopify Flow app installed and accessible from Shopify admin.
• A Volanea project and a secret API key beginning with sk_ for live delivery, or sk_test_ while testing without delivery.
• A verified sender domain and a From address on that domain.
• A decision about which orders should trigger the message.

Create and verify your sender domain before using it in the request. A From address such as orders@example.com must be on a domain that is verified in Volanea. Use the email API reference and setup guides to confirm the current sender and domain-verification requirements before moving the workflow into production.

Decide what makes this email transactional

The example below is a transactional acknowledgement tied directly to a completed order. Keep its purpose operational: confirmation, important next steps, fulfillment instructions, account access, receipt-related help, or an exception requiring action.

Do not quietly convert an order-triggered email into a promotional campaign. Marketing consent, suppression handling, expectations, frequency, and content requirements can differ. If you need a post-purchase promotion, model that separately and ensure your workflow respects the consent and policy requirements that apply to your store.

Store the Volanea API key in Shopify Flow Secrets

Volanea authenticates API calls with a bearer token. The header format is:

Authorization: Bearer <your-secret-key>

The secret key must never be placed in Shopify theme JavaScript, a storefront form, a checkout customization visible to shoppers, a public Git repository, or a hard-coded value copied into an email template. Anyone who gets a secret sending key could make authenticated API calls as your Volanea project.

For the direct Flow integration, create a Flow secret instead:

1. In Shopify admin, open Apps > Flow.
2. Open Settings in Flow.
3. Create a secret with a clear handle, such as volanea_secret_key.
4. Paste the Volanea sk_... key as the value.
5. Add the secret to the Send HTTP request action’s Authorization header.

Shopify Flow secrets are intended for sensitive values such as access tokens and passwords. Shopify documents that a secret has a handle, value, and description, and can be referenced as a Liquid variable such as {{secrets.handle}} or inserted with the action’s Add secret option.

Your header value will therefore be:

Bearer {{secrets.volanea_secret_key}}

Use a dedicated key where possible, record which workflow uses it, and rotate it if access changes or a leak is suspected. Do not use a Volanea public key for sending: public keys are not substitutes for server-side sending credentials.

Build the Shopify Flow workflow

In Shopify admin, go to Apps > Flow and create a workflow. The basic canvas should read:

Order created
  → Condition: order email is present
    → Send HTTP request

The condition is important. It prevents an avoidable API error when an order does not expose an email address. In the Flow condition builder, choose the order.email variable and configure it to be present or not empty.

You can add other conditions before the HTTP step. Examples include:

• Only send for orders above a threshold.
• Only send when an order has a specific tag.
• Exclude test orders.
• Send a special message when a particular product appears in the order.
• Route wholesale or B2B orders to an internal inbox instead of the buyer.

Keep the first version narrow. Build one workflow for one message and one event. It is easier to test, trace, and revise than a large workflow that tries to handle every order state and recipient path in one request.

Configure the Send HTTP request action

Add a Send HTTP request action after your condition. Configure its fields as follows:

Flow supports POST requests and lets you provide multiple headers and a request body. The HTTP action waits up to 30 seconds for an HTTP response before closing the connection and retrying later. That is why the Idempotency-Key header is not optional production polish; it is part of the correctness of the integration.

The exact request Flow sends to Volanea

In Flow, the request body is text that Liquid renders at run time. The JSON below is the concrete body to paste into the action’s Body field. It maps Shopify’s order fields into Volanea’s documented single-message send schema.

{
  "from": {
    "email": "orders@example.com",
    "name": "Example Store"
  },
  "to": [
    {
      "email": {{ order.email | json }}
    }
  ],
  "subject": "We received your order {{ order.name }}",
  "html": "<p>Thank you for your order {{ order.name }}.</p><p>Order total: {{ order.totalPriceSet.shopMoney.amount }} {{ order.currencyCode }}.</p><p>We will email you again when your order moves forward.</p>",
  "text": "Thank you for your order {{ order.name }}. Order total: {{ order.totalPriceSet.shopMoney.amount }} {{ order.currencyCode }}. We will email you again when your order moves forward."
}

The corresponding headers are:

Authorization: Bearer {{secrets.volanea_secret_key}}
Content-Type: application/json
Idempotency-Key: shopify-order-confirmation-{{order.id}}

At runtime, assume Shopify created an order whose ID is gid://shopify/Order/1234567890, whose name is #1042, whose email is alex@example.net, and whose total is 84.00 USD. The Flow action renders this effective request body before it sends it:

{
  "from": {
    "email": "orders@example.com",
    "name": "Example Store"
  },
  "to": [
    {
      "email": "alex@example.net"
    }
  ],
  "subject": "We received your order #1042",
  "html": "<p>Thank you for your order #1042.</p><p>Order total: 84.00 USD.</p><p>We will email you again when your order moves forward.</p>",
  "text": "Thank you for your order #1042. Order total: 84.00 USD. We will email you again when your order moves forward."
}

That is the payload Volanea receives. It is not an opaque Shopify event envelope: the HTTP action sends the body you configured after Flow substitutes its variables.

Why | json matters for the recipient address

Use the Flow json Liquid filter on values inserted as JSON strings, as shown for order.email. The filter emits valid JSON quoting and escaping. This is safer than writing:

"email": "{{ order.email }}"

For an ordinary address both may look identical, but JSON encoding avoids malformed output when dynamic values contain characters that require escaping. For more complex personalization—customer names, addresses, custom attributes, or user-supplied order notes—build and inspect the rendered request carefully before enabling the workflow.

Do not interpolate untrusted customer text directly into HTML without escaping and content review. An order note or product title can contain unexpected characters, markup-like text, or values you would not want to display in an email. Keep the first message limited to controlled order identifiers and totals, then expand only after testing the rendered output.

Field mapping: Shopify order data to email fields

The request above intentionally maps only the data needed for a simple acknowledgement. Here is how each field behaves.

Volanea’s send endpoint accepts a recipient or an array of recipients, and one request can address up to 50 recipients. For a buyer acknowledgement, keep one recipient per request. It keeps the relationship between the Shopify order and the email obvious, makes suppression or delivery troubleshooting easier, and avoids accidentally exposing one customer’s address to another.

Customer first names and guest checkouts

It is tempting to add order.customer.firstName immediately. Do that only after accounting for guests and missing customer objects. A guest can have order.email while the nested order.customer data you expect is absent or incomplete.

A safe first message can simply say “Thank you for your order.” If you later personalize it, provide a fallback in the Liquid logic and test guest checkout, Shop Pay, draft-order conversion, staff-created orders, and any B2B flows you use. A greeting is not worth a broken JSON payload or a workflow failure.

Make retries safe with an idempotency key

Every order-triggered email needs a stable idempotency strategy. The central rule is simple: retries of the same logical email must use the same key.

This workflow uses:

Idempotency-Key: shopify-order-confirmation-{{order.id}}

That value is stable for one specific order confirmation. If Shopify Flow times out after Volanea accepted the request but before Flow received the response, Flow can retry. When the retry carries the same idempotency key, Volanea can recognize it as the same intended send instead of creating a second confirmation.

Do not generate a random value in a Flow retry path. A new random key makes every retry look like a new email. Similarly, do not use only the customer email as the key: one customer can place multiple legitimate orders.

If you later add a second email for the same order—such as a high-value-order review notice—use a different stable prefix:

shopify-high-value-review-{{order.id}}

The prefix identifies the logical message type; the order ID identifies the event instance. Together, they make replay behavior intentional.

When this breaks: Shopify Flow and email delivery failure modes

A reliable integration assumes failures will happen and decides what they mean before production traffic arrives.

Shopify retries after a timeout

Shopify Flow waits a maximum of 30 seconds for the HTTP response. If it does not receive one, it closes the connection and retries later. A timeout does not prove Volanea did not receive or begin processing the request.

What to do: Keep the same Idempotency-Key for the same order and email type. Do not change the key between attempts. Avoid putting slow work in front of Volanea; the direct call should be a straightforward request to the API endpoint.

A 4XX, 429, or 5XX response repeats the action

Flow lets you configure how it handles client errors and server errors. Its documented retry behavior can continue for up to 24 hours for configured retries on 4XX, 5XX, and 429 responses.

What to do: Treat a 4XX as a configuration or data problem first. Check the sender address, Authorization header, JSON syntax, and recipient field. Treat 429 and 5XX as retry-worthy transient conditions, but let idempotency make the retry safe. Do not automatically ignore every failure; an ignored failed confirmation can become a support problem you never see.

The order has no usable email address

Some orders may not supply the email value you expect, or your workflow may be triggered by an internal process rather than a standard checkout.

What to do: Put a condition before the HTTP action that requires order.email to be present. Build a separate internal-notification path for exceptional orders rather than sending an invalid request to Volanea.

The field you need is not ready on Order created

Shopify notes that some GraphQL Admin API data is populated asynchronously on orders. Fulfillment, risk, UTM, and similar data may be missing when Flow runs immediately after the order is created.

What to do: Select a trigger that occurs when the required information is ready. For a risk-related message, use Order risk analyzed. For shipping information, use an appropriate fulfillment-related trigger. If you must use Order created, do not render fields that are not guaranteed at that point.

The sender domain is not verified

A message with an unverified From domain should not be treated as a Shopify problem. It is sending configuration.

What to do: Verify the exact domain used by from.email, confirm the sender address is correct, and use a test key before switching to live delivery. Keep production and test keys separate so an integration test cannot accidentally mail real customers.

Flow test mode does not actually send the request

When you test a Flow workflow, external actions such as Send HTTP request display configuration previews rather than executing the real external request. Shopify recommends using real recorded events to test these actions.

What to do: First inspect the Flow preview for variable and JSON problems. Then activate the workflow with a Volanea test key and create a controlled test order. After you confirm the rendered payload and response, switch to the live secret key and test with an internal recipient before enabling the workflow for customers.

Test the workflow before customers see it

Testing should prove three things: the trigger runs when you expect, Flow renders valid JSON, and Volanea accepts the email without duplicate sends.

Use this checklist:

1. Create the Flow secret using a Volanea sk_test_... key.
2. Build the Order created workflow with the email-present condition and Send HTTP request action.
3. Inspect the action configuration to confirm the endpoint, authorization format, content type, and idempotency header.
4. Use Flow’s preview tools to inspect available order values and look for missing fields.
5. Place a controlled test order with an inbox you can access.
6. Review the workflow run in Shopify Flow for the request result and status code.
7. Review the Volanea send record to verify the sender, recipient, subject, and rendered message.
8. Repeat or replay only if needed and confirm the same order key does not produce duplicate logical sends.

Keep a copy of the final request body and headers in your implementation notes. If someone later edits the workflow, changes a sender address, or rotates the key, the saved expected request makes regression testing much faster.

When to use middleware instead of direct Flow HTTP

Direct Flow-to-Volanea HTTP is the simplest route when your Shopify plan supports Send HTTP request and the email is a straightforward transactional message. It has fewer systems, fewer credentials, and fewer opportunities for mapping drift.

Use middleware when you need capabilities Flow alone does not provide well:

• Your Shopify plan does not include Send HTTP request.
• You need to combine Shopify data with another system before emailing.
• You need complex HTML rendering, a component-based template engine, or extensive escaping.
• You need a database-backed audit trail, queue, custom rate controls, or an approval step.
• You need to verify Shopify-signed webhooks from a custom app endpoint.
• You need a long-running process that should return quickly to Shopify and continue asynchronously.

For Basic-plan stores, Zapier or Make can receive a Shopify event and make an authenticated Volanea HTTP call. Store the Volanea key in the automation platform’s credential or connection manager, not in a public webhook URL or client-side script. For higher-volume or business-critical flows, a small server endpoint plus a durable queue gives you tighter control over signatures, logging, retries, and idempotency.

The direct route and middleware route can coexist. For example, use Flow direct calls for one internal operational alert while a custom service handles a multi-step post-purchase program. What matters is that each message has one clear owner and one stable idempotency rule.

Operational practices that keep the integration maintainable

Treat this workflow as production infrastructure, not a one-time admin configuration.

First, name the workflow for the actual event and message, such as Order created → Volanea order acknowledgement. Avoid vague names like “Email automation.” A clear name makes workflow history understandable when support or operations teams investigate a missing email.

Second, preserve the relationship between Shopify and Volanea. The order.id in the Idempotency-Key is the join point. Put the order name in the subject or message body so a support person can locate the corresponding Shopify order and Volanea send record quickly.

Third, separate message types. An order acknowledgement, fraud-review alert, backorder notice, and fulfillment instruction email should have different Flow workflows or clearly separated paths, different idempotency prefixes, and explicit conditions. That lets you adjust one message without accidentally changing another.

Fourth, review your sender identity and reply handling. A transactional From address should be monitored or have an intentional Reply-To strategy. Customers often reply to an order email even when the message says it is automated.

Finally, revisit the workflow after Shopify or your order process changes. New sales channels, B2B orders, subscriptions, draft orders, pickup flows, and fulfillment providers can alter which order data exists at each trigger stage.

Conclusion

To send email from Shopify with Volanea, use Shopify Flow’s Order created trigger and Send HTTP request action to call POST https://api.volanea.com/v1/send. Put the Volanea secret key in Flow Secrets, map only the Shopify order fields your message truly needs, and use order.id in a stable Idempotency-Key.

The direct integration is deliberately simple: Shopify starts the workflow, Flow renders a controlled JSON request, and Volanea handles the transactional send. Its reliability comes from the details—choosing the right trigger, avoiding unavailable fields, never exposing the secret key, and assuming retries can happen.

FAQ

Does Volanea have a native Shopify app?

No. This setup does not use a Volanea Shopify marketplace app or plugin. It uses Shopify Flow’s native Send HTTP request action to call Volanea’s REST API directly.

Which Shopify plans can send HTTP requests from Flow?

Shopify documents the Send HTTP request action for Grow, Advanced, and Plus plans. If your store is on Basic, use middleware such as Zapier, Make, or a custom server-side integration instead.

What Shopify event starts the email in this guide?

The workflow starts with Shopify Flow’s Order created trigger. It runs when a customer places an order or when a paid draft order converts into an order.

How do I prevent duplicate order emails?

Set a stable Idempotency-Key header such as shopify-order-confirmation-{{order.id}}. Shopify Flow can retry a request after timeouts or configured error responses, so the same logical order email must reuse the same key.

Where should the Volanea API key be stored?

Store the sk_... Volanea secret key in Shopify Flow > Settings > Secrets and reference it in the Authorization header. Never place a secret API key in storefront JavaScript, theme settings exposed to shoppers, or a public repository.