How to Send Email from Uncanny Automator with Volanea

Send email from Uncanny Automator without relying on a native marketplace app: build an Uncanny Automator recipe, use its outbound webhook action, and post a transactional message to Volanea’s REST API. This route keeps your WordPress automation flexible while giving your email sending a dedicated delivery API.

There is no native Volanea app, listing, or installable marketplace plugin for Uncanny Automator. The practical integration is an HTTP connection: an Automator trigger completes, the recipe runs the Webhooks → Send data to webhook action, and that action makes an authenticated POST request to Volanea.

Uncanny Automator supports outbound webhooks with configurable request methods, headers, body fields, nested JSON objects, and data formats including JSON. Its outbound webhook functionality is available in the free version; receiving incoming webhooks is the capability that requires Pro. (automatorplugin.com)

This guide uses a concrete example: a visitor submits a WPForms contact form, Uncanny Automator starts an Everyone recipe with the WPForms trigger A form is submitted, and the recipe sends a personalized acknowledgement through Volanea. The same pattern works for Gravity Forms, WooCommerce, LearnDash, membership plugins, booking plugins, and any other Automator trigger that exposes the recipient and message data as tokens.

What this integration does

The integration has one simple responsibility: convert an event that happened in WordPress into a transactionally sent email.

For the example workflow, the chain is:

1. A visitor submits your WPForms contact form.
2. Uncanny Automator detects the event through the trigger WPForms → A form is submitted.
3. Automator resolves the trigger tokens for the person’s email address, first name, and selected form fields.
4. The Webhooks → Send data to webhook action sends a JSON request to https://api.volanea.com/v1/send.
5. Volanea accepts the email request, applies the sending domain, suppression, rendering, tracking, and dispatch pipeline, then records the result.

Uncanny Automator calls its automations recipes. For a public form, create a Recipe for Everyone, because the person submitting the form may not be logged in. In Automator’s own WPForms registration example, the documented trigger is A form is submitted, and the example specifically uses an Everyone recipe. (automatorplugin.com)

Volanea’s single-message endpoint is POST /v1/send. It accepts one recipient or up to 50 recipients in a request, supports secret-key authentication, and supports an Idempotency-Key header for safe retries. (volanea.com)

Before you build the recipe

Set up the email-delivery side first. A webhook request can be perfectly formed and still fail if Volanea is not ready to send from the address you selected.

You need:

• An active Volanea project.
• A verified sending domain in Volanea.
• A sender address on that verified domain, such as hello@example.com.
• A Volanea secret API key beginning with sk_ or sk_test_.
• A WPForms form containing, at minimum, an email field and preferably a first-name field.
• Uncanny Automator installed on the WordPress site where the form is submitted.

Use a real, verified sender identity rather than a visitor-supplied value. A safe sender is something like support@yourdomain.com; the visitor’s address belongs in the to field, and their email can also be included in replyTo only when the workflow genuinely needs replies to go to that person.

Volanea documents secret keys as the credentials for authenticated API requests, while test keys run the sending pipeline and log the message without delivering it. That makes a test key the appropriate first step while you validate token mapping and email content. (volanea.com)

If you have not yet chosen an account tier or need to estimate the effect of form confirmations, support alerts, receipts, and onboarding messages on your monthly volume, review transactional email pricing before moving the recipe into production.

The concrete Uncanny Automator trigger

This guide’s trigger is:

WPForms → A form is submitted

Choose Everyone when the contact form can be submitted by logged-out visitors. Choose Logged-in users only if the workflow should run exclusively for authenticated WordPress users and you deliberately want user context to be part of the recipe.

Create a form with fields similar to these:

Then create the recipe:

1. In WordPress admin, go to Automator → Add New.
2. Select Everyone and confirm the recipe type.
3. Give the recipe a clear operational name, such as Contact form acknowledgement via Volanea.
4. Select WPForms as the trigger integration.
5. Select A form is submitted as the trigger.
6. Select the specific contact form.
7. Save the trigger.
8. Add the action Webhooks → Send data to webhook.

