How to Send Email From Apollo.io With Volanea

Apollo does not offer a native Volanea app, marketplace listing, or documented generic outbound HTTP action for standard workflows. The reliable way to send email from Apollo.io with Volanea is to use Apollo’s supported Zapier integration as the trigger layer, then call a small server-side middleware endpoint that securely sends through the Volanea REST API.

This architecture is deliberate. Apollo remains the source of contact events, Zapier receives the event using Apollo’s supported New Contact trigger, your middleware validates and maps the data, and Volanea accepts the final transactional send. It avoids placing an email API secret in Apollo, in a browser, or in a client-visible automation configuration.

The integration architecture

Here is the production-safe path:

1. A person is saved as a contact in Apollo.
2. Apollo’s New Contact Zapier trigger fires.
3. Zapier maps the Apollo contact fields into a POST request to your middleware endpoint.
4. Your middleware validates the event and builds a Volanea POST /v1/send request.
5. Volanea queues the email, applies suppression and unsubscribe controls, and sends using your verified domain.

Apollo documents its Zapier integration as supporting triggers including New contact, Contact updated, New account, and Account updated. The concrete trigger used in this guide is New contact, which Apollo defines as firing when you save a new contact in Apollo.

The important distinction is that this is not an Apollo-to-Volanea native connection. Zapier is the supported event bridge, and your middleware is the security and reliability boundary.

Apollo contact saved
        ↓
Zapier: Apollo.io — New Contact
        ↓
Zapier: Webhooks by Zapier — POST
        ↓
Your server-side endpoint
        ↓
Volanea REST API — POST /v1/send
        ↓
Recipient inbox + Volanea delivery events

Why use middleware instead of putting the Volanea key in Zapier

It can be tempting to configure a Webhooks by Zapier action that calls Volanea directly and paste the Volanea secret key into an Authorization header. That may be acceptable for a controlled prototype, but it is not the preferred production pattern.

A small middleware endpoint gives you several benefits that a no-code HTTP action alone cannot reliably provide:

• The Volanea secret key stays in a server-side environment secret. It never needs to be copied into Apollo fields, a front-end app, or a shared contact property.
• You control validation. A missing email address, an invalid template variable, or a bad event payload can be rejected before it becomes a send request.
• You control deduplication. Apollo or Zapier retries must not create duplicate email sends.
• You can enforce policy. For example, only send when the Apollo contact has a particular stage, list membership, custom field, or explicit consent state.
• You have one place for observability. Store the Apollo contact ID, Zap run ID, Volanea response, and any failure reason together.

The Volanea API uses a secret key with Bearer authentication. Keep that key in the secret manager or environment-variable system for the middleware runtime, such as Cloudflare Workers secrets, AWS Lambda environment variables, a container secret store, or your hosting platform’s encrypted configuration.

Do not store the Volanea key in an Apollo custom field. Do not include it in a Zapier request body. Do not expose it in JavaScript delivered to a browser. A leaked sending key can allow an attacker to send mail from your account, damaging domain reputation and creating a potentially costly incident.

For the endpoint, authentication details, and the current send request reference, see the Volanea API documentation.

What actually triggers the email in Apollo

The trigger in this integration is not “a webhook from Apollo,” because Apollo’s documented Zapier connection is the supported event source here. In Zapier, choose:

• App: Apollo.io
• Trigger event: New Contact

Apollo describes this trigger as firing when a new contact is saved. A contact is a person record in your Apollo workspace, not merely an Apollo search result viewed in the prospecting interface.

That distinction matters operationally. If your sales team searches Apollo’s database, opens a profile, and never saves the person as a contact, this Zap should not be expected to run. The event happens when the contact record is saved into the workspace.

Choose the right contact-creation moment

Before activating the Zap, decide what “new contact” should mean in your process. Common choices include:

• A rep manually saves an approved prospect from Apollo search.
• A CSV import creates new Apollo contacts.
• A CRM or another system creates contacts through Apollo’s API.
• A workflow or sales process saves contacts after qualification.

If you only want to send after qualification, do not blindly use every new contact. Either add a Zapier filter after the Apollo trigger or use a separate field and update-driven workflow. For example, your Zap could continue only when the contact has an email value and a custom field such as email_ready is true.

