How to Send Email from Clearbit with Volanea

Clearbit can identify and enrich the people and companies that match your ideal customer profile; Volanea can deliver the email that follows. This guide shows how to send email from Clearbit without pretending there is a native Clearbit marketplace app: Clearbit posts an Audience Webhook Destination to your server, and that server securely calls Volanea’s REST API.

This is an event-driven integration for a legitimate, consent-aware workflow. For example, a known contact enters a customer-onboarding audience, a trial user crosses a product-usage threshold, or a person who submitted a form becomes qualified after enrichment. It is not a recipe for turning company-level visitor identification into unsolicited cold email.

The integration pattern: Clearbit webhook, your relay, Volanea API

Clearbit’s documented outbound HTTP mechanism is an Audience Webhook Destination. When a person or company matches an audience, Clearbit can POST JSON to the URL you configure. The destination can trigger when an entity enters or exits an audience, or on a page view; its JSON includes destination and segment context plus the person or company attributes you select for the payload. (help.clearbit.com)

There is no native Volanea app to install in Clearbit, no Clearbit marketplace connection flow, and no reason to put a Volanea secret key in Clearbit configuration. The architecture should be:

1. A known person meets the rules for a Clearbit People Audience.
2. The Audience Webhook Destination fires with the segment_enter trigger.
3. Clearbit sends JSON to a webhook endpoint that you own.
4. Your endpoint validates the request and required fields, builds a stable idempotency key, and calls POST https://api.volanea.com/v1/send.
5. Volanea accepts the message for delivery, applies suppression and sending controls, and records the send.

That small relay is important. It creates a trustworthy boundary between a third-party event source and an email-sending credential. It is also where you can enforce consent, restrict audience IDs, redact logs, normalize fields, prevent duplicate sends, and choose an approved template.

Volanea’s single-message endpoint is POST /v1/send; it uses the https://api.volanea.com base URL and supports the Idempotency-Key request header for retry-safe sends. (volanea.com)

The concrete Clearbit trigger to use

For this integration, create a People Audience in Clearbit and add an Audience Webhook Destination. Select When a person enters the audience as the destination trigger. Clearbit documents this event in the outbound payload as context.trigger: "segment_enter". (help.clearbit.com)

A person entering an audience is a better transactional trigger than a generic page view for most email workflows. It gives you a defined business event: the person now satisfies the audience rules. It also makes it possible to reason about who should receive the message, why they received it, and whether the trigger is compatible with your consent model.

Good audience definitions

The right audience is based on a customer relationship or an explicit user action, not merely a company match. Examples include:

• People who submitted a demo or contact form and are marked as opted in for follow-up.
• Trial users who have an account, have accepted product communications, and meet a product-qualified threshold.
• Existing customers whose organization has entered a customer-success segment and whose contacts have a valid service-notification basis.
• Event registrants who supplied an email address and consented to receive event details or requested materials.

A company audience is useful for routing sales alerts, CRM tasks, or account-level automation. It is usually not sufficient by itself for sending a person an email because a company record is not an email recipient. If your purpose is to send a message, use a People Audience and deliberately include the person’s email attribute in the webhook payload.

What not to use as a send trigger

Avoid treating Clearbit enrichment or anonymous web activity as automatic permission to email someone. A page-view trigger can be useful for notifying an internal account owner, adding a contact to a review queue, or updating lead scoring. It should not silently turn an identified business visitor into an outbound recipient.

The email action should also match the trigger’s meaning. A person entering a “trial activated” audience can reasonably receive a setup email. A person entering a “high-fit company visitor” audience may justify an internal notification, not an automated external email.

Configure the Clearbit Audience Webhook Destination

In Clearbit, open the People Audience that should initiate the email. Go to its Destinations tab, create a Webhook Destination, and configure the destination’s trigger as When a person enters the audience. Clearbit’s setup documentation describes entering the destination URL, saving the destination, activating it, and choosing the attributes included in the outgoing payload. (help.clearbit.com)

Set the webhook URL to your relay, not to Volanea directly. A production URL might look like this:

https://hooks.example.com/clearbit/audience?token=replace-with-a-long-random-secret

Use HTTPS. Generate a long random URL token, store it as a secret in your deployment environment, and treat it as a routing credential rather than as a substitute for formal signed-webhook verification. Clearbit’s documented destination setup asks for a URL; do not assume a custom authorization header or an HMAC signature is available unless your own Clearbit account documentation explicitly shows it.

Choose the smallest useful payload

Clearbit lets you customize which attributes its destination sends. Its own documentation notes that the payload format remains the same while available attributes depend on what you choose to include. (help.clearbit.com)

For a basic welcome or follow-up email, select only the values your relay needs:

• Person email address.
• Person full name, if available.
• Person employment title, if useful in a template.
• Company name and domain, if useful in a template.
• Destination and segment context, which Clearbit includes for event identification.

Do not send an entire enrichment profile just because it is available. More data expands the privacy and logging footprint without necessarily making the email better. A relay that only needs email, first name, company name, segment ID, destination ID, timestamp, and trigger is simpler to secure and easier to debug.

Delivery suppression in Clearbit is helpful, not enough

Clearbit’s webhook configuration includes a delivery-suppression option that can exclude entities already alerted within a chosen period. That is useful for reducing repeated audience alerts, but it should not be your only duplicate control. (help.clearbit.com)

Clearbit suppression is a destination-level operational setting. It does not replace a durable email event policy, a stable idempotency key, recipient consent checks, or Volanea’s own suppression handling. Keep duplicate prevention close to the side effect: the actual send request.

The Clearbit payload and field mapping

Clearbit posts JSON containing a context object and an entity object. The documented example includes destination_id, segment_id, segment_name, segment_type, timestamp, and trigger in context; the entity payload contains the company or person attributes chosen for the destination. (help.clearbit.com)

For a People Audience, configure the payload to include the person email and the optional attributes used below. The resulting event has this practical shape:

{
  "context": {
    "destination_id": "dst_123",
    "segment_id": "seg_trial_activated",
    "segment_name": "Trial users ready for onboarding",
    "segment_type": "person",
    "timestamp": "2026-10-01T15:42:19.679+00:00",
    "trigger": "segment_enter"
  },
  "person": {
    "email": "maya@example.com",
    "name": {
      "fullName": "Maya Chen"
    },
    "employment": {
      "title": "Product Operations Manager"
    }
  },
  "company": {
    "name": "Northstar Labs",
    "domain": "northstarlabs.example"
  }
}

The context fields are the useful event envelope. The entity fields are selected in the destination payload, so test the actual body received by your endpoint before relying on a nested field name. If your configuration sends a flattened field rather than person.name.fullName, change the mapping in the relay rather than trying to fix it in an email template.

Mapping Clearbit fields to an email

Here is the intended transformation:

Keep your subject and body under application control. Do not allow an incoming webhook to supply arbitrary HTML, arbitrary recipients, or arbitrary sender addresses. Clearbit determines whether an entity qualifies; your relay determines whether that event is allowed to create a particular email.

Working Node.js relay: Clearbit to Volanea

The following example is a complete Express route. It accepts a Clearbit Audience Webhook Destination, requires the URL token, rejects events other than segment_enter, validates the email address, maps selected fields, and sends through Volanea.

The Volanea request uses a Bearer secret key, JSON content type, and a stable Idempotency-Key. Volanea documents POST /v1/send, its API base URL, and safe retries through that header. (volanea.com)

import express from "express";

const app = express();
app.use(express.json({ limit: "256kb" }));

const {
  CLEARBIT_WEBHOOK_TOKEN,
  VOLANEA_API_KEY,
  EMAIL_FROM
} = process.env;

function firstName(fullName = "there") {
  const value = String(fullName).trim();
  return value ? value.split(/\s+/)[0] : "there";
}

function isEmail(value) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(String(value || ""));
}

app.post("/clearbit/audience", async (req, res) => {
  // Clearbit stores this token only as part of the configured webhook URL.
  if (req.query.token !== CLEARBIT_WEBHOOK_TOKEN) {
    return res.status(401).json({ error: "Unauthorized webhook" });
  }

  const event = req.body;
  const context = event?.context || {};
  const person = event?.person || {};
  const company = event?.company || {};

  // This endpoint is intentionally narrow: one approved audience event.
  if (context.trigger !== "segment_enter" || context.segment_type !== "person") {
    return res.status(202).json({ ignored: true });
  }

  const recipient = person.email;
  if (!isEmail(recipient)) {
    // Return 2xx for a structurally valid but non-sendable event so it is not
    // retried forever. Log only a redacted diagnostic in production.
    return res.status(202).json({ ignored: true, reason: "missing_email" });
  }

  if (!VOLANEA_API_KEY || !EMAIL_FROM) {
    console.error("Missing server-side Volanea configuration");
    return res.status(500).json({ error: "Server configuration error" });
  }

  const idempotencyKey = [
    "clearbit-audience",
    context.destination_id,
    context.segment_id,
    context.timestamp,
    recipient.toLowerCase()
  ].join(":");

  const payload = {
    from: EMAIL_FROM,
    to: recipient,
    subject: "Welcome to your next step",
    html: `<p>Hi ${firstName(person?.name?.fullName)},</p>
<p>Thanks for your interest in ${company?.name || "our team"}. Here is the next step to get started.</p>`,
    text: `Hi ${firstName(person?.name?.fullName)},\n\nThanks for your interest in ${company?.name || "our team"}. Here is the next step to get started.`,
    variables: {
      firstName: firstName(person?.name?.fullName),
      companyName: company?.name || "",
      jobTitle: person?.employment?.title || "",
      segmentName: context.segment_name || ""
    }
  };

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

  const responseText = await response.text();

  if (!response.ok) {
    console.error("Volanea send failed", {
      status: response.status,
      destinationId: context.destination_id,
      segmentId: context.segment_id
    });
    return res.status(502).json({ error: "Email provider request failed" });
  }

  return res.status(202).json({ accepted: true, provider: responseText });
});

app.listen(process.env.PORT || 3000);

Set deployment secrets outside source control:

CLEARBIT_WEBHOOK_TOKEN='long-random-value-used-only-in-the-webhook-url'
VOLANEA_API_KEY='sk_live_replace_with_your_secret_key'
EMAIL_FROM='Customer Team <hello@your-verified-domain.example>'

Before deploying, confirm the exact from and to representation accepted by your Volanea project in the email API reference and setup guides. The sender domain must be verified before production sends; an unverified sender should be treated as a configuration failure, not as a reason to fall back to a personal mailbox.

Where the Volanea API key belongs

The Volanea API key does not live on the Clearbit side. Clearbit stores the webhook destination URL. Your relay stores VOLANEA_API_KEY in a server-side secret manager, encrypted platform environment variable, or equivalent protected runtime configuration.

That distinction matters because Volanea secret keys authorize sending. If a key reaches browser JavaScript, a public client configuration object, a static site repository, a Zap export, a support screenshot, or an unprotected webhook configuration, an attacker may be able to send mail from your account. A sending key belongs only in code that runs on infrastructure you control.

Safe secret handling checklist

• Keep VOLANEA_API_KEY in the relay’s secret store or encrypted environment configuration.
• Never put it in Clearbit’s destination URL, an email template, frontend code, or client-side environment variable.
• Restrict access to the deployment configuration to the operators who need it.
• Rotate the key after a suspected disclosure and update the relay before revoking the old one.
• Keep the Clearbit webhook token separate from the Volanea key. One authenticates event delivery to your relay; the other authorizes mail sending.
• Avoid logging request headers, raw webhook bodies, or full recipient emails in general application logs.

Volanea’s documentation identifies the secret key as a server-side credential and distinguishes it from public event-ingestion use cases. (volanea.com)

Use a template once the flow is proven

The inline HTML in the sample is intentionally small so you can see the mapping. In production, a stored Volanea template is often cleaner for messages with branded markup, localization, previews, approvals, and multiple owners.

The relay should still choose the template. It can send a fixed templateId and pass only reviewed variables such as firstName, companyName, a product URL, and an account owner’s name. This stops a Clearbit payload change from unexpectedly changing message content.

A strong pattern is one endpoint per email purpose or an allowlist keyed by context.segment_id. For example:

const templatesBySegment = {
  "seg_trial_activated": "tpl_trial_onboarding",
  "seg_event_registered": "tpl_event_confirmation"
};

const templateId = templatesBySegment[context.segment_id];
if (!templateId) return res.status(202).json({ ignored: true });

That allowlist has a second-order benefit: it prevents someone from creating a new Clearbit audience and accidentally connecting it to a production sender without a code review. The audience can still generate a webhook event, but it cannot create an email until engineering or marketing operations explicitly approves the segment-to-template mapping.

When this breaks: Clearbit-to-relay failure modes

A webhook integration is two separate hops: Clearbit to your relay, then your relay to Volanea. Treat them separately in logs, monitoring, and incident response.

Clearbit retries can create duplicate sends

If Clearbit sends the event, your relay sends the email, and the connection closes before Clearbit receives a response, Clearbit may retry. The relay can see the same event more than once even though the email send already succeeded.

This is why the example derives Idempotency-Key from stable event fields: destination ID, segment ID, event timestamp, and normalized recipient email. Reusing the same key for the same Clearbit event allows Volanea to replay the earlier result instead of dispatching a second copy. Volanea documents that repeated idempotency keys replay the stored response for 24 hours. (volanea.com)

Do not generate a random UUID for every webhook delivery. A random value makes a retry look like a new business event, which defeats idempotency. If Clearbit’s payload in your account includes a unique event identifier, prefer that identifier as part of the idempotency key.

Webhook timeouts can make a successful event look failed

Your relay should not do slow database work, remote enrichment calls, or lengthy template rendering before it acknowledges Clearbit. The more work you do in the synchronous request, the more likely a timeout becomes.

For low volume, the direct route shown above is usually sufficient because the Volanea send request is the immediate work item. For higher volume or stricter reliability requirements, accept the webhook, write an event record or enqueue a job keyed by the idempotency value, return a 2xx response, then have a worker call Volanea. The worker should preserve the same idempotency key.

Be careful with a simple “always return 200” approach. It avoids upstream retries but can silently lose messages if you acknowledge the request before persisting it. The safe order is: authenticate and validate, durably record the event or enqueue it, return success, then send asynchronously.

Payload fields can be absent on some plans or configurations

Clearbit says that the attributes available in a webhook payload differ according to what you choose to include. A webhook built around person.email, job title, or company data can therefore fail when a field is not selected, is unavailable, or is empty for a given record. (help.clearbit.com)

Handle missing fields deliberately:

• Missing email: do not send. Return a non-error acknowledgement after recording a redacted reason, so a permanently incomplete record is not retried endlessly.
• Missing name: use a neutral greeting such as “Hi there,” rather than rendering Hi undefined.
• Missing company: omit company-specific language rather than guessing from a domain.
• Missing segment or destination context: reject or quarantine the event because you cannot safely identify the policy that allowed it.
• Unavailable Webhook Destinations: use the middleware route through Zapier or another automation platform rather than inventing a direct Clearbit capability.

Clearbit’s help center describes Webhook Destinations for Standard Bundle, Enrichment, and Clearbit Platform customers, and separately documents a Zapier route using Webhooks by Zapier with a Catch Hook trigger. (help.clearbit.com)

A 2xx from Volanea is not a final inbox-placement guarantee

An accepted API request means Volanea accepted the message for its sending pipeline. It does not mean every recipient has read it, that every mailbox provider will place it in the inbox, or that a suppressed address will receive it.

Build operational visibility around the provider response and Volanea email events. For important workflows, log the event key, audience identifiers, template identifier, recipient hash, Volanea response status, and provider message identifier if returned. Do not log message bodies or raw enrichment profiles unless you have a documented reason and suitable retention controls.

Test the integration before activating the audience

A reliable launch uses controlled records and small blast radius. Start with a test People Audience containing an internal address or a designated QA record. Add a temporary webhook destination to a staging endpoint, inspect the payload, then activate the production destination only after the mapping matches your assumptions.

Recommended test sequence

1. Verify the Volanea sender domain and send one direct test from the relay with a known email address.
2. Create a test Clearbit People Audience with one internal person who has an email address.
3. Configure the webhook payload with the exact person and company fields needed by the relay.
4. Point the destination at staging and capture the received JSON securely.
5. Confirm context.trigger is segment_enter, context.segment_type is person, and the mapped email is present.
6. Replay the same payload twice and verify that the same idempotency key does not produce duplicate delivery.
7. Remove the email field from a test payload and confirm the endpoint acknowledges but does not send.
8. Point the destination at production, activate it, and monitor the first few events.

Use Clearbit’s destination-level delivery suppression as a guardrail during testing, but do not rely on it to prove that your idempotency implementation works. Test the retry case explicitly by making the identical request more than once.

Zapier middleware when you do not run a webhook service

If you cannot deploy a relay, Clearbit documents a no-code path: configure a Webhook Destination, create a Zap with Webhooks by Zapier using Catch Hook, paste the generated Zapier URL into Clearbit, then use subsequent Zap steps to route the data to another service. (help.clearbit.com)

However, do not place a Volanea secret key in a broadly shared, client-visible configuration or a loosely governed automation. If you use Zapier, store the Volanea key only in Zapier’s protected connection or credential mechanism, limit editor access, and make the final request with a Webhooks action to https://api.volanea.com/v1/send.

The middleware mapping remains the same:

• Clearbit trigger: person enters the People Audience.
• Zapier trigger: Catch Hook receives the Clearbit JSON.
• Filter: only continue for context.trigger = segment_enter and an approved segment ID.
• Validation: require person.email and your consent or lifecycle condition.
• Webhook action: POST to Volanea with the Bearer key, JSON body, and stable Idempotency-Key.

For production-critical email, a small custom relay is generally easier to version, test, audit, and make idempotent than a visual automation alone. The strongest design is not the one with the fewest boxes; it is the one that preserves consent, secure credentials, event traceability, and duplicate protection.

Deliverability and lifecycle implications

Clearbit can make an email more relevant, but relevance does not override recipient expectations. Use Clearbit attributes to improve a message that the recipient already expects: route someone to the right onboarding path, select the relevant event resources, personalize a customer-success reminder, or alert an internal owner.

Avoid adding enrichment details that feel surveillance-heavy. Stating an inferred title, funding event, browsing behavior, or detailed technology stack in the first email can reduce trust even if the data is accurate. The better approach is modest personalization: name, company context, the action they took, and the next useful step.

Also separate transactional and promotional intent. A product-access message, consent confirmation, or event receipt should not quietly become a marketing campaign. If the content is marketing, apply the relevant opt-in, unsubscribe, frequency, and regional compliance controls before the event reaches Volanea.

If an address is questionable before it reaches the send endpoint, check it with the email address verification tool. Verification is not permission, but it can prevent obvious syntax errors and reduce avoidable bounces in workflows where the address was supplied by a user.

Conclusion

The correct way to send email from Clearbit with Volanea is a secure webhook relay, not a fictional native plugin. Configure a Clearbit People Audience, trigger an Audience Webhook Destination when a person enters that audience, send the selected JSON fields to infrastructure you control, and make a server-side Volanea API call with a stable idempotency key.

That approach keeps Clearbit responsible for audience qualification, keeps Volanea responsible for email delivery, and keeps your application responsible for policy: consent, validation, template choice, secret storage, and duplicate prevention. It is a small amount of integration code, but it gives you the operational controls that a direct shortcut cannot.

FAQ

Does Clearbit have a native Volanea integration?

No. Clearbit does not provide a native Volanea app, marketplace listing, or one-click connector for this workflow. Use a Clearbit Audience Webhook Destination to call your own relay, then have that relay call Volanea’s REST API.

What Clearbit event starts the email send?

Use a People Audience Webhook Destination configured for When a person enters the audience. The outbound context identifies this as segment_enter.

Can I send directly from Clearbit to the Volanea API?

Do not do so. A direct call would require exposing a Volanea sending secret in Clearbit configuration or assuming unsupported custom authentication options. Send Clearbit to a relay you own; keep the Volanea key in server-side secrets.

How do I stop duplicate Clearbit emails?

Create an Idempotency-Key from stable event data such as Clearbit destination ID, segment ID, timestamp, and normalized recipient email. Send that same key to Volanea for every retry of the same event.

What happens when Clearbit does not include an email address?

Do not send. Configure the People Audience webhook payload to include the person email field, and make the relay acknowledge but quarantine or log events where that value is absent or invalid.