Automator exposes trigger data as tokens. In a form recipe, available tokens can include the form name and submitted field values, and those tokens can be inserted into subsequent actions. (automatorplugin.com)

Do not type token placeholders by hand unless you are copying one that Automator inserted for you. In every field that supports a value, use the * token selector beside the field and choose the matching form value. Automator’s guidance is explicit that the generated token format should not be manually edited. (automatorplugin.com)

Configure the outgoing webhook action

Open the configuration panel for Send data to webhook and use the following values.

Automator defaults an outbound webhook to POST, but its default body format can be x-www-form-urlencoded. Change the format to JSON because Volanea’s REST endpoint expects a JSON request body. Automator lets you add headers as key/value entries and lets you inspect the generated structure with Check data format before you save. (automatorplugin.com)

Map form tokens to the Volanea request body

Add these body rows in the Automator action. The values shown as {{...}} represent the tokens you select from the WPForms trigger’s token picker; the exact token labels vary with your form and field names.

The slash in to/0 matters. Automator’s outbound webhook action uses forward slashes in a body key to create nested JSON, and numbered path segments create arrays. In other words, to/0 becomes the first entry in the to array. (automatorplugin.com)

Here is the exact request shape those rows should produce. It is also a useful reference for testing the Volanea request independently from WordPress:

curl --request POST 'https://api.volanea.com/v1/send' \
  --header 'Authorization: Bearer sk_test_replace_with_your_key' \
  --header 'Content-Type: application/json' \
  --header 'Idempotency-Key: wpforms-contact-ENTRY_ID' \
  --data '{
    "from": "Support <support@yourdomain.com>",
    "to": [
      "maya@example.net"
    ],
    "subject": "We received your message, Maya",
    "html": "<p>Hi Maya,</p><p>Thanks for contacting us. We received your message:</p><blockquote>Can I change plans later?</blockquote><p>Our team will reply shortly.</p>",
    "text": "Hi Maya,\n\nThanks for contacting us. We received your message:\n\nCan I change plans later?\n\nOur team will reply shortly."
  }'

In Automator, the equivalent JSON preview should look like this:

{
  "from": "Support <support@yourdomain.com>",
  "to": [
    "{{WPForms Email token}}"
  ],
  "subject": "We received your message, {{WPForms First name token}}",
  "html": "<p>Hi {{WPForms First name token}},</p><p>Thanks for contacting us. We received your message:</p><blockquote>{{WPForms Message token}}</blockquote><p>Our team will reply shortly.</p>",
  "text": "Hi {{WPForms First name token}},\n\nThanks for contacting us. We received your message:\n\n{{WPForms Message token}}\n\nOur team will reply shortly."
}

This is a direct API integration, not an SMTP configuration. Volanea’s API reference and documentation use https://api.volanea.com as the base URL and identify POST /v1/send as the transactional send endpoint. (volanea.com)

Build better email content than a raw form echo

A basic acknowledgement is useful, but it should not reveal more form data than the recipient expects. Contact forms often collect phone numbers, order references, account details, support descriptions, or files. Sending all raw fields back to the submitter can create privacy problems and may expose data that was entered in error.

For a customer-facing acknowledgement, include only:

• The first name, if collected.
• A high-level confirmation that the message was received.
• A short response-time expectation only if your team can meet it.
• A reference number if you have a reliable one.
• A way to correct an accidental submission or contact support.

For an internal team notification, use a second webhook action and a different to/0 value, such as support-team@yourdomain.com. Give it a clearly operational subject, for example New contact form: {{Topic}}, and include the full message only when the support mailbox is appropriately protected.

Avoid putting a visitor’s email address or message content directly into HTML attributes, URLs, tracking parameters, or subject lines without considering escaping and length. A plain body paragraph is safer than constructing dynamic markup from untrusted fields. Form content is user input, and user input can contain markup, line breaks, unexpected characters, or attempted injection strings.

