How to Send Email From Act! With Volanea

Act! does not have a native Volanea app or marketplace plug-in. The practical way to send email from Act! with Volanea is to use Act!'s Zapier integration as the event source, then pass a deliberately small contact payload to a server-side relay that calls the Volanea REST API.

This approach is useful when Act! is the source of truth for a new lead, customer, or contact, but a product, operations, or engineering team wants deliverable transactional email, templates, event tracking, and API-based sending outside the CRM. It also keeps the email provider credential out of browsers, email templates, and individual users' Act! records.

What this integration does—and does not do

The workflow in this guide is event-driven:

1. A contact is added in Act!.
2. Zapier's Act! New Contact trigger finds that new contact.
3. Zapier sends selected fields to a webhook endpoint that you control.
4. The endpoint validates the request, prevents a repeat send, and makes one Volanea REST API request.
5. Volanea accepts the message for delivery and returns a response that your relay records.

This is not an Act! plug-in. There is no Volanea installation inside Act!, no custom Act! toolbar button, and no assumption that Act! itself can store or safely use a Volanea API key. Zapier is the connector between the CRM event and your backend.

That distinction matters. A CRM contact record often contains more personal information than an email service needs. The relay should receive only the address and merge values needed for the message. It should not forward every available Act! field by default merely because Zapier can expose it.

Why use a relay instead of posting directly from Zapier?

A direct Zapier Webhooks action can be appropriate for a very small internal workflow. A relay is usually safer for production email because it gives you a place to:

• keep the Volanea API key in a server-side secret store;
• validate recipient and event data before sending;
• generate an idempotency key so retries do not create duplicate messages;
• choose a template and subject in code rather than in a no-code action;
• log the provider message ID without placing it in the contact record;
• change providers or API versions without rebuilding every Zap.

It also makes permissions clearer. A Zapier editor can map contact fields and invoke a narrowly scoped webhook URL without necessarily being given the credential that can send from your entire domain.

The concrete Act! trigger: New Contact in Zapier

For this integration, the triggering event is New Contact in the Act! app on Zapier. A new contact record in Act! is what starts the Zap. This is a contact-created workflow, not a generic “record changed” webhook and not an Act! form-submission event.

In Zapier, create a Zap and choose Act! as the trigger app. Select New Contact, connect the Act! account, and test the trigger with a recently created contact. The test step is important: it shows the fields that the connected account actually makes available for mapping.

Contact fields can vary with Act! configuration, user permissions, customizations, and the quality of the underlying data. Do not build a production email flow on the assumption that every record has an email address, first name, or a consistently populated company name. Inspect the sample and add explicit rules for incomplete records.

A recommended Zap structure

A practical Zap has these steps:

1. Trigger: Act! — New Contact.
2. Filter: continue only if the mapped email value exists and contains an @ character at minimum.
3. Optional formatter step: normalize whitespace and lowercase the email address.
4. Action: Webhooks by Zapier — send a JSON POST to your relay.
5. Optional logging action: record a successful handoff in a system that is appropriate for operational logs.

The filter is not a substitute for address validation, but it prevents obvious bad records from reaching the relay. For higher-value sends, validate an address before creating or updating the Act! contact, or use an address-validation step such as the email verification tool in your intake process.

What Act! actually sends in this route

It is important to be precise about the payload. In this setup, Act! is not directly making an outbound HTTP request to Volanea. The Act! Zapier trigger supplies contact data to Zapier, and Zapier constructs the JSON body for your webhook action. There is therefore no universal, native Act! webhook JSON schema to copy into an API client.

That is an advantage: you define a stable relay contract even if Act! field labels or Zapier's displayed field set changes. Map the tested Act! contact values to this intentionally small JSON object in the Webhooks by Zapier action:

{
  "event": "act.contact.created",
  "contact": {
    "id": "<map the Act! Contact ID field>",
    "email": "<map the Act! Email field>",
    "first_name": "<map the Act! First Name field>",
    "last_name": "<map the Act! Last Name field>",
    "company": "<map the Act! Company field>"
  }
}

In the Zapier Webhooks action, set the method to POST, set the request body type to JSON, and map each angle-bracketed value by selecting the corresponding output from the tested New Contact step. The literal event value is useful because a single relay may later receive other CRM events too.

Do not manually type a test contact's address into the action. Select the dynamic Act! field. Test with a second contact after publishing so that you confirm dynamic data, rather than a sample value, is used.

Build the secure webhook relay

Your relay can be a small service in a platform such as Cloudflare Workers, AWS Lambda, Vercel Functions, Fly.io, or an existing application backend. The hosting choice matters less than these properties: HTTPS, server-side environment variables, request authentication, controlled logging, and durable duplicate protection.

The code below is a complete JavaScript-style handler illustrating the contract. It accepts the Zapier-built payload, checks required values, creates a deterministic idempotency key, and posts the mapped message to Volanea. Store the provider endpoint, API key, verified sender, and shared webhook secret as environment variables rather than hard-coding them.

// POST /integrations/act/contact-created
// Environment variables:
// VOLANEA_API_URL=https://api.volanea.com/v1/emails
// VOLANEA_API_KEY=server-side Volanea API key
// VOLANEA_FROM=Acme Team <hello@updates.example.com>
// ZAPIER_WEBHOOK_SECRET=a-long-random-secret

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    if (request.headers.get("x-zapier-secret") !== env.ZAPIER_WEBHOOK_SECRET) {
      return new Response("Unauthorized", { status: 401 });
    }

    let input;
    try {
      input = await request.json();
    } catch {
      return Response.json({ error: "Invalid JSON" }, { status: 400 });
    }

    const contact = input.contact || {};
    const email = String(contact.email || "").trim().toLowerCase();
    const contactId = String(contact.id || "").trim();
    const firstName = String(contact.first_name || "").trim();

    if (input.event !== "act.contact.created" || !contactId || !email.includes("@")) {
      return Response.json({ error: "Missing event, contact ID, or email" }, { status: 422 });
    }

    // Use a real durable store (database/KV/Redis) for this check in production.
    // The key must be retained before making the provider request.
    const idempotencyKey = `act-contact-created:${contactId}`;
    const previouslySent = await hasAlreadyProcessed(idempotencyKey);
    if (previouslySent) {
      return Response.json({ status: "duplicate_ignored", idempotencyKey }, { status: 200 });
    }

    const displayName = firstName ? ` ${escapeHtml(firstName)}` : "";
    const subject = "Welcome to Acme";
    const html = `<p>Hello${displayName},</p><p>Thanks for getting in touch with Acme.</p>`;

    const volaneaResponse = await fetch(env.VOLANEA_API_URL, {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify({
        from: env.VOLANEA_FROM,
        to: [email],
        subject,
        html
      })
    });

    const responseText = await volaneaResponse.text();
    if (!volaneaResponse.ok) {
      console.error("Volanea send failed", volaneaResponse.status, responseText);
      return new Response("Email provider request failed", { status: 502 });
    }

    await markProcessed(idempotencyKey, responseText);
    return Response.json({ status: "sent", idempotencyKey }, { status: 202 });
  }
};

function escapeHtml(value) {
  return value.replace(/[&<>'"]/g, char => ({
    "&": "&amp;", "<": "&lt;", ">": "&gt;", "'": "&#39;", "\"": "&quot;"
  }[char]));
}

The message field mapping is deliberately visible in the code: contact.email becomes to, the configured sender becomes from, and the Act! first name is merged into HTML after escaping. In a real deployment, replace hasAlreadyProcessed and markProcessed with calls to a durable datastore; in-memory state disappears across serverless invocations and cannot reliably stop duplicates.

Confirm the current endpoint, authentication header, accepted recipient format, and any template parameters against the Volanea API reference and setup guides before deployment. API credentials and send payloads are part of your operational interface, so code should follow the version documented for the account rather than a copied snippet from an old integration.

Map fields intentionally, not mechanically

A contact-created email should have a narrow, documented purpose. The most common implementation is an acknowledgement, onboarding message, owner notification, or consent-confirmation message. It should not automatically become a marketing campaign just because a new record exists.

Use this mapping table as the design baseline:

Keep the contact ID even if the email message itself does not need it. Addresses can be corrected, reused, or changed. The Act! record identifier is the better event correlation key for a “created contact” message.

If your process creates a contact before a valid address is known, choose one of two explicit policies: skip the email permanently and log the reason, or create a later workflow that sends only after an address is added and validated. Do not silently send to a blank field, substitute an internal address, or guess an address from a name and domain.

Use template data for more complex messages

For longer welcome, receipt, or account emails, a maintained transactional template is generally easier to review than concatenating HTML in a function. The relay can build a compact data object such as { first_name, company, contact_id } and send it using the template mechanism documented by Volanea.

Regardless of where the HTML lives, treat Act! values as untrusted input. Escape values in HTML, avoid using contact fields to create URLs without validation, and do not include sensitive CRM notes in an email just because they are available to Zapier.

Keep the Volanea API key off the client and out of Act!

The Volanea API key belongs in the relay's encrypted server-side environment or secret manager. It must not be put in an Act! contact field, a public web form, browser JavaScript, an email template, a shared spreadsheet, or the visible URL/query string of a webhook.

For the route in this guide, Zapier stores only a separate random ZAPIER_WEBHOOK_SECRET in the Webhooks action as an x-zapier-secret header. That secret lets the relay distinguish expected requests from arbitrary internet traffic. The relay alone reads VOLANEA_API_KEY and attaches it when it calls Volanea.

This two-secret model gives you a clean rotation path. If someone leaves the team or a Zap configuration is exposed, rotate the webhook secret and update the Zap. If there is any concern that the email-provider credential was exposed, rotate the Volanea API key in Volanea and update the server environment. These are different incidents and should not be treated as one shared password.

Minimum access and sender control

Use an API key intended for this application or environment when the platform supports separate credentials. Keep production and test sends separate. Configure VOLANEA_FROM as a sender address on a domain you control and authenticate that domain with the DNS records Volanea specifies.

A well-built automation can still have poor inbox placement if it sends from an unverified or misaligned domain. Transactional messages should use a recognizable From name, a monitored reply address where appropriate, and a message purpose recipients reasonably expect after becoming a contact.

Test the workflow before turning it on

Testing must cover both systems and the boundary between them. Create a dedicated test contact in Act!—not a customer record—and use an inbox your team controls. Then work through the result from trigger to delivery.

A useful test checklist is:

• Create a new Act! contact with an address, first name, and contact ID visible in the Zap test output.
• Verify that the Zap filter allows the test only when the email is present.
• Inspect the relay request log and ensure it contains the event and contact ID, but not unnecessarily sensitive data.
• Confirm that the relay receives the expected JSON field names and returns a successful response.
• Confirm Volanea records an accepted send and that the mailbox receives the message.
• Run the Zap test or replay scenario again and confirm the idempotency control returns duplicate_ignored rather than sending a second welcome email.
• Create a contact with no email and verify the flow stops safely.

Separate “provider accepted the API request” from “recipient received the message.” Acceptance shows that the handoff worked. Delivery, bounces, suppression, inbox placement, and recipient engagement are subsequent outcomes that deserve their own monitoring.

When this breaks

Every automation needs a failure model. The vulnerable boundary here is not an imaginary direct Act!-to-Volanea connection; it is Act! contact data flowing through Zapier to your relay, followed by the relay's HTTP request to Volanea.

Retries can cause duplicate sends

A network failure can occur after Volanea receives a request but before the relay receives the response. Zapier may also retry a failed webhook action according to its delivery behavior, and an operator may replay a task manually. From the sending system's point of view, those attempts can look identical.

That is why the relay marks a durable act-contact-created:<contact-id> idempotency key before or atomically with sending. Do not rely solely on a Zap's task history to avoid duplicates. Your store should record at least the key, first-seen time, provider response or message ID, and final status.

If the same contact should receive a new welcome message after a meaningful correction, define a new event version or key—for example, an explicit verified-email event—not a second contact-created event. This prevents routine retries from being confused with a business-approved resend.

Webhook timeouts and slow provider calls

A webhook caller expects a timely HTTP response. If the relay performs slow database work, waits on a provider outage, or tries several retries synchronously, the webhook action can time out and invoke a retry even while the original work continues.

Keep the request path short. Validate, reserve the idempotency key, enqueue a send job where your infrastructure supports queues, and return a success response once the job is safely accepted. The background worker can make controlled provider retries with the same idempotency key. If you do send synchronously for a low-volume setup, use conservative timeouts and never retry blindly after an ambiguous network error.

Missing or differently named contact fields

Act! contact fields shown to Zapier can be absent on a particular record, unavailable to the connected user, or represented differently from what a developer expected. A sample record with an email does not prove every production record has one. Custom fields are particularly prone to changed labels and blank values.

Protect against this in two places: a Zap filter catches obvious blanks, and the relay treats id and email as required. Return a clear 422 response for an invalid payload and log the field names that were missing, not the entire raw contact record. Review these failures periodically; they often reveal a CRM process issue rather than an API issue.

Authentication and sender failures

A 401 or 403 from the relay usually indicates that the Zapier shared secret is missing or wrong. A provider authorization failure usually points to an expired, revoked, or incorrectly deployed Volanea credential. A sender-related rejection points to an unverified From address or domain configuration problem.

Give each failure category a distinct alert and runbook. “Email failed” is not enough information for an operator to know whether to fix a Zap header, rotate a server secret, correct a sender identity, or repair an individual Act! record.

Operational and compliance considerations

A contact record is not automatically marketing consent. The safest first use for this integration is a transactional or operational message clearly connected to why the contact was created: a request acknowledgement, account notification, or confirmation of a service interaction.

If the intended message is promotional, add the appropriate consent, segmentation, unsubscribe, and regional compliance controls before sending. Act!'s creation date alone is not a durable consent model. Capture the consent source and timestamp in the CRM or a dedicated preference system, then make that signal part of the Zap filter and relay validation.

Also decide what belongs in Act! after a send. Writing every delivery event back to a CRM can create noise and expose operational data to users who do not need it. Often the better design is to retain provider IDs and event logs in the relay's database, while writing only a high-level, human-useful note to the CRM when a business process requires it.

Alternatives to the New Contact workflow

The New Contact trigger is the right choice when contact creation itself is the business event. It is not the right choice for every message.

For example, a sales team may need an email when an opportunity reaches a defined milestone, while support may need a confirmation after an intake process creates a case. Before adapting this guide, identify the exact Act! data change that represents permission to send. Then verify that the chosen connector exposes that event; do not approximate it by sending on every contact edit.

If no suitable Act! trigger is available in the connected account, use middleware as the integration boundary rather than claiming there is a native outbound HTTP feature. A scheduled CRM export or a connector-supported event can still feed your backend, but it should preserve the same principles: a clear event contract, server-side provider credentials, validation, and idempotency.

Conclusion: make the CRM event small and the sending system reliable

To send email from Act! with Volanea, use the Act! New Contact trigger in Zapier, map only necessary contact values into a controlled JSON body, and send that body to a secure relay. The relay is where the Volanea API key, sender identity, validation, retry policy, and duplicate protection belong.

This design is more durable than treating a CRM automation as an email API client. It acknowledges the actual integration path, gives engineering a stable point to observe and improve delivery, and lets sales or operations teams continue creating contacts in Act! without handling email infrastructure secrets.

FAQ

Does Volanea have a native Act! integration?

No native Act! app or marketplace plug-in is required or assumed in this setup. The integration uses Act!'s Zapier New Contact trigger and a webhook relay that calls Volanea's REST API.

What event sends the email?

The event is a new contact in Act!. In Zapier, select Act! as the trigger app and New Contact as the trigger event. The Zapier step then maps that contact's ID, email, and optional name fields to your relay payload.

Where should the Volanea API key be stored?

Store it only as an encrypted server-side secret or environment variable in the relay. Do not place it in Act!, in browser-visible code, or in the Zapier request body. Zapier should use a separate shared webhook secret to authenticate to the relay.

How do I stop retries from sending two emails?

Use the immutable Act! contact ID to create and persist an idempotency key such as act-contact-created:<contact-id>. Check that key before sending and retain the outcome in a durable store so webhook retries and manual replays return success without sending again.

Can I use this for marketing email?

Only if the recipient has the required marketing consent and your workflow applies preference and unsubscribe controls. A new Act! contact record by itself is not proof that promotional email is appropriate; transactional messages tied to the contact's action are the safer default.