How to Send Email from Keap with Volanea

If you need to send email from Keap without relying on a native marketplace app, Keap’s Automation Builder can call Volanea directly over HTTPS. The practical integration is a Keap automation trigger followed by an HTTP Request action that sends a JSON email payload to Volanea’s REST API.

Volanea does not provide a native Keap app, marketplace listing, or one-click plugin. That is not a blocker: Keap’s HTTP Request action supports outbound POST, headers, a request body, merge fields, and request testing. That makes it suitable for sending transactional messages when a Keap automation reaches a specific business event.

This guide builds a concrete example: a contact submits a Keap form, enters an automation through the Form Submitted trigger, and receives a welcome email through Volanea. The same pattern also works when Keap runs an automation because a tag is applied, a product is purchased, an appointment changes, or an opportunity moves pipeline stage.

What this Keap and Volanea integration does

The integration has two systems with distinct responsibilities:

• Keap owns the CRM record and the automation event. It decides that a contact submitted a form, was tagged, bought a product, or reached another automation goal.
• Volanea owns the sending request. It accepts the recipient, sender, subject, and message content, then processes the email through its transactional sending pipeline.

The direct path looks like this:

1. A contact submits a Keap form.
2. The contact enters an Automation Builder campaign through the Form Submitted goal.
3. The sequence reaches an HTTP Request action.
4. Keap merges the contact’s saved fields into the request body and headers.
5. Keap sends an HTTPS POST request to https://api.volanea.com/v1/send.
6. Volanea accepts the transactional email request and returns a response to Keap’s HTTP Request action.

This is intentionally event-driven. You do not export contacts, run a scheduled CSV job, or poll Keap for new records. The email request happens at the point in the automation where the business event becomes true.

The concrete Keap trigger: Form Submitted

For this walkthrough, use Keap’s Form Submitted automation trigger. In Keap Automation Builder, this is the goal that starts or routes a contact into an automation after that contact submits the selected form.

That choice is useful for a welcome email because it gives you an explicit moment to send: the person completed the form, Keap has created or updated the contact record, and the automation can immediately continue into a sequence.

Example workflow

Imagine that your website has a Keap landing-page form named Newsletter signup. You want every new signup to receive a welcome message from hello@example.com.

Set up the automation in this order:

1. Create or open an automation in Keap Automation Builder.
2. Add the Form Submitted goal to the canvas.
3. Configure that goal for the Newsletter signup form.
4. Connect the goal to a sequence.
5. Inside the sequence, add an HTTP Request action.
6. Configure that action to call Volanea’s send endpoint.
7. Test the request with a real internal contact before publishing the automation.

Keap also supports other automation goals, so you can use the same HTTP Request action after a Tag Applied, Product Purchased, Pipeline Stage Move, appointment activity, or another supported event. The key is to choose an event that represents one logical email send, not merely an incidental contact update.

For example, a welcome email should usually be triggered by form submission or a dedicated Send welcome email tag. A payment receipt should be triggered by a completed purchase or payment event. A deal-stage message should be triggered by the relevant pipeline-stage move.

Why Keap’s HTTP Request action is the right integration point

Keap has an older Send HTTP Post object that sends configured name/value pairs to an external server. For a modern REST API call, use the newer HTTP Request action instead. It supports request methods including POST, optional headers, a body, query parameters, merge fields, and a test view that previews the outgoing request.

That matters because Volanea expects an authenticated JSON REST request. The HTTP Request action can supply the required HTTP headers and JSON body directly, whereas a basic form-style post is better suited to older server-side scripts or webhook receivers.

Use the HTTP Request action when you want Keap to call Volanea directly. Use the older HTTP Post object only when you are intentionally posting name/value pairs to your own webhook relay.

What Keap actually sends

Keap does not automatically serialize an entire contact object and send it to Volanea. You configure the outgoing request yourself. The body is the literal body text you enter in the HTTP Request action, after Keap resolves the merge fields for the contact moving through the sequence.

Keap contact merge fields use the ~Object.FieldName~ format. For example:

• ~Contact.Id~ becomes the Keap contact ID.
• ~Contact.FirstName~ becomes the first name stored on the contact.
• ~Contact.LastName~ becomes the last name stored on the contact.
• ~Contact.Email~ becomes the contact’s email address.

For a contact named Jordan Lee with jordan@example.net and contact ID 123, the configured body below becomes the following JSON payload at send time:

{
  "from": "Example Co <hello@example.com>",
  "to": "jordan@example.net",
  "subject": "Welcome to Example Co, Jordan",
  "html": "<h1>Welcome, Jordan!</h1><p>Thanks for signing up. We are glad you are here.</p>",
  "text": "Welcome, Jordan! Thanks for signing up. We are glad you are here."
}