If your form supports a category such as billing, technical support, sales, or partnership, put it in the subject only after you constrain the choices with a select field. Free-form subject inputs lead to inconsistent support-mail routing and make reporting much harder.

Authentication: where the Volanea key belongs

For a direct setup, put the Volanea secret in the Authorization header of the outgoing webhook action:

Authorization: Bearer sk_...

That header is transmitted server-to-server when WordPress runs the Automator action. It is not JavaScript configuration for the form page and must never be embedded in page source, a public WPForms field, a browser-side script, a query string, or a client-visible environment value.

A Volanea secret key can send email and must be treated as a production credential. If it is exposed in browser-visible configuration, any visitor can retrieve it and make API requests under your Volanea project. That can create spam, consume sending capacity, damage domain reputation, and make forensic attribution far harder.

There is an important operational distinction: the outgoing webhook action is server-side, but a key saved in the recipe is still a WordPress-admin secret. People with sufficient WordPress administrative access, database access, backups, migration exports, or log access may be able to access it. Keep WordPress administrator access narrow, protect backups, and avoid screenshots that reveal request headers.

The safer production pattern: a small relay

For a high-value production site, prefer a relay endpoint you control. Automator sends only form data and a separate shared webhook secret to the relay; the relay stores VOLANEA_API_KEY in its host’s secret manager or environment configuration and calls Volanea.

That architecture adds one hop, but it improves credential handling substantially:

• The Volanea key does not live in the Automator recipe or WordPress database.
• You can validate and normalize recipient addresses before sending.
• You can enforce a fixed sender address and prevent a recipe editor from changing it.
• You can generate a durable idempotency key from the form-entry ID.
• You can capture Volanea response IDs and send failures to your monitoring system.
• You can rotate the Volanea key without editing WordPress recipes.

A relay does not need to be a large application. It can be a small serverless handler, a WordPress must-use plugin endpoint, or an internal service. The critical property is that the Volanea secret is available only to server-side code.

For endpoint details, request fields, and authentication behavior, use the Volanea API reference and setup guides as the source of truth rather than relying on copied snippets from a recipe export.

Add retry protection before you make the recipe live

An HTTP timeout does not prove that Volanea failed to accept a request. The request may have reached Volanea and been queued, while the response back to WordPress was interrupted. Retrying the same POST without protection can therefore send a second acknowledgement.

Volanea supports the Idempotency-Key header on POST /v1/send. The same key must represent the same logical send attempt; retries of that same send reuse the key, while a genuinely new email receives a new key. (api.volanea.com)

For a form confirmation, the strongest idempotency key is based on an immutable form-entry identifier. If your trigger exposes an entry ID token, use a deterministic value like:

wpforms-contact-confirmation-{{entry ID}}

Do not use the recipient address alone. A customer can legitimately submit two different support messages from the same address. Do not use the current timestamp alone either: a retry may generate a fresh timestamp and become indistinguishable from a new send.

If your chosen Automator trigger does not expose a stable entry or submission ID that can be inserted into a header, use the relay approach. The relay can derive a stable key from an entry ID in the payload, store the key alongside the entry, and reuse it whenever the incoming webhook is retried.

Uncanny Automator’s asynchronous-action behavior can retry failures, and its documented default maximum for failed asynchronous actions is three retries. That is useful for transient failures, but it reinforces why email sends should be idempotent. (docs.automatorplugin.com)

Test the recipe safely

Start with a Volanea test key and a mailbox you control. Do not test using a customer’s address or a production support queue.

Use this testing sequence:

1. Keep the recipe, trigger, and action in draft while you map tokens.
2. Use Check data format in the outgoing webhook action to inspect the generated JSON shape.
3. Confirm that to is an array, not a comma-separated string.
4. Confirm the from address belongs to your verified sending domain.
5. Submit a test form using a controlled email inbox.
6. Inspect the Automator recipe and action logs.
7. Inspect the Volanea message record and confirm the rendered content, recipient, sender, and status.
8. Switch to a live Volanea secret key only after the payload and content are correct.
9. Make the action live, then make the recipe live.