Using a filter is safer than trying to infer readiness from job title, company size, or an email-status label. Your process should state exactly what makes a contact eligible for this message.

The Apollo contact data Zapier can map

Apollo’s Zapier trigger provides contact data for the saved Apollo contact. In Zapier, the exact field-picker labels and optional fields depend on the sample contact returned when you test the trigger, but the core data you should expect to map is the contact record’s identity and contact fields.

For this route, configure Zapier to send the following normalized JSON to your middleware. This is the payload your middleware receives from Zapier after mapping the Apollo New Contact output:

{
  "apolloContactId": "67dabc1234567890abcdef12",
  "email": "maya.chen@example.com",
  "firstName": "Maya",
  "lastName": "Chen",
  "organizationName": "Northstar Labs",
  "title": "VP of Operations",
  "apolloCreatedAt": "2026-09-29T14:08:22.000Z",
  "zapRunId": "zapier-run-id-from-your-zap"
}

This normalized payload is intentional. Apollo does not document a standard, direct outbound HTTP webhook payload for ordinary contact events that you can post straight to Volanea. Zapier is the connector, and its field mapping is the contract you configure. Rather than depend on a fragile raw-object envelope, map the individual Apollo fields you need into an explicit JSON body.

Recommended field mapping in Zapier

In the Zapier action, use Webhooks by Zapier and select a POST request to your middleware URL. Add these fields to the JSON body:

Map only the fields your email needs. Sending an entire Apollo contact object to another system increases the amount of personal data processed and makes the integration harder to maintain when fields change.

Validate email before sending

Apollo contacts may not always have an email address available. Some records may have only a name, company, LinkedIn URL, or other identifying information. Your middleware should return a successful no-op result for records without an eligible address rather than creating an invalid Volanea request.

For high-volume contact workflows, verify addresses before triggering mail. You can use the free email verification tool to check individual addresses during testing, but use a documented qualification rule for production automation.

Configure the Zapier trigger and webhook action

Create a new Zap with Apollo as the trigger and Webhooks by Zapier as the delivery action.

Step 1: Connect Apollo to Zapier

Apollo’s current setup guidance places API key management under Settings > Integrations > API > API keys. Apollo instructs users to create a key, then connect the Apollo app in Zapier using that key.

Treat the Apollo key as sensitive too. It provides access to Apollo data and should be created with only the permissions your connection needs. Name it clearly, such as zapier-apollo-new-contact, so you can identify and revoke it later.

Step 2: Select the New Contact trigger

In Zapier:

1. Create a new Zap.
2. Choose Apollo.io as the trigger app.
3. Choose New Contact as the trigger event.
4. Connect the Apollo account.
5. Test with a contact that contains a real, non-sensitive test email address.

The test result determines which source fields appear in Zapier’s mapping picker. If the test contact lacks a company name or title, Zapier may not offer a useful sample for that field. Create or select a representative test contact before configuring the downstream request.

Step 3: Add filtering before the send

Add a Zapier Filter step before the webhook if the email should only be sent under specific conditions. At minimum, continue only when:

• The contact email exists.
• The email is not an internal test address unless you are in a testing workflow.
• The contact meets your approved outreach or transactional eligibility condition.

Avoid treating all Apollo contacts as opted-in marketing subscribers. Apollo can help you organize prospect data, but it does not replace your responsibility to establish the appropriate legal basis, consent state, suppression policy, and message category for each send.

Step 4: POST the normalized body to middleware

Add Webhooks by Zapier as the next action and configure a POST request to an endpoint you control, such as:

https://email.example.com/hooks/apollo/new-contact

Set Content-Type to application/json and use the normalized mapping described above. Protect this endpoint with a separate shared secret header such as X-Integration-Secret. This secret is not the Volanea key; it is a narrowly scoped credential that lets your endpoint verify that the incoming request is from your automation.

Use a distinct middleware secret for this route so you can rotate or revoke it without affecting Volanea sending credentials.

Working middleware: Apollo contact to Volanea send

The following Cloudflare Worker example receives the mapped Zapier payload, validates it, constructs a Volanea email request, and posts it to https://api.volanea.com/v1/send.