The exact values come from the Keap contact record and the static content configured in the action. This is important operationally: if the email field is blank, the outbound payload will contain a blank recipient. If the first name is blank, a personalized greeting can look incomplete unless you design a fallback.

Configure the direct Volanea API request in Keap

Before configuring the automation, verify a sending domain in Volanea and create a secret API key. The from address in the request should use a sender on that verified domain.

Then open the sequence that follows your Keap Form Submitted goal and add an HTTP Request action. Configure it as follows.

Request settings

The Idempotency-Key header deserves attention. It tells Volanea that repeated requests with the same key represent the same logical send. In this example, one contact can receive the version-one newsletter welcome message once, even if Keap repeats the HTTP request after an ambiguous network failure.

Do not use a random value for this header on every attempt. A random value makes each retry look like a new send and defeats idempotency. Instead, derive the value from the business event. Here, the business event is “send version-one welcome email for this Keap contact.”

Keap body text and field mapping

Paste this into the Body field of Keap’s HTTP Request action:

{
  "from": "Example Co <hello@example.com>",
  "to": "~Contact.Email~",
  "subject": "Welcome to Example Co, ~Contact.FirstName~",
  "html": "<h1>Welcome, ~Contact.FirstName~!</h1><p>Thanks for joining Example Co.</p><p>You can reply to this email if you need help getting started.</p>",
  "text": "Welcome, ~Contact.FirstName~! Thanks for joining Example Co. You can reply to this email if you need help getting started."
}

This is the complete Volanea REST call expressed in Keap’s HTTP Request configuration: the URL, authentication, content type, duplicate-protection header, and JSON request body are all explicit.

The field mapping is straightforward:

Use both html and text. HTML provides the intended visual presentation, while text gives recipients and email clients a useful alternative when HTML is disabled or unavailable.

For the full endpoint reference, sender setup guidance, and additional sending patterns, review the Volanea API reference and setup guides.

Keep the Volanea API key out of client-visible configuration

The Volanea key belongs in the Authorization header of Keap’s server-side HTTP Request action, not in a form, landing-page script, browser JavaScript bundle, URL parameter, or custom field visible to contacts.

The correct header is:

Authorization: Bearer sk_your_volanea_secret_key

Keap runs an Automation Builder HTTP Request after a contact reaches the sequence step. A visitor submitting the form should not receive the key in their browser, and the key should never be placed in the form’s hidden fields or in a redirect URL.

What “server-side” does and does not mean here

The Keap automation action is not client-side browser code, which is why it is appropriate for calling an authenticated API. But the key is still a sensitive credential stored in a configured automation. People who can view or edit that HTTP Request action may be able to see it.

Treat that access as privileged. Limit who can edit automations, use a dedicated Volanea API key for Keap rather than a shared all-purpose key, and rotate the key if an administrator leaves, an automation is copied into an untrusted account, or the credential appears in a screenshot, ticket, or export.

Do not put the key in either of these places:

• A Keap contact custom field, even if you believe only staff can see it.
• A landing-page field, including a hidden form field.
• The target URL as a query parameter.
• Email HTML, browser-side JavaScript, or a public code repository.

When a relay is the safer choice

A direct Keap-to-Volanea request is simple and works for many transactional messages. Use a small middleware relay instead when you need stronger secret isolation, more detailed audit logging, conditional business rules, custom validation, durable queues, or a more sophisticated duplicate strategy.

In that design, Keap sends non-secret contact and event data to your HTTPS endpoint. Your endpoint validates it, looks up the Volanea key from a server environment variable or managed secret store, and calls Volanea. The Volanea key never lives in Keap at all.

That additional hop is worthwhile for high-value messages such as invoices, account access notices, compliance communications, or purchase receipts. It also gives you a place to store the exact Keap event, the Volanea response, and the final send decision.

Make the email event idempotent before publishing

Email integrations fail in ways that are hard to see from the CRM screen. A request can reach Volanea successfully, but the response can be delayed or interrupted. Keap may report an error even though Volanea accepted the email. If you manually retry without a stable idempotency key, the recipient can receive duplicates.

The direct configuration uses this header:

Idempotency-Key: keap:newsletter-welcome:v1:~Contact.Id~

That value is stable for the same contact and the same version of the welcome event. If the same HTTP Request is tried again, Volanea can recognize the duplicate operation instead of producing another logical send.

Pick the key based on the message’s business meaning

Use an idempotency key that describes what should happen exactly once. Good examples include:

• keap:signup-welcome:v1:~Contact.Id~
• keap:trial-started:v1:~Contact.Id~
• keap:contract-received:v1:~Contact.Id~
• keap:course-access:v3:~Contact.Id~

Avoid basing the key only on the recipient email address. A person can legitimately need more than one distinct transactional email. Also avoid a generic key such as welcome-email, which would cause every contact to collide with every other contact.

If you revise the message in a way that should create a new send, change the event version deliberately. For example, moving from v1 to v2 makes the new welcome sequence a new logical event. Do not change versions casually; it is part of the send policy, not merely a content label.

Validate recipient data before the HTTP Request action

Keap merge fields resolve only to what is stored on the contact. They do not guarantee that the resulting data is complete, current, or deliverable.

At a minimum, use an automation decision before the HTTP Request action to avoid attempting a send when the email field is empty. Depending on your workflow, you may also want to route contacts with no first name to a generic greeting rather than sending a message that starts with “Welcome, !”

A durable design usually follows this order:

1. Form submission or another Keap goal enters the contact into the automation.
2. A decision checks that the contact has an email address.
3. A decision or separate branch chooses personalized versus generic content based on whether first name is present.
4. The HTTP Request action calls Volanea.
5. A follow-up Keap action optionally applies a tag such as Welcome API requested.

Do not use the follow-up tag as proof of inbox delivery. It means the Keap automation moved forward after the request step; it does not replace delivery-event monitoring. For higher-value mail, capture Volanea event data in your own system or a relay and use that data for operational reporting.

Before adding a new recipient to a sensitive workflow, you can also use Volanea’s email address verification tool to check address quality. Verification is not a substitute for consent or suppression handling, but it can help identify malformed and risky addresses before a sending workflow starts.

Build content that survives missing fields and email clients

Keap makes it easy to insert merge fields, but a transactional message should remain understandable when personalization is missing. The contact record may have an email address but no first name, or an old integration may have created a partial record.

Safer message content

Instead of making all meaning depend on a first name, write a message where the greeting is optional:

{
  "from": "Example Co <hello@example.com>",
  "to": "~Contact.Email~",
  "subject": "Welcome to Example Co",
  "html": "<h1>Welcome to Example Co</h1><p>Thanks for signing up. Your account updates and useful next steps will arrive here.</p>",
  "text": "Welcome to Example Co. Thanks for signing up. Your account updates and useful next steps will arrive here."
}

You can send this generic branch when first name is absent and use a separate, personalized HTTP Request branch when first name is present.

Keep the payload focused on the message. Do not insert sensitive CRM fields into an email simply because Keap makes them available as merge fields. A contact ID is useful for an idempotency key, but it typically does not belong in the recipient-facing body. The same is true for internal owner names, lifecycle scoring, notes, payment metadata, and custom fields that a recipient would not expect to see.

Test the request before you activate the automation

Keap’s HTTP Request action includes request and response testing. Use it before publishing, but test with a real internal contact record that has a safe inbox address and representative data.

A useful test plan includes these cases:

• A normal contact with first name, last name, and a valid email address.
• A contact with an email address but no first name.
• A contact with a malformed or blank email field, routed away from the send action.
• The same contact reaching the action twice, to confirm your idempotency behavior.
• A sender address on the verified Volanea domain you intend to use in production.

Inspect Keap’s request preview closely. Confirm that ~Contact.Email~ has become the intended email address and that the body remains valid JSON after each merge value is substituted. Names with quotation marks, unexpected line breaks, or unusual characters are especially useful test data because they can expose fragile manually assembled JSON.

After testing Keap’s action, check the Volanea send log. A successful API acceptance is not identical to an inbox placement guarantee, but it confirms that the request reached the sending platform and was processed as a send request rather than rejected because of missing authentication, malformed JSON, an invalid sender, or an invalid recipient field.

When this breaks: Keap-to-Volanea troubleshooting

The integration crosses an automation platform, an HTTPS request, and an email API. Troubleshoot each boundary separately instead of assuming every failure is an email-delivery problem.

Keap retries or a manual rerun creates duplicate sends

This is the most important failure mode. An HTTP request can time out after the remote server has accepted it, or an administrator can rerun a contact through an automation while investigating a problem. Without protection, both paths can create duplicate email.

Use a stable Idempotency-Key header derived from the event and contact ID. Keep the key identical for a retry of the same logical message. If a human intentionally needs to resend, define that as a new event with a new policy rather than blindly changing the key during an incident.

Also document which Keap actions are allowed to re-enter the automation. A tag-triggered campaign can loop if the same sequence applies or removes tags that qualify a contact for re-entry. Separate “message requested” operational tags from tags that are automation entry conditions.

The HTTP Request action times out or reports an error

A timeout does not always mean Volanea did not receive the request. It can mean the network or response path failed after the request was accepted. Do not immediately remove the idempotency key and retry with a fresh value.

First, inspect the Keap HTTP Request test or action result. Then check Volanea’s send records for the recipient, subject, and approximate timestamp. If a matching request was accepted, the same idempotency key is what protects the recipient when Keap retries.

For critical workflows, use a relay with a durable queue and application logs. That architecture gives you a durable record before calling Volanea, lets you retry transient failures deliberately, and prevents a temporary Keap-to-API failure from becoming an untraceable manual support task.

The request reaches Volanea but the payload fields are blank

Keap sends the fields you configured, not a complete contact schema. A merge field can resolve to an empty string when the record does not contain a value, when a custom field was not populated by the form, or when the field is not available in the context you expected.

Use Keap’s request preview with several representative contacts. Confirm that the selected automation goal actually occurs after the contact data has been written. If your workflow depends on a custom field, ensure the relevant form or upstream integration populates that field before the contact reaches the HTTP Request action.

Plan availability and account configuration can also affect which automation features and field contexts your team can use. Do not copy an automation from another Keap account and assume every object, custom field, form, or sequence behaves identically. Re-test the actual request in the destination account.

Volanea returns an authentication error

Check that the HTTP Request action uses the exact Authorization header format:

Authorization: Bearer sk_your_volanea_secret_key

Common mistakes include omitting Bearer, adding quotes around the whole header value, using a test key in the wrong environment, pasting whitespace into the key, or storing the key in the body instead of the header. Rotate the key rather than continuing to use it if it was copied into an unsafe location.

Volanea rejects the sender or recipient

Make sure the from value uses an address on a domain verified in Volanea. Then verify the merged to field in Keap’s request preview. A static test address can make an integration appear healthy while the production merge field is blank, outdated, or malformed.

Keep sender identity stable. Switching sender domains, changing display names frequently, or using a sender address unrelated to the recipient’s sign-up context can make transactional mail less recognizable and harder to troubleshoot.

When to use direct HTTP requests versus middleware

The direct Keap HTTP Request approach is the shortest path and is appropriate when the message is simple, the automation team is trusted to manage the credential, and the event can be represented safely with Keap merge fields.

Choose a middleware relay when you need any of the following:

• A secret manager rather than storing the Volanea API key in an automation configuration.
• Database-backed idempotency records and audit logs.
• Conditional templates based on complex rules.
• Input validation, HTML escaping, or data normalization beyond Keap’s merge behavior.
• Queueing and controlled retries for operationally important email.
• A way to combine data from Keap with your application, billing system, or product database.
• A way to receive Volanea lifecycle events and write delivery information back to your systems.

The relay does not replace Keap. Keap remains the trigger and CRM workflow engine. The relay becomes the secure integration boundary between Keap’s business event and Volanea’s sending API.

Conclusion: use Keap as the event source and Volanea as the sending layer

To send email from Keap with Volanea, use Keap Automation Builder’s Form Submitted goal and an HTTP Request action. Set the target to Volanea’s POST /v1/send endpoint, authenticate with a Bearer secret key in the action header, provide a JSON body with Keap merge fields, and send a stable Idempotency-Key for every logical message.

The direct integration is effective because it is explicit. Keap decides when an automation event happens. The HTTP Request action exposes the exact payload. Volanea receives a standard authenticated send request. And your idempotency policy prevents the most damaging integration error: a retry that becomes an accidental duplicate email.

Start with one controlled transactional flow, test it with representative Keap contacts, inspect the resulting Volanea sends, and only then expand the pattern to purchases, lifecycle events, appointment workflows, and pipeline stages.

FAQ

Can Keap send directly to Volanea without a marketplace plugin?

Yes. Keap’s Automation Builder includes an HTTP Request action that can send an authenticated POST request with headers, a body, and merge fields. Volanea does not need a native Keap marketplace app for this integration pattern.

What Keap event should trigger the Volanea email?

Use the Keap automation goal that represents the real business event. For a signup email, use Form Submitted. For a product message, use a purchase-related goal. For lifecycle email, a deliberately applied tag is often easier to control than generic contact updates.

Where should the Volanea API key go in Keap?

Put it in the HTTP Request action’s Authorization header as Bearer sk_.... Do not place it in a contact field, landing-page form, URL parameter, or browser-side code. Restrict who can edit the automation because editors may be able to view the configured credential.

How do I prevent duplicate emails when Keap retries an HTTP request?

Set a stable Idempotency-Key header based on the business event and ~Contact.Id~, such as keap:newsletter-welcome:v1:~Contact.Id~. Use the exact same key when retrying the same logical email.

Should I use Keap’s HTTP Post object or HTTP Request action?

Use HTTP Request for a direct Volanea REST API call because it supports methods, headers, a request body, merge fields, and testing. Use the older HTTP Post object when you intentionally need to send configured name/value pairs to a server-side script or webhook relay.