NeverBounce is built to verify email addresses, not to originate marketing or transactional messages. To send email from NeverBounce with Volanea, make the verification result a decision point in your application or automation: verify the address with NeverBounce, then send through Volanea only when your policy allows it.

The important limitation: NeverBounce does not trigger outbound sends

There is no native Volanea app, marketplace listing, or installable NeverBounce-to-Volanea connector. More importantly, NeverBounce is not a CRM, form builder, or workflow database with events such as “record created,” “stage changed,” or “form submitted.”

NeverBounce’s public API is designed around email verification. Its documented “webhook” feature is also easy to misread: it is a prebuilt NeverBounce verification URL that another system can call with an email address. It is not an outbound event webhook that NeverBounce posts to after a verification completes.

That means there is no NeverBounce-originated trigger payload to receive and no NeverBounce setting where you should paste a Volanea endpoint. A correct implementation starts with an event in the system that collected or owns the email address, such as:

A visitor submits your signup, waitlist, checkout, or contact form.
Your backend creates a user or organization.
A CRM workflow sends a lead to a server-side automation endpoint.
A list-cleaning job has completed and your application retrieves its verified rows through the NeverBounce jobs API.

For real-time messaging, the concrete trigger is usually your application’s form submission or account-creation event. Your server calls NeverBounce’s single/check endpoint, receives a verification result, applies your send policy, and then calls Volanea’s POST /v1/send endpoint.

This distinction matters operationally. NeverBounce tells you whether an address is suitable for a send decision; Volanea accepts and delivers the actual email. Treating verification and sending as two separate steps makes the flow safer, easier to test, and much less likely to send duplicate mail.

The recommended architecture

The safest architecture is a small server-side relay in your existing application, API route, serverless function, or worker. The relay is responsible for keeping credentials secret, validating input, checking the verification result, and creating a stable idempotency key for the email send.

The flow looks like this:

Your trusted source system creates an event, such as signup_submitted.
A backend route receives the person’s email and any message context.
The route calls NeverBounce to verify the recipient address.
NeverBounce returns the verification response synchronously.
Your policy evaluates the result value.
If permitted, the route calls Volanea’s email API.
The route stores the source event ID, verification result, and Volanea response for audit and retry handling.

This is a request/response integration, not an app-to-app webhook subscription. The architecture has one extra hop compared with sending immediately, but it gives you a controlled place to enforce deliverability policy and prevent a browser, a third-party automation editor, or a public form from seeing a sending credential.

Why the sender should own the workflow

A verification result is a useful signal, not a complete permission model. An address can be technically deliverable yet unsubscribed, suppressed after a previous hard bounce, inappropriate for a particular message, or outside the scope of consent you collected.

Your application is the right place to combine those checks. It already knows what event occurred, which message is appropriate, whether the person opted in, and whether a message with the same business purpose was already sent. Volanea then adds the sending, delivery, suppression, and email-infrastructure layer.

For a production integration, use a verified Volanea sending domain before enabling live traffic. The Volanea API setup guides cover the API endpoint and domain configuration needed for authenticated transactional sending.

What NeverBounce actually returns

NeverBounce does not post an outbound payload to your application after a single verification. Your backend sends it an address, and the single/check endpoint returns a JSON response.

A successful single-email response has this shape:

{
  "status": "success",
  "result": "valid",
  "flags": ["has_dns", "has_dns_mx"],
  "suggested_correction": "",
  "retry_token": "",
  "execution_time": 499
}

The critical field is result. NeverBounce documents result values including valid, invalid, disposable, catchall, and unknown. Your send policy should be explicit rather than assuming that every non-error response means “safe to send.”

A practical starting policy for transactional messages is:

valid: send normally.
invalid: do not send; prompt for a corrected address or mark the record for review.
disposable: usually do not send account activation, trial, or high-value messages unless your product deliberately supports disposable addresses.
catchall: choose deliberately. A catch-all domain accepts mail for many or all local parts, so mailbox existence is not confirmed.
unknown: do not automatically treat it as invalid. It can be caused by a remote server timeout or temporary connectivity issue; choose between a cautious send, delayed retry, or manual review based on the message type.

NeverBounce’s own point-of-entry guidance notes that valid, catchall, and unknown may be allowed for some signup flows, while invalid and disposable should be blocked. That is a useful baseline, but not a universal rule. A password reset is a different risk profile from a free-trial welcome email, and a high-volume campaign should generally be more conservative than an account confirmation.

Preserve the result alongside the recipient

Do not reduce verification to a one-time boolean such as isVerified: true. Store the exact result, flags, verification time, and the address that was checked. That helps you answer important questions later:

Was the address actually checked before the message was sent?
Did the recipient submit a corrected spelling after the first result?
Was the result unknown because a lookup timed out?
Did you choose to send to a catch-all address under a documented policy?
Is a prior result stale enough that the address should be checked again?

For list-cleaning jobs, NeverBounce’s results endpoint returns each submitted row under data and its corresponding verification under verification. If you submitted rows through the API, the data object retains the keys you originally provided. This makes it possible to retain your internal contact ID or import-row ID and map cleaned recipients back to your own records without matching solely on email address.

Working server-side example: NeverBounce check to Volanea send

The following Node.js example shows the complete real-time pattern. The incoming JSON is from your own trusted event source—for example, a signup route, CRM automation relay, or server-side form handler. It is not a payload sent by NeverBounce, because NeverBounce does not emit an outbound verification-complete webhook.

The example uses:

NEVERBOUNCE_API_KEY for the NeverBounce verification request.
VOLANEA_API_KEY for Volanea’s authenticated send request.
eventId as the stable identifier for the original business event.
A deterministic Idempotency-Key so a retry does not create a second email.

import express from "express";
import crypto from "node:crypto";

const app = express();
app.use(express.json());

const {
  NEVERBOUNCE_API_KEY,
  VOLANEA_API_KEY,
  VOLANEA_FROM = "Support <support@example.com>"
} = process.env;

if (!NEVERBOUNCE_API_KEY || !VOLANEA_API_KEY) {
  throw new Error("Missing NEVERBOUNCE_API_KEY or VOLANEA_API_KEY");
}

function text(value) {
  return String(value ?? "").trim();
}

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

app.post("/events/signup", async (req, res) => {
  // This is YOUR source event, not a NeverBounce webhook payload.
  const eventId = text(req.body.eventId);
  const email = text(req.body.email).toLowerCase();
  const firstName = text(req.body.firstName) || "there";

  if (!eventId || !email) {
    return res.status(400).json({ error: "eventId and email are required" });
  }

  // 1. Verify the recipient with NeverBounce.
  const verifyUrl = new URL(
    "https://api.neverbounce.com/v4.2/single/check"
  );
  verifyUrl.searchParams.set("key", NEVERBOUNCE_API_KEY);
  verifyUrl.searchParams.set("email", email);

  const verifyResponse = await fetch(verifyUrl, {
    headers: { Accept: "application/json" },
    signal: AbortSignal.timeout(10_000)
  });

  if (!verifyResponse.ok) {
    return res.status(502).json({
      error: "NeverBounce verification request failed",
      status: verifyResponse.status
    });
  }

  const verification = await verifyResponse.json();

  // Field mapping from NeverBounce's response:
  // verification.result -> send decision
  // verification.flags -> internal audit data
  // verification.suggested_correction -> optional UI remediation
  // verification.retry_token -> optional later recheck workflow
  if (verification.status !== "success") {
    return res.status(422).json({
      error: "NeverBounce did not return a successful verification",
      verification
    });
  }

  if (verification.result !== "valid") {
    return res.status(202).json({
      sent: false,
      reason: "recipient_not_eligible_under_current_policy",
      neverBounceResult: verification.result,
      suggestedCorrection: verification.suggested_correction || null
    });
  }

  // 2. Send through Volanea. Reuse this exact value if this source event retries.
  const idempotencyKey = crypto
    .createHash("sha256")
    .update(`signup-welcome:${eventId}:${email}`)
    .digest("hex");

  const volaneaPayload = {
    from: VOLANEA_FROM,
    to: [{ email, name: firstName }],
    subject: "Welcome to Example",
    text: `Hi ${firstName},\n\nThanks for signing up.`,
    html: `<p>Hi ${htmlEscape(firstName)},</p><p>Thanks for signing up.</p>`
  };

  const sendResponse = 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(volaneaPayload),
    signal: AbortSignal.timeout(10_000)
  });

  const responseBody = await sendResponse.json().catch(() => null);

  if (!sendResponse.ok) {
    return res.status(502).json({
      error: "Volanea send request failed",
      status: sendResponse.status,
      response: responseBody,
      neverBounceResult: verification.result
    });
  }

  return res.status(201).json({
    sent: true,
    neverBounce: {
      result: verification.result,
      flags: verification.flags ?? []
    },
    volanea: responseBody
  });
});

app.listen(3000, () => {
  console.log("Listening on http://localhost:3000");
});

The mapping in this example is intentionally narrow. The recipient address comes from the event that started the workflow, while NeverBounce contributes the verification decision. firstName comes from the same trusted source event and is used only for personalization. The verification response is not treated as customer profile data because NeverBounce’s single-check response is a deliverability assessment, not a contact record.

Why `eventId` matters

The eventId must identify the logical event, not the HTTP attempt. Good values include a database event UUID, a signup submission ID, an order ID plus message type, or an immutable CRM activity ID.

Do not build the idempotency key from the current timestamp. A timestamp changes on every retry, which turns a retry into a new email request. Do not use the email address alone either, because one person may legitimately receive different messages over time.

In the example, the key is derived from the stable combination of message purpose, event ID, and recipient address. If the worker runs twice because the caller did not receive a response, it repeats the same logical Volanea send rather than creating a second welcome email.

Authentication: keep both keys on the server

NeverBounce API keys and Volanea API keys are secrets. They must live in a server-side secret store, environment variable system, or automation platform’s encrypted connection/secret facility—not in browser JavaScript, public form settings, mobile-app binaries, client-visible configuration files, or front-end build variables.

NeverBounce explicitly warns that its standard API is not suitable for browser-side use because doing so exposes sensitive credentials. Its webhook URL format also embeds a sensitive NeverBounce key in the URL, which is another reason it should never be copied into public client-side code.

The same rule applies to Volanea. The Volanea API request uses an Authorization: Bearer header. Anyone who can inspect a client-side request, a public repository, or a broadly shared workflow export can potentially recover and misuse a key.

Where the Volanea key belongs

For the direct integration shown above, store the Volanea key as VOLANEA_API_KEY in the deployment environment for the server, function, or worker that executes the relay. Limit access so only the runtime identity and the operators responsible for email infrastructure can read it.

For an automation platform, use that platform’s encrypted connection or secret field if it has one. If it does not offer protected credentials for outgoing HTTP headers, route the automation to your own relay endpoint instead. Your relay can authenticate the automation with a dedicated inbound secret, while keeping the Volanea key entirely inside your infrastructure.

Use separate keys for development, staging, and production. Give each key an identifiable name, rotate it when access changes, and revoke it if it appears in a repository, screenshot, exported workflow, issue tracker, browser console, or support ticket.

Do not confuse the two credentials

The NeverBounce credential authorizes a verification request. The Volanea credential authorizes email sending. They are independent and should not be exchanged, placed in the same public configuration object, or passed through your frontend.

Keeping them separate also makes incident response clearer. If a NeverBounce key is exposed, rotate the NeverBounce key and audit verification use. If a Volanea key is exposed, rotate the Volanea key, inspect send activity, and review suppression and delivery behavior. A single “integration token” stored everywhere removes that isolation.

Choosing a verification policy before sending

A direct integration should not hide a business decision inside a loose condition such as if (result !== "invalid"). Define the statuses your message type can accept, document the decision, and instrument the outcomes.

For example, a conservative transactional policy might be:

NeverBounce result	Suggested welcome-email action	Reason
`valid`	Send	The address was verified as real.
`invalid`	Do not send	A likely hard bounce is not worth the risk.
`disposable`	Do not send or require review	Temporary mailboxes are often unsuitable for durable accounts.
`catchall`	Queue for a separate policy	Domain acceptance does not prove the named mailbox exists.
`unknown`	Retry verification later or permit selectively	The result may be inconclusive because of temporary remote behavior.

For account-critical messages, a cautious policy is usually preferable. For a signup confirmation, you may allow unknown rather than blocking a legitimate person because a recipient server was slow. For a campaign or a large batch of outreach, you may exclude unknown and catchall until you have a more deliberate risk policy.

NeverBounce also returns suggested_correction for some likely typos. Use that value to improve your form experience—for example, asking “Did you mean jane@example.com?”—but do not silently replace the address and send mail without the person confirming it. An address correction is a user-interface suggestion, not proof of consent for a different inbox.

Using NeverBounce bulk jobs without pretending they are webhooks

The real-time single/check path is best when an event needs an immediate decision. Bulk cleaning is different. You may submit a list or job, wait for processing, retrieve job status, and then request results.

The relevant NeverBounce model is a job and its results, not a sequence of outgoing webhook events. A results record includes the original row data and a verification object. If your source file contained columns such as contact_id, email, and first_name, retain those columns when you create the job so you can map a verified result back to the appropriate message workflow.

A sensible bulk pattern is:

Export recipients with a stable internal contact_id and their email address.
Submit or upload the list to NeverBounce.
Wait until the job status indicates processing has completed.
Retrieve results in pages.
Filter rows under your documented policy.
Enqueue one Volanea send task per eligible recipient.
Use an idempotency key such as reengagement:campaign-2026-10:contact-12345.
Store the NeverBounce result and Volanea response with the task.

Do not use the fact that a job is finished as permission to blast every returned row. Apply your normal consent, unsubscribe, suppression, segmentation, frequency-cap, and campaign rules first. Email verification reduces invalid-recipient risk; it does not replace recipient permission or sender-reputation controls.

For a quick second opinion on a single address during debugging, Volanea also provides a free email verification tool. Keep the production eligibility decision centralized in your application so the operational policy does not drift across teams.

When this breaks

Every integration needs a failure design. In this flow, the failure boundaries are clear: the event source can retry, NeverBounce can respond slowly or inconclusively, and Volanea can receive a request even if your code never receives the response.

Retries can cause duplicate sends

Your application, a serverless platform, a queue worker, or an automation service may retry when it sees a timeout or a 5xx response. The danger is that Volanea may have accepted the send before the connection failed. If the retry uses a new request identity, the recipient can receive two copies.

Use Volanea’s Idempotency-Key header on every transactional request. Generate it from a stable source-event ID and message purpose, then reuse the same value for all attempts to send that same logical message. Record the key in your database or durable job store before you make the request.

NeverBounce itself is not the sender in this architecture, so it is not “retrying a send.” But a surrounding workflow that calls NeverBounce and then Volanea can absolutely repeat the whole sequence. Design every hop as at-least-once delivery and make the Volanea send idempotent.

Verification timeouts should not become accidental sends

NeverBounce notes that a single verification request can take longer than the timeout parameter alone because network latency is separate. Some remote mailbox hosts are slow or temporarily inaccessible. A timeout is not the same thing as an invalid result.

Set a bounded timeout in your HTTP client, such as the 10-second timeout used in the example. If the verification request times out, record an unknown or verification_unavailable state and follow a documented policy: retry later, hold the email, or allow only low-risk messages. Do not silently skip the verification call and send as though it returned valid.

Also avoid putting the full verification-and-send path on a browser request that must respond instantly. For a signup, you can accept the registration, enqueue the welcome message, and let a worker finish verification and delivery. That improves resilience while preserving the audit trail.

Missing payload fields are usually an upstream-data problem

NeverBounce’s single-check response does not provide your lead’s name, order number, template variables, consent record, or source-event ID. Those fields need to come from your own system. If they are absent, the relay should reject or safely default them before calling Volanea.

For bulk jobs, the fields returned under data depend on the data you submitted. API-submitted rows preserve submitted keys; dashboard-uploaded CSV rows depend on the file’s header row. If a paid plan, import method, or downstream automation does not carry a field you expected, do not invent a fallback recipient or personalization value. Validate the schema at the boundary and route incomplete records to a review queue.

Keep recipient email mandatory. Treat first name and other personalization fields as optional. A neutral greeting such as “Hello,” is better than sending malformed content or accidentally inserting the string undefined into a customer email.

A 2xx send response is not final inbox placement

A successful Volanea API response means the send request was accepted by the API; it is not a guarantee that the recipient read the message or that every mailbox provider will place it in the inbox. Delivery can later be affected by a recipient server, bounce, complaint, suppression, or authentication issue.

Capture Volanea’s returned message identifier and correlate it with your source event. Use delivery event handling and suppression behavior as part of the broader production design. A NeverBounce valid result reduces the chance of sending to a bad address, but it does not eliminate later mailbox failures or replace domain authentication.

Client-visible secrets are an incident, not a configuration shortcut

If you ever see a NeverBounce key in a browser network request, a public webhook URL, a mobile app bundle, or a front-end environment variable, rotate it. If you see a Volanea bearer key in any of those places, revoke and replace it immediately, then audit send activity.

A common mistake is trying to use NeverBounce’s webhook URL directly in a public form and then trying to call Volanea from the same script. That leaks the verification credential and the sending credential while allowing an attacker to submit arbitrary addresses. Always insert a trusted server-side boundary.

Zapier, Make, and middleware options

NeverBounce can be used with automation platforms, but do not assume that its presence in an app directory means it provides an outgoing “verification completed” trigger. In an automation design, the trigger should still be the system where the record, lead, form submission, or purchase originated.

A typical middleware flow is:

A form, CRM, ecommerce system, or database triggers the automation.
The automation calls NeverBounce’s single verification endpoint as an action or webhook request.
A filter allows only the results your policy accepts.
The automation sends a request to a secure relay you control.
The relay calls Volanea with the protected bearer key and an idempotency key.

For low-volume, no-code use cases, the automation platform can perform the decision and HTTP request. For important transactional mail, a relay is still preferable because it gives you durable idempotency storage, structured logs, schema validation, retry policy, and control over credential exposure.

Avoid placing the Volanea bearer key into a client-side custom code step, a shared template, or a plain-text notes field. If the automation platform can store encrypted secrets and restrict project access, it may hold the key server-side. If it cannot, the platform should authenticate only to your relay, and the relay should own the Volanea credential.

Testing the flow before production

Test the entire decision chain with controlled inputs before attaching it to a live signup form or campaign pipeline. Test both success and non-send outcomes; a workflow that correctly refuses to send is working as designed.

Use this checklist:

Confirm the source event includes a stable event ID and recipient email.
Confirm your NeverBounce request is made only from the backend.
Test valid and verify the Volanea request has the expected recipient, subject, HTML, plain text, and idempotency key.
Test invalid and confirm no Volanea API request is made.
Test disposable, catchall, and unknown against your chosen policy.
Test a duplicate delivery of the same source event and confirm the same idempotency key is reused.
Simulate a timeout after the Volanea call and confirm retry behavior does not create a second message.
Remove an optional personalization field and verify that the output remains readable.
Verify that the From address belongs to a verified sending domain.
Confirm logs redact both API keys and minimize stored recipient data.

Do not test by repeatedly sending live welcome emails to customer addresses. Use an internal mailbox or a dedicated test recipient, and give test events recognizable IDs so they can be filtered from analytics and support workflows.

Conclusion

The reliable way to send email from NeverBounce with Volanea is not a native app installation or a NeverBounce outbound webhook. NeverBounce does not originate that send event. Instead, let your own form, application, CRM, or queue trigger a trusted server-side workflow.

That workflow verifies the email address with NeverBounce, evaluates the returned result under a documented policy, and sends the message through Volanea using a protected bearer key and a stable idempotency key. The result is a cleaner separation of responsibilities: NeverBounce helps decide whether an address is suitable, while Volanea handles the transactional email send.

Build the integration around that boundary and you gain more than verification. You gain a durable audit trail, safer retries, fewer duplicate emails, controlled access to credentials, and a practical way to evolve your verification policy without rewriting your email infrastructure.

FAQ

Can NeverBounce send an email directly to Volanea?

No. NeverBounce’s documented API verifies addresses and supports a callable verification webhook URL, but it does not provide an outbound event webhook that posts a verification-complete payload to Volanea. Use your application or middleware as the trigger and relay.

What is the NeverBounce trigger for this integration?

There is no NeverBounce-native “record created” or “verification completed” outbound trigger. The practical trigger is an upstream event you own, such as a form submission, user creation, order event, or queued bulk-job result retrieval.

Should I send to `catchall` or `unknown` addresses?

It depends on the message type and risk tolerance. catchall means the domain accepts mail broadly but does not confirm the mailbox. unknown can be temporary or inconclusive. Define a separate policy for those results rather than treating them as equivalent to valid.

Where should I store the Volanea API key?

Store it only in a server-side environment variable, secrets manager, or encrypted automation-platform connection. Send it as Authorization: Bearer <key> from your backend. Never place it in browser code, a public form, or a client-visible configuration file.

How do I stop retrying workflows from sending duplicate emails?

Create one stable Volanea Idempotency-Key for each logical message, based on an immutable source event ID and message purpose. Reuse the same key on every retry of that event.

How to Send Email From NeverBounce With Volanea