Automator provides recipe, trigger, and action logs, which let you establish whether the trigger completed and whether the outgoing webhook action succeeded or failed. (automatorplugin.com)

Test both a typical submission and the awkward cases: missing first name, an internationalized email address, a long message, emojis, quotation marks, line breaks, and an address that is already suppressed. Those cases reveal whether your body copy reads naturally and whether the integration treats data as text rather than as markup.

A successful API acceptance is not the same thing as mailbox placement. Transactional delivery happens after the request is accepted, and a recipient can still be skipped because of suppression or other sending controls. Monitor the event history instead of assuming that HTTP success means an inbox receipt.

When this breaks

Every integration has failure points. Here, the hop is specific: WordPress runs Automator, Automator makes an HTTP request, and Volanea receives and processes the send request. Diagnose the stage before changing random settings.

The recipe never starts

If there is no Automator recipe run, the problem is upstream of Volanea. Confirm that the selected WPForms form is the same form embedded on the page, that the trigger is saved, and that the trigger, action, and recipe are all set to Live. Automator’s troubleshooting guidance specifically calls out the need for every level of a recipe to be live. (automatorplugin.com)

Also confirm the recipe type. A public contact form needs an Everyone recipe. If you configure a logged-in recipe for a form that anonymous visitors submit, the expected event will not have the user context that recipe type requires.

The request is rejected with authentication or sender errors

A 401 or authentication-related error usually means the authorization value is missing, malformed, revoked, or copied with an accidental space or quote. The header must be exactly Authorization with a value formatted as Bearer followed by the Volanea secret key.

A sender or permission error commonly means that the from address does not belong to a verified sending domain, or that a test key and live project configuration have been mixed. Keep the sender fixed rather than making it a form token.

The webhook times out, then the recipient gets duplicate mail

This is the most important failure mode to design for. The HTTP request may have succeeded at Volanea even though WordPress or Automator did not receive a response. A retry can make a second email unless the retry repeats the exact same Idempotency-Key.

Use a stable key derived from the form-entry ID, not one generated separately on every request. If Automator cannot construct that stable header from tokens for your trigger, send the webhook to a relay and generate the key there. Do not “solve” duplicate sends by disabling all retries; that merely trades duplicate risk for lost-message risk.

Some payload fields are missing

Tokens are scoped to the recipe trigger. A field will be absent if it was not collected on that form, if the form field was renamed or deleted, if the recipe references a different form, or if the event type does not provide the value you expected.

Plan differences can also matter. Automator’s available integrations, trigger variants, conditions, loops, and incoming-webhook capabilities vary by edition and connected plugin. Build the request using the actual token picker on the site where the recipe will run, then validate the JSON preview before publishing.

Use defensive content design. Do not make the entire email meaningless when first_name is blank. Write Hello, rather than Hello {{first_name}}, if no reliable fallback exists, and avoid putting optional fields into the email subject.

The JSON body is malformed

The most common mapping mistake is sending to as a plain string instead of an array. In Automator’s key/value interface, use to/0 for the first recipient. For nested structures, use forward-slash-separated paths; Automator builds the JSON object or array from those paths. (automatorplugin.com)

The second common mistake is leaving the data format set to x-www-form-urlencoded. Set it to JSON, use Check data format, and send a test request before making the recipe live.

The action succeeds but the message is not delivered

Check Volanea’s event and message records. The address may be suppressed after a bounce, complaint, unsubscribe, or manual suppression; it may also be invalid or blocked by recipient-side controls. Do not automatically fall back to another sender for a suppression event. That defeats suppression handling and can damage deliverability.

For addresses collected through public forms, consider validating the address before you use it for follow-up sequences. You can use the email verification tool during testing or in a controlled operational process, but verification should complement—not replace—consent, suppression checks, and proper bounce handling.

Direct webhook versus relay: which should you choose?

A direct outgoing webhook to Volanea is the fastest route when you need a simple acknowledgement, a low-volume notification, or a proof of concept. It has fewer moving parts and lets a WordPress administrator manage the flow in one recipe.

Choose the direct route when:

• The recipient address and content are straightforward form tokens.
• The sender address is fixed.
• The site has tightly controlled WordPress administrator access.
• You can construct a stable idempotency key from an Automator token.
• You have a clear process for rotating the stored key.

Choose a relay when:

• The email is business-critical, such as a receipt, credential, access link, or compliance notice.
• You need to keep the Volanea key out of the WordPress database and recipe settings.
• You need richer validation, rate limiting, auditing, or conditional content.
• You need a durable idempotency store.
• You want to use templates, attachments, multiple destinations, or a custom event schema without making the recipe difficult to maintain.

The relay route is also the better option when multiple recipes send email. Instead of repeating credentials and payload rules in every action, each recipe sends a controlled event such as contact_form_received to your relay, and the relay owns Volanea-specific formatting and policy.

Operational practices for reliable automated email

Treat this recipe as part of your customer communication system, not as a one-time automation. Assign an owner who can update the sender, confirm the form still maps to the expected fields, and review failures after WordPress, WPForms, or Automator updates.

Keep an operational checklist:

• Use a fixed, verified sender address.
• Keep the confirmation content short and expected.
• Include a plain-text fallback for accessibility and resilient rendering.
• Use a stable idempotency key for each form submission.
• Check Automator action logs when an expected email is missing.
• Check Volanea events when an API request was accepted but delivery is unclear.
• Rotate secret keys after staff changes, suspected exposure, or periodic security reviews.
• Re-test the recipe after changing form fields, cloning a form, or moving the site between environments.

Also decide whether a form submission should send an acknowledgement at all. A contact form normally can; a sensitive security-report form may be better served by a neutral acknowledgement that does not repeat content; an unsubscribe or privacy request may need a different workflow entirely. Automation should reflect the user expectation created by the form.

Conclusion

To send email from Uncanny Automator with Volanea, use an Everyone recipe with the WPForms trigger A form is submitted, then add Webhooks → Send data to webhook as the action. Configure a JSON POST to https://api.volanea.com/v1/send, map form tokens into to/0, subject, html, and text, and authenticate with a Volanea secret key in the Authorization header.

The integration is simple, but reliability depends on the details: use a verified sender domain, keep the key server-side, preview the JSON payload, and attach an idempotency key based on a stable submission ID. For sensitive or high-volume workflows, put a small relay between Automator and Volanea so credentials, policy, retries, and observability live in one controlled place.

FAQ

Does Volanea have a native Uncanny Automator integration?

No. This setup uses Uncanny Automator’s outbound webhook action to call Volanea’s REST API directly. There is no Volanea marketplace app or native Automator action to install.

Can I send directly from Uncanny Automator without Zapier or Make?

Yes. Uncanny Automator can send outbound webhooks to services that accept HTTP requests, including a JSON POST to Volanea’s API. Zapier or Make are optional middleware choices, not requirements for the direct route. (automatorplugin.com)

Where should I store the Volanea API key?

For a simple direct integration, put it in the outgoing webhook action’s Authorization header so it is sent server-to-server. For stronger production secret handling, store it in a server-side relay’s environment or secret manager and let Automator call the relay instead.

How do I stop duplicate emails after a webhook timeout?

Send a stable Idempotency-Key with every request. Base it on the immutable form-entry or submission ID, and reuse the same key if that logical send is retried. Do not generate a fresh key for each retry.

Can one recipe notify both the visitor and my support team?

Yes. Add two outbound webhook actions: one sends a concise confirmation to the visitor, and one sends an internal notification to the team. Use distinct subjects and content, and avoid exposing internal notes or sensitive form data in the visitor-facing message.