Send email from Justuno with Volanea by attaching Justuno’s HTTP Client webhook to a form-submit action in a workflow. The integration is direct: Justuno sends a server-side HTTP POST to Volanea’s email API after the visitor submits your form; there is no native Justuno app, marketplace listing, or plugin to install.
The pattern is useful when a Justuno popup captures an email address and you need an immediate operational message that is separate from your broader marketing automation: a coupon delivery email, a lead-confirmation message, a back-in-stock acknowledgement, a consultation request receipt, or an internal notification.
Justuno supports custom webhooks through its HTTP Client integration. Its workflow builder can invoke a webhook either as a standalone workflow step or from the form submit action on a design step. For an opt-in confirmation or code delivery message, the form-submit path is usually the right trigger because it runs at the moment the visitor submits the form. (hub.justuno.com)
What this Justuno-to-Volanea integration does
The integration has four moving parts:
- A Justuno workflow enrolls a visitor and displays a design containing a form.
- The visitor presses a button whose click action is configured as form submit.
- The design step’s Sync To App action uses a custom HTTP Client webhook to POST selected Justuno profile properties to Volanea.
- Volanea accepts the message at
POST /v1/send, applies its sending pipeline, and queues it for delivery.
That last distinction matters. An API acceptance response means Volanea received and processed the send request; it is not the same thing as proof that a receiving mailbox accepted the email. Delivery can still be affected by a suppression, an invalid recipient, mailbox policy, sender-domain configuration, or a later provider response.
This is a transactional pattern, not a substitute for collecting consent and running a full promotional email program. If the email is a marketing follow-up rather than an immediate consequence of the form action, send the profile to your CRM or marketing platform first and use that platform’s consent, segmentation, and unsubscribe controls.
The real Justuno trigger: a form submission
Justuno calls the audience entry point an Enrollment Trigger. That decides who enters a workflow, such as a new visitor, a visitor viewing a product category, or someone meeting a behavior condition. It is not, by itself, the send event.
For this integration, the concrete sending event is a visitor submitting a form in a Justuno design step. Justuno’s own webhook guidance describes two placement options: a standalone webhook step, or a webhook attached to a form submit on a design step. It specifically notes that form-submit webhooks are the common option when profile data should sync immediately after submission. (hub.justuno.com)
Recommended workflow shape
Set up the workflow in this order:
- Create or edit a workflow under Experiences.
- Configure the Enrollment Trigger that determines who can see the popup, banner, embedded design, or other experience.
- Add a Design step that contains your lead-capture form.
- Include an email field and any other fields you need, such as first name, offer code, product interest, or consent state.
- Confirm at least one design button has its click action set to form submit.
- In that design step, use Sync To App, choose the custom integration route, and configure the HTTP Client webhook.
- Publish the workflow and test a real submission.
Justuno exposes the Sync To App control after a design contains a form and a button configured for form submission. (hub.justuno.com)
Why form submission is safer than enrollment for email
A workflow enrollment trigger can be broad. A visitor may qualify when they load a page, scroll, return to the site, or meet another audience rule. Sending a confirmation email at enrollment would risk sending mail before someone has actually supplied an email address or expressed the relevant intent.
A form submission gives you a cleaner contract: the visitor submitted the fields you mapped, including the recipient address. It also lets you make the email copy match the action exactly. A visitor who requests a discount should receive the discount delivery message, not a generic “welcome” email that may be triggered by unrelated behavior.
Before you configure the webhook
Prepare the sending side first. You need a Volanea API key and a verified sending domain before a production message can send reliably. The Volanea send endpoint is https://api.volanea.com/v1/send, and the API documentation describes it as a single-message endpoint that can address one recipient or up to 50 recipients. (volanea.com)
Use a sender address that belongs to the verified domain, such as hello@updates.example.com or support@example.com. Do not use a shopper’s submitted email address as the from address. Besides looking suspicious, that would break domain alignment and invite spoofing problems. If replies matter, choose a monitored sender mailbox or use Volanea’s supported reply-to capability according to the API reference.
You should also decide what this message represents. A useful first implementation is a direct, immediate confirmation:
- “Thanks — your 15% code is WELCOME15.”
- “We received your wholesale request and will reply within one business day.”
- “You are on the back-in-stock list for the product you selected.”
- “Your fitting-guide download is ready.”
Keep the first version narrow. One form action should produce one clearly related email. That makes testing, consent review, analytics, and duplicate prevention materially easier.
Configure the Justuno HTTP Client webhook
Justuno’s HTTP Client supports GET, POST, PUT, PATCH, and DELETE, plus JSON, form-urlencoded, and form-data request bodies. It can send dynamic Justuno profile properties in the body and static header values for authentication. (hub.justuno.com)
For Volanea, use JSON and POST.
Webhook settings
In the custom HTTP Client configuration attached to the design’s form submit action, use these values:
| Justuno setting | Value |
|---|---|
| Method | POST |
| URL | https://api.volanea.com/v1/send |
| Body type | JSON |
Header Content-Type | application/json |
Header Authorization | Bearer YOUR_VOLANEA_API_KEY |
Justuno labels headers as static key/value pairs. Put the Volanea API key in the HTTP Client integration’s Authorization header, not in custom code inside the popup, a page-level JavaScript variable, an HTML field, or any client-visible tag-manager configuration.
Why the API key must stay out of browser code
The Justuno design is rendered for the visitor’s browser. Anything embedded in its custom JavaScript, HTML, page source, client-side network requests, or a public configuration object can be extracted by a visitor or browser extension. A Volanea API key is a bearer credential: someone who obtains it may be able to send email as your account until you revoke or rotate it.
The HTTP Client configuration is the correct Justuno-side location because it is configured as an app connection and invoked from Justuno’s server-side integration flow, rather than being handed to the visitor’s browser. This is also why a direct HTTP Client route is preferable to trying to call Volanea with fetch() inside custom popup code.
Treat the key as production infrastructure:
- Create a scoped or environment-specific credential if your account supports it.
- Do not paste it into screenshots, tickets, exported workflow notes, or source control.
- Rotate it after an employee departure, suspected exposure, or migration.
- Use a separate test credential for staging where possible.
- Restrict who can edit Justuno apps and Volanea sending credentials.
For setup patterns beyond this one integration, see the email API reference and setup guides.
The payload Justuno sends to Volanea
Justuno does not impose one fixed webhook payload. You define the JSON body in the HTTP Client JSON editor, then insert Justuno profile properties as dynamic values. That is valuable because the payload can match Volanea’s send request directly instead of requiring a translation service for a basic acknowledgement email.
There is one important Justuno syntax rule: dynamic properties use double curly braces, such as {{email}}, and Justuno warns not to wrap the dynamic property itself in quotes in the JSON editor. Quoting a dynamic token causes the editor/parser to fail. (hub.justuno.com)
Assume your Justuno form writes these profile properties:
| Justuno profile property | Meaning | Volanea field |
|---|---|---|
email | Submitted recipient email | to[0] |
firstName | Submitted first name | Used in email copy or template variables |
offerCode | Static or captured code | Used in email copy or template variables |
marketingConsent | Consent record, if collected | Routing or CRM logic; not required for a transactional receipt |
Direct JSON body for Justuno’s editor
Paste a body shaped like this into the Justuno JSON editor. Replace the static sender address and copy with your own verified sender and message.
{
"from": "hello@updates.example.com",
"to": [{{email}}],
"subject": "Your welcome offer is ready",
"html": "<p>Thanks for signing up.</p><p>Your code is <strong>WELCOME15</strong>.</p><p>Use it at checkout before it expires.</p>",
"text": "Thanks for signing up. Your code is WELCOME15. Use it at checkout before it expires."
}
That is the actual outgoing shape for this simple direct route: Justuno resolves {{email}} from the visitor profile at form submission, produces a JSON request, and posts it to Volanea. The recipient is intentionally an array with one address, matching the one-message, one-recipient transactional use case.
The equivalent raw HTTP request is:
POST /v1/send HTTP/1.1
Host: api.volanea.com
Authorization: Bearer YOUR_VOLANEA_API_KEY
Content-Type: application/json
{
"from": "hello@updates.example.com",
"to": ["alex@example.com"],
"subject": "Your welcome offer is ready",
"html": "<p>Thanks for signing up.</p><p>Your code is <strong>WELCOME15</strong>.</p><p>Use it at checkout before it expires.</p>",
"text": "Thanks for signing up. Your code is WELCOME15. Use it at checkout before it expires."
}
Avoid unsafe dynamic HTML in the direct route
Use dynamic properties cautiously in inline HTML. A first name may contain punctuation or unexpected characters; other custom fields can contain arbitrary visitor input. A direct JSON mapping is excellent for an address and a static email body, but it is not the best place to interpolate raw visitor-entered values into HTML without escaping.
If you need personalization beyond a controlled first-name field, complex branching, product details, per-request coupon generation, or robust sanitization, use stored Volanea templates and an application endpoint. The endpoint can validate the input, escape untrusted text, select the right template, and then call Volanea. That also gives you substantially better duplicate protection.
A better production architecture for dynamic messages
The direct Justuno-to-Volanea call is appropriate for a small, low-risk, static confirmation. For a production workflow with personalized content or a customer-facing promise, add a small middleware endpoint between the two services:
Justuno form submit
-> Justuno HTTP Client webhook
-> your protected endpoint
-> validate and normalize data
-> create/reuse idempotency key
-> POST https://api.volanea.com/v1/send
The middleware endpoint should receive only the data it needs, authenticate the inbound request with a private shared secret, validate that email is present and syntactically plausible, and decide whether the event is eligible to send. It then holds the Volanea key in its server environment and makes the send request.
A conceptual Node.js handler looks like this:
import crypto from "node:crypto";
export async function justunoLead(req, res) {
if (req.get("X-Justuno-Secret") !== process.env.JUSTUNO_WEBHOOK_SECRET) {
return res.status(401).json({ error: "Unauthorized" });
}
const { email, firstName, submissionId } = req.body;
if (!email || !/^\S+@\S+\.\S+$/.test(email)) {
return res.status(422).json({ error: "A valid email is required" });
}
const idempotencyKey = submissionId || crypto
.createHash("sha256")
.update(`justuno-welcome:${email}:${req.body.offerCode || "WELCOME15"}`)
.digest("hex");
const response = await fetch("https://api.volanea.com/v1/send", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey
},
body: JSON.stringify({
from: "hello@updates.example.com",
to: [email],
subject: "Your welcome offer is ready",
html: `<p>Thanks${firstName ? `, ${escapeHtml(firstName)}` : ""}.</p><p>Your code is <strong>WELCOME15</strong>.</p>`,
text: `Thanks${firstName ? `, ${firstName}` : ""}. Your code is WELCOME15.`
})
});
return res.status(response.status).json(await response.json());
}
function escapeHtml(value) {
return String(value).replace(/[&<>'"]/g, char => ({
"&": "&", "<": "<", ">": ">", "'": "'", "\"": """
}[char]));
}
The important parts are not the framework details. They are the protected secret, server-side Volanea credential, input validation, stable event identity, and one clearly defined message creation step.
When this breaks: Justuno retries, timeouts, and missing fields
A working test does not eliminate operational failure modes. This specific hop has three that deserve design attention.
Justuno retries can create duplicate emails
Justuno records webhook and connected-app activity. Its documentation says a failed processing attempt moves through a retry queue, with up to five retries: the first after 15 minutes, then after one hour, four hours, 24 hours, and 48 hours. (hub.justuno.com)
Retries are necessary, but they create ambiguity. Imagine Volanea accepts the email, but the response is interrupted before Justuno records success. Justuno can reasonably retry because it does not know whether the downstream action happened. Without idempotency, a second POST may create a second email.
The direct HTTP Client route cannot reliably generate a unique, stable Idempotency-Key per form event when its header configuration is static. Therefore, use middleware for messages where duplicates are unacceptable: coupon emails, order-related notices, applications, appointment confirmations, account access links, or anything that can confuse or inconvenience a recipient.
At middleware, persist an event identifier and reuse the same idempotency key for every retry of that logical submission. Do not generate a fresh random key inside each retry attempt. A new key tells the email API that this is a new send.
Webhook timeouts can leave the result unknown
A timeout does not necessarily mean Volanea rejected the request. It can mean a network path stalled, Justuno stopped waiting, your middleware took too long, or the downstream provider accepted the request just before the connection ended.
Your webhook target should return quickly. Do not make it wait for unrelated CRM calls, PDF generation, inventory lookups, or a long chain of third-party requests. Validate the incoming event, store the idempotency record, enqueue work if necessary, and return a success response once the work has been safely accepted.
If you call Volanea directly from Justuno, keep the send payload simple and avoid dependencies that add latency. If you use middleware, log the inbound request ID, event identity, normalized recipient, Volanea response status, and resulting message identifier where available. Those records turn a vague “it timed out” report into something you can investigate.
Some profile fields may be absent or have unexpected types
Justuno dynamic properties are profile-property based. A field is only available when it was collected, populated earlier, or otherwise exists on that visitor’s profile. The HTTP Client documentation also notes that property types differ: checkboxes and multi-select values are arrays by default, numbers are numbers, and dates/datetimes are strings. (hub.justuno.com)
Do not assume firstName, phone, product interest, consent, or offer-code fields exist for every visitor. Your form may vary by workflow, a user may abandon an earlier step, or a legacy profile may contain only an email address.
Use these safeguards:
- Require an email field in the Justuno form before enabling the send action.
- Keep direct email content static unless a dynamic property is guaranteed.
- Use default text in middleware when optional values are absent.
- Treat checkboxes and multi-select fields as arrays, not strings.
- Add workflow conditions when a particular property is essential to the message.
- Test with a brand-new browser session, not only a profile that already has rich data.
Testing the integration without sending bad mail
Test in layers. Do not begin with a production popup and your customer list.
1. Validate Volanea independently
First send one message to a mailbox you control using the Volanea API or dashboard tooling. Confirm the sender domain is verified, the chosen from address is accepted, and the message renders correctly in both HTML and plain-text form.
2. Test the Justuno form flow
Use Justuno’s workflow testing approach to limit display to a safe URL condition or test session. Submit a disposable test address. Verify that the form is shown, the click action actually submits the form, and the profile receives the expected values.
3. Inspect Justuno activity logs
Justuno makes activity logs available through Account Settings > Apps > My Apps, then the app’s menu and Activity Logs. The logs show the outgoing request and the exact response returned by the connected service. (hub.justuno.com)
Check the actual resolved payload, not merely the JSON you intended to configure. Confirm that to contains a real recipient address, the sender is the expected verified address, and HTML did not become malformed due to a copied quote or invalid JSON token.
4. Test failure deliberately
Temporarily use an invalid API key in a non-production setup, or direct the webhook to a controlled test endpoint that returns a failure. Verify that the Justuno activity is marked appropriately and that you understand how retries appear. Then restore the valid configuration before publishing.
5. Test duplicate behavior
Submit the form once, inspect the logs, and avoid resubmitting simply because mail takes a moment to arrive. For a middleware implementation, replay the same inbound payload using the same event ID and confirm only one email is created. This is the test that proves your retry plan, not merely your happy path.
Deliverability and consent implications
A direct API call is not deliverability strategy by itself. Authenticate the domain that appears in the sender address, keep the sender identity stable, include both HTML and text content, and send messages whose content matches the visitor’s immediate expectation.
The direct form-submit trigger helps with relevance because it ties the email to a specific action. Still, do not quietly convert a coupon request or downloadable-resource form into an ongoing promotional sequence unless your consent language and routing support that use. Transactional acknowledgement and marketing subscription are distinct decisions, even when they happen in the same popup.
For higher-volume lead capture, validate addresses before adding them to a long-lived campaign audience. Volanea provides a free email address verification tool that can help you reduce obvious address-quality problems before they become bounce or complaint issues.
Direct webhook versus middleware versus automation tools
There are three reasonable implementation choices.
Direct Justuno HTTP Client to Volanea
Choose this when the message is immediate, static, low-risk, and tied directly to form submission. It has the fewest components and keeps the configuration inside Justuno.
Its tradeoff is limited control. You have less opportunity to sanitize input, make API credentials independently rotatable from app configuration, create durable idempotency, or enrich the event with external data.
Justuno to your middleware to Volanea
Choose this for personalized mail, generated links, high-value notifications, consent logic, duplicate resistance, auditing, or multi-system workflows. It is the strongest production option because your server owns validation, event identity, secrets, retry policy, and observability.
It adds code and hosting, but it prevents the email provider from becoming the place where business rules accidentally live.
Justuno to Zapier or Make to Volanea
Justuno also documents using its webhooks with Zapier’s Catch Hook trigger. That route can be useful when your team needs no-code transforms, routing, or additional app actions. (hub.justuno.com)
Use an automation platform when the operational need is genuinely orchestration. For sensitive or high-volume transactional sends, evaluate how the platform stores credentials, retries failed steps, exposes logs, and constructs idempotency before treating it as a replacement for a durable server endpoint.
Conclusion
To send email from Justuno with Volanea, trigger a custom HTTP Client webhook from a Justuno design’s form submit action, configure it as a JSON POST to https://api.volanea.com/v1/send, and keep the Volanea key in the server-side HTTP Client Authorization header. Map the submitted {{email}} profile property to Volanea’s recipient array and start with a static confirmation body.
That direct setup is fast and practical for a basic acknowledgement. As soon as duplicates, personalized HTML, generated offers, or high-value messages enter the picture, put middleware between Justuno and Volanea. A short protected endpoint gives you the controls that make webhook-driven transactional email safe to retry and easier to operate.
FAQ
Does Volanea have a native Justuno integration?
No. This setup uses Justuno’s custom HTTP Client webhook capability and Volanea’s REST API; it is not an installable Justuno marketplace app or plugin.
What starts the email send in Justuno?
The recommended trigger is a visitor submitting a form on a Justuno design step. Attach the custom HTTP Client webhook through the design step’s Sync To App flow after configuring a button with the form-submit click action.
Where should I put the Volanea API key?
Store it as the static Authorization: Bearer ... header in the Justuno HTTP Client integration configuration, or preferably in a server environment variable when using middleware. Never expose it in popup JavaScript, HTML, or browser-visible configuration.
Can Justuno retries send the same email twice?
Yes, they can if a prior request succeeded downstream but Justuno did not receive or record the response. Justuno retries failed integration processing, so use middleware with a stable Volanea Idempotency-Key for sends where duplicates matter.
Should I use this for newsletters?
Usually no. Use this route for an immediate message caused by a Justuno form submission. For ongoing promotional email, route subscribed profiles into a marketing system that manages consent, segmentation, preference handling, and unsubscribes.