It uses a deterministic Idempotency-Key based on the Apollo contact ID. That is essential because a webhook attempt can time out after Volanea has accepted the email, and Zapier may retry the step. Reusing the same key for the same logical send allows Volanea to avoid creating another message.

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

    // This is the shared secret between Zapier and this endpoint.
    // It is NOT your Volanea API key.
    if (request.headers.get("X-Integration-Secret") !== env.APOLLO_ZAPIER_SECRET) {
      return new Response("Unauthorized", { status: 401 });
    }

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

    const {
      apolloContactId,
      email,
      firstName = "there",
      lastName = "",
      organizationName = "",
      title = "",
      apolloCreatedAt = null,
      zapRunId = null
    } = apollo;

    // A contact with no email is not a failed email send; it is ineligible.
    if (!apolloContactId) {
      return Response.json(
        { error: "apolloContactId is required" },
        { status: 400 }
      );
    }

    if (!email || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
      return Response.json({
        skipped: true,
        reason: "missing_or_invalid_email",
        apolloContactId
      });
    }

    const displayName = `${firstName} ${lastName}`.trim();

    // Volanea REST API payload: verified sender, one recipient,
    // a subject, and HTML content. Keep the API key only in env.VOLANEA_API_KEY.
    const volaneaPayload = {
      from: {
        email: "hello@your-verified-domain.com",
        name: "Your Company"
      },
      to: [
        {
          email,
          name: displayName || undefined
        }
      ],
      subject: `Welcome, ${firstName}`,
      html: `
        <p>Hi ${escapeHtml(firstName)},</p>
        <p>Thanks for connecting with Your Company.</p>
        ${organizationName ? `<p>We have noted your work at ${escapeHtml(organizationName)}.</p>` : ""}
        ${title ? `<p>Your role as ${escapeHtml(title)} helps us tailor the next step.</p>` : ""}
        <p>Reply to this email if you would like to continue the conversation.</p>
      `,
      text: [
        `Hi ${firstName},`,
        "",
        "Thanks for connecting with Your Company.",
        organizationName ? `We have noted your work at ${organizationName}.` : "",
        title ? `Your role as ${title} helps us tailor the next step.` : "",
        "",
        "Reply to this email if you would like to continue the conversation."
      ].filter(Boolean).join("\n"),
      metadata: {
        source: "apollo-zapier",
        apolloContactId,
        apolloCreatedAt,
        zapRunId
      }
    };

    const idempotencyKey = `apollo-new-contact:${apolloContactId}:welcome-v1`;

    const response = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify(volaneaPayload)
    });

    const resultText = await response.text();
    let result;
    try {
      result = JSON.parse(resultText);
    } catch {
      result = { raw: resultText };
    }

    if (!response.ok) {
      console.error("Volanea send failed", {
        status: response.status,
        apolloContactId,
        result
      });

      return Response.json(
        {
          error: "Volanea send failed",
          status: response.status,
          apolloContactId,
          result
        },
        { status: 502 }
      );
    }

    return Response.json({
      sent: true,
      apolloContactId,
      idempotencyKey,
      volanea: result
    });
  }
};

function escapeHtml(value) {
  return String(value)
    .replaceAll("&", "&amp;")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#039;");
}

Set these two secrets in your Worker or server environment:

VOLANEA_API_KEY=sk_...
APOLLO_ZAPIER_SECRET=a-long-random-route-specific-secret

The API key belongs only in VOLANEA_API_KEY. On the Apollo side, there is no Volanea key to store. Apollo authenticates its connection to Zapier with the Apollo API key; Zapier authenticates to your middleware with the route-specific integration secret; your middleware authenticates to Volanea with the Volanea secret key.

Field mapping and message design

The code above demonstrates inline HTML and text. For a production lifecycle message, a Volanea template is often easier to maintain than HTML embedded in a Worker. It lets marketing or operations teams update copy while engineering keeps the event routing, sender policy, and idempotency code stable.

Whether you use inline content or a template, keep these rules in place:

Use a verified sender

The from.email address must belong to a domain you have verified in Volanea. Configure SPF, DKIM, and the related sending-domain DNS records before enabling the Zap for real contacts. A successful API acceptance response means the email was accepted for processing; it is not proof that the recipient received it in the inbox.

Include plain text as well as HTML

A text alternative improves readability in clients that disable HTML and makes the email more resilient. Keep the text content semantically equivalent to the HTML rather than treating it as an afterthought.

Escape dynamic values

Never interpolate untrusted contact data directly into HTML. Names, company names, titles, and custom fields can contain special characters. The sample middleware escapes dynamic HTML values before inserting them.

Keep personalization conservative

A first name and company name can make a message clearer. Overly specific enrichment details can make a recipient uncomfortable, especially if the message implies monitoring or data collection. Match your personalization level to the relationship and the purpose of the email.

Idempotency is not optional

Email sending is a side effect. If an automation system does not know whether its previous HTTP request succeeded, retrying can easily send the same email again.

The risky sequence looks like this:

1. Zapier POSTs the Apollo contact payload to your middleware.
2. Middleware sends the email to Volanea.
3. Volanea accepts the request and queues the email.
4. The network connection closes before middleware returns its response to Zapier.
5. Zapier treats the action as failed or timed out and retries it.
6. Without a stable idempotency key, the recipient receives two messages.

Volanea supports safe retries through the Idempotency-Key header on POST /v1/send. The key must represent one business event, not one HTTP attempt.

For the example, the event is “send welcome version 1 for this Apollo contact,” so the key is:

apollo-new-contact:<apollo-contact-id>:welcome-v1

If you later intentionally send a different email to the same contact, use a different semantic key, such as:

apollo-new-contact:<apollo-contact-id>:meeting-followup-v1

Do not generate a random UUID for each retry. That would make every retry look like a distinct send and defeat the protection.

When this breaks

Every automation has failure modes. The goal is not to assume the Apollo-to-Zapier-to-middleware-to-Volanea path will never fail; it is to make each failure diagnosable and safe.

Apollo or Zapier retries create duplicate attempts

A trigger can be delivered more than once, an action can be retried after a network interruption, or a user can accidentally create duplicate Apollo contacts. These are different causes, but they can all lead to duplicate outbound attempts.

Mitigation:

• Use a deterministic Volanea Idempotency-Key based on the Apollo contact ID and message type.
• Persist a small send ledger in a database or durable store for longer-lived deduplication.
• Decide whether a duplicate Apollo contact should receive a message. If not, deduplicate on email address or a CRM identifier before calling Volanea.
• Log the Apollo contact ID, Zap run ID, idempotency key, and Volanea message result.

Idempotency protects retries of the same logical event. It cannot decide whether two different Apollo contact records for the same person represent one intended send or two. That is a business rule your middleware should enforce.

The webhook action times out

Zapier and serverless environments have execution limits. If your endpoint takes too long, the automation can mark the step as failed even though Volanea later accepted the send.

Mitigation:

• Keep the middleware synchronous path short: validate, construct payload, call Volanea, return.
• Do not perform slow enrichment, CRM lookups, or large database queries in the request path.
• Use the same idempotency key on retries.
• If you need complex processing, accept the Zapier request quickly, write the event to a queue, and return a 202 response. A worker can then send to Volanea asynchronously with the same idempotency key.

Payload fields are missing

Apollo contact records are not guaranteed to have every field. Email may be absent; a company may be unknown; names may be incomplete; and optional data availability can vary based on how the contact was created and which Apollo capabilities your workspace uses.

Mitigation:

• Require apolloContactId and a syntactically valid email at the middleware boundary.
• Treat first name, organization, and title as optional.
• Use safe fallback content such as “Hi there.”
• Test with manual saves, imports, API-created contacts, and workflow-created contacts if your team uses all of them.
• Add a Zapier filter so incomplete contacts never reach the send endpoint unless you explicitly want that behavior.

The wrong contact gets an email

The New Contact trigger is broad. If any team member can save contacts, a generic “welcome” or “outreach” email may be sent to contacts that were not intended for the automation.

Mitigation:

• Gate the Zap on a dedicated Apollo custom field, list, owner, or qualification status.
• Use separate Zaps for separate message categories.
• Send test traffic from a dedicated test workspace or test list before activating production automation.
• Add a kill switch environment variable in middleware, such as EMAIL_SENDING_ENABLED=false, that returns a skipped result without calling Volanea.

A suppression or unsubscribe prevents sending

Volanea applies sending controls, including suppressions and contact unsubscribe state, during the send pipeline. That is a feature, not an error to bypass. If a recipient has bounced, complained, or opted out, do not attempt to work around that state by sending through another address or provider.

Mitigation:

• Inspect the Volanea response and event records.
• Keep marketing and transactional use cases separate in both copy and eligibility logic.
• Make sure the message type matches the recipient relationship and applicable requirements.

Testing before activating the integration

Treat this integration like a production system even if it begins as a simple Zap. A structured test plan catches most dangerous errors before real recipients see them.

Test the happy path

Create a test Apollo contact with a mailbox you control. Confirm that:

1. The Apollo New Contact trigger fires.
2. Zapier maps the expected fields.
3. Middleware returns a successful JSON response.
4. Volanea accepts the send.
5. The email arrives with the correct sender, subject, greeting, and plain-text alternative.

Test incomplete contact data

Create separate test contacts with:

• No email address.
• An empty first name.
• A company name containing &, <, or quotation marks.
• No organization or title.

Verify that the endpoint skips ineligible contacts safely and that escaped values do not break the message HTML.

Test duplicate delivery behavior

Send the same mapped request twice with the same Apollo contact ID and message version. Verify that the Idempotency-Key remains unchanged and that Volanea does not create a second send for the same logical event.

Then change the message version in the idempotency key intentionally and confirm that a new, distinct message can be sent when desired.

Test an invalid Volanea key

Use a non-production environment with an invalid VOLANEA_API_KEY. Your endpoint should return a controlled error, Zapier should show the failed action, and no sensitive credential should appear in your logs or error response.

Operational checklist

Before switching on the Zap for real Apollo contacts, confirm all of the following:

• Apollo is connected to Zapier with a dedicated API key.
• The Zap trigger is New Contact, not a loosely defined proxy event.
• A Filter step requires a usable email address and your explicit eligibility condition.
• Zapier sends only the normalized fields your middleware requires.
• Middleware validates input before calling Volanea.
• The Volanea API key exists only as a server-side environment secret.
• The middleware endpoint uses its own X-Integration-Secret or equivalent authentication.
• Your sender domain is verified in Volanea.
• Each logical message has a stable Idempotency-Key.
• Logs include contact ID, send type, idempotency key, response status, and Volanea result.
• A test contact has completed the entire flow successfully.
• Your team knows how to pause the Zap and disable middleware sending quickly.

Conclusion

To send email from Apollo.io with Volanea, use the supported Apollo-to-Zapier connection rather than pretending there is a native Volanea marketplace app or an Apollo direct-webhook setup. The concrete event is Apollo’s New Contact trigger: when a contact is saved, Zapier maps the relevant contact fields to a protected middleware endpoint.

That endpoint is where the important engineering happens. It validates the Apollo-derived data, keeps the Volanea key out of client-visible configuration, escapes personalized values, and sends through Volanea’s POST /v1/send endpoint with a deterministic idempotency key. The result is an integration that is easier to audit, safer to retry, and much less likely to send duplicate or malformed email.

FAQ

Can Apollo.io call the Volanea API directly?

Not through a native Volanea integration or a documented standard generic outbound HTTP workflow action. Use Apollo’s supported Zapier integration as the event bridge, then call Volanea from a server-side middleware endpoint.

What Apollo.io event starts this integration?

This guide uses Apollo’s Zapier New Contact trigger, which fires when a new contact is saved in Apollo.

Where should I put the Volanea API key?

Store it only in your middleware platform’s encrypted environment secrets, such as VOLANEA_API_KEY. Do not put it in Apollo contact fields, browser code, or any client-visible configuration.

How do I prevent duplicate emails when Zapier retries?

Send a stable Idempotency-Key header to Volanea, based on the Apollo contact ID and the specific message type or version. Reuse that same key for retries of the same logical email.

What should happen if an Apollo contact has no email address?

Skip the send safely and log the reason. Do not construct a Volanea send request without a valid recipient address.