How to Send Email from Emailable with Volanea

Emailable can help you decide whether an address should receive a message, but it is not an outbound email platform. To send email from Emailable with Volanea, use a server-side workflow that verifies an address through Emailable, evaluates the verification result, and then calls Volanea’s email API only when the result meets your sending policy.

That distinction matters. There is no native Volanea app, marketplace installation, or general-purpose outbound webhook in Emailable that can directly dispatch an email from an Emailable event. The dependable integration is a middleware pattern: your application, automation service, or worker receives the business event, requests verification from Emailable, and sends through Volanea after applying explicit rules.

What this integration does — and does not do

Emailable is an email-verification service. Its API evaluates an address and returns attributes such as a verification state, tag, reason, whether the domain has MX records, and whether SMTP checks succeeded. Volanea is the delivery layer: it accepts a composed message through SMTP or REST and handles the email send.

Putting those jobs together creates a useful pre-send gate. For example, when a person requests a password reset, joins a waitlist, submits a lead form, or is invited to a workspace, your backend can verify the address before it attempts delivery. If the address is deliverable, it can send the transactional message through Volanea. If it is risky, undeliverable, disposable, or unknown, the workflow can stop, request a corrected address, or place the contact into a review path.

It does not mean Emailable becomes a campaign automation system. Emailable does not provide a contact record lifecycle such as “contact created,” “form submitted,” or “deal stage changed” that can act as the source trigger for a send. It also should not be used as the place where message templates, subscriber consent, unsubscribe state, or sending credentials live.

The actual trigger must come from the system where the customer action occurs:

• Your application creates a user after signup.
• Your form endpoint receives a lead submission.
• Your billing system records a successful invoice or a failed payment.
• Your CRM changes an opportunity, contact, or ticket status.
• Your background queue receives a request for a transactional notification.

That business event calls Emailable’s single-email verification endpoint. The verification response is the decision payload that the middleware uses before calling Volanea.

The real Emailable trigger: a verification request, not a webhook event

It is important to name the trigger accurately. In a direct API implementation, the immediate Emailable-side action is a single email verification request. Your server requests verification for an email address, and Emailable returns a result. That returned response is not an unsolicited webhook emitted by Emailable; it is the response to a request your system made.

This has practical consequences for architecture. You should not design a workflow that waits for an Emailable “new verification” event to arrive at Volanea. Instead, create a single orchestration point that owns the complete sequence:

1. Receive the application event, such as user.created or password_reset.requested.
2. Check local suppression, consent, and idempotency rules.
3. Request email verification from Emailable.
4. Inspect the returned verification payload.
5. Send with Volanea only if the policy permits it.
6. Store the outcome and the Volanea message identifier for troubleshooting.

For synchronous account flows, this can happen in the request handler if latency is acceptable. For less urgent messages, queue the job and let a worker perform verification and delivery. A queue is generally the safer choice for welcome messages, invitations, receipts that are not time critical, and other sends where retries need careful control.

Why a direct browser integration is the wrong pattern

Do not call Emailable and Volanea directly from browser JavaScript, a public mobile configuration file, or a client-side no-code form. Both services require credentials with material consequences. An exposed Emailable key can consume verification credits; an exposed Volanea key can be used to send mail from your account.

A browser also cannot safely enforce the decision policy. A malicious user could bypass a client-side deliverable check, alter recipient fields, or reuse a token to submit arbitrary email content. Verification, authorization, composition, and sending should therefore happen in a trusted server environment.

The Emailable verification payload to use

Emailable’s single-email verification API returns a JSON object describing its evaluation of an address. The key fields to treat as a decision contract are commonly the email address, state, tag, reason, disposable, role, free, mx, smtp, and score.

A representative response has this shape:

{
  "email": "alex@example.com",
  "state": "deliverable",
  "tag": "valid",
  "reason": null,
  "disposable": false,
  "role": false,
  "free": false,
  "mx": true,
  "smtp": true,
  "score": 0.98
}

Treat this response as evidence, not a permanent guarantee. Mailbox availability can change after the check. Some providers intentionally limit SMTP-level signals, and catch-all domains can make mailbox-specific certainty impossible. A verification service reduces avoidable bad sends; it does not replace bounce processing, consent management, or list hygiene.

Fields that should drive a sending decision

A conservative transactional policy can start with state === "deliverable" and then apply your own rules. The exact policy depends on the email’s purpose and the cost of a missed message.

For example:

• Password resets and account-security codes: Send to deliverable addresses. Do not silently change an address based on a suggestion. If an address is not deliverable, show a recovery path.
• Welcome emails: Send only when the result is deliverable, unless the account was already verified through a separate ownership confirmation process.
• Sales follow-ups and promotional messages: Require deliverable status, recorded consent, and suppression checks. Exclude role and disposable addresses if that fits your policy.
• Receipts and legally required notices: Do not discard the event merely because verification is uncertain. Record the result, attempt the required delivery where appropriate, and use bounce feedback to correct the account record.

The tag and reason fields help explain a non-send decision. Store them with the workflow result so support and operations teams can distinguish “we did not send because the mailbox was undeliverable” from “we tried to send and the recipient server bounced the message.” Those are materially different events.

Keep business fields separate from the Emailable response

Emailable verifies an address; it does not know your recipient’s first name, account ID, event name, template choice, locale, or consent source. Those fields must travel alongside the verification request in your own job payload.

For example, a queued job can include:

{
  "event": "workspace.invite.created",
  "idempotencyKey": "invite_8f2b3d",
  "recipient": {
    "email": "alex@example.com",
    "name": "Alex Rivera",
    "userId": "usr_123"
  },
  "template": "workspace-invite",
  "templateData": {
    "workspaceName": "Northstar",
    "inviteUrl": "https://app.example.com/invites/abc"
  }
}

Do not expect those application fields to appear in Emailable’s result. The middleware must retain them and map them into the Volanea message after verification succeeds.

A working server-side verification and send flow

The example below uses Node.js with the built-in fetch available in modern Node releases. It makes a server-side request to Emailable, applies a clearly stated policy, and then sends a message through Volanea’s REST API.

Keep the two keys in server-only environment variables. The Emailable key is used only for verification. The Volanea key is used only for delivery. Separating them makes rotation, auditing, and least-privilege controls easier.

// send-invite.js
// Run only on a trusted server or worker. Never bundle these values into frontend code.

const EMAILABLE_API_KEY = process.env.EMAILABLE_API_KEY;
const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;

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

async function verifyWithEmailable(email) {
  const url = new URL("https://api.emailable.com/v1/verify");
  url.searchParams.set("email", email);
  url.searchParams.set("api_key", EMAILABLE_API_KEY);

  const response = await fetch(url, {
    method: "GET",
    headers: { "Accept": "application/json" },
    signal: AbortSignal.timeout(10_000)
  });

  if (!response.ok) {
    throw new Error(`Emailable verification failed: ${response.status}`);
  }

  return response.json();
}

function canSendTransactionalEmail(result) {
  // Start conservative. Adjust only after documenting why a message type
  // should use a different rule.
  return result.state === "deliverable" &&
    result.tag === "valid" &&
    result.disposable === false;
}

async function sendWithVolanea({ toEmail, toName, subject, html }) {
  const response = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Accept": "application/json"
    },
    body: JSON.stringify({
      from: "Northstar <notifications@updates.example.com>",
      to: [{ email: toEmail, name: toName }],
      subject,
      html
    }),
    signal: AbortSignal.timeout(10_000)
  });

  if (!response.ok) {
    const detail = await response.text();
    throw new Error(`Volanea send failed: ${response.status} ${detail}`);
  }

  return response.json();
}

export async function sendWorkspaceInvite(job) {
  const verification = await verifyWithEmailable(job.recipient.email);

  // Field mapping:
  // verification.email       -> validates the intended recipient address
  // verification.state/tag   -> send/no-send decision
  // job.recipient.name       -> Volanea to[0].name
  // job.recipient.email      -> Volanea to[0].email
  // job.templateData         -> rendered subject and HTML
  if (!canSendTransactionalEmail(verification)) {
    return {
      status: "not_sent",
      email: job.recipient.email,
      verification: {
        state: verification.state,
        tag: verification.tag,
        reason: verification.reason,
        score: verification.score
      }
    };
  }

  const safeWorkspaceName = escapeHtml(job.templateData.workspaceName);
  const safeInviteUrl = escapeHtml(job.templateData.inviteUrl);

  const delivery = await sendWithVolanea({
    toEmail: job.recipient.email,
    toName: job.recipient.name,
    subject: `You are invited to ${job.templateData.workspaceName}`,
    html: `<p>Hello ${escapeHtml(job.recipient.name)},</p>
      <p>You have been invited to <strong>${safeWorkspaceName}</strong>.</p>
      <p><a href="${safeInviteUrl}">Accept your invitation</a></p>`
  });

  return {
    status: "sent",
    email: job.recipient.email,
    verification: {
      state: verification.state,
      tag: verification.tag,
      score: verification.score
    },
    delivery
  };
}

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

The Volanea call maps the application-owned recipient and rendered content into the send request. It deliberately does not map Emailable’s score, reason, or tag into an email header or message body. Those values are operational metadata, not recipient-facing content.

Before deploying, compare the request object with the current email API reference and setup guides. In particular, use a verified sender domain, configure the domain’s authentication records, and confirm the exact response fields your account receives after a successful send.

Choosing a decision policy instead of blindly trusting a score

A numeric score is useful for analysis, but a production workflow needs deterministic decisions. Define a policy per message class and make it testable. If the policy is encoded only in an automation filter with no documentation, it will be hard to explain why a customer did not receive an important email.

A simple policy table might look like this:

Role addresses such as support@, admin@, or sales@ deserve a deliberate rule rather than an automatic rejection. They may be unsuitable for an individual sales sequence but entirely valid for an account notification. Likewise, free email providers are not inherently bad; a customer using a personal address for a legitimate account should not be penalized simply because the address is free.

Verification should also happen at the right time. Checking an address months before a campaign is less useful than checking it near the moment it will receive a message. For recurring messages, do not spend verification credits on every send without thinking about the trade-off. Use recent successful delivery, bounce history, subscriber activity, and the risk profile of the message to decide when re-verification adds value.

Authentication and secret handling

The Volanea API key belongs in the middleware’s secret store, not in Emailable, not in a browser, and not in a public automation URL. Because Emailable is not the outbound HTTP sender in this design, there is no Emailable webhook configuration field where a Volanea authorization header should be placed.

For a custom integration, store VOLANEA_API_KEY in your hosting provider’s encrypted environment-variable or secret-management system. Your server injects it into the Authorization: Bearer header only when it makes the REST request. Store EMAILABLE_API_KEY in the same kind of server-side secret store, while keeping the two values separate.

Follow these practices:

• Never include either key in frontend environment variables such as NEXT_PUBLIC_*, static site configuration, screenshots, or client logs.
• Do not append the Volanea key to a URL. URLs can be retained in browser history, proxy logs, analytics tools, and referrer headers.
• Limit access to the deployment environment that needs to send email, and rotate keys after an accidental disclosure or personnel change.
• Redact authorization headers and API keys from application logs, error-reporting payloads, and queue failure records.
• Use a sender domain that your organization controls and authenticate it before production sending.

The Emailable API key appears as an api_key parameter in the verification request documented by Emailable. Since query strings can be logged by intermediary systems, make server logs avoid recording full outbound URLs. The key should never be placed into client-visible code merely because a verification request is easy to make from a browser.

Using Zapier or Make when you do not own the backend

If you do not have a server, use an automation platform as the middleware — but start the automation from the system that owns the real event, not from Emailable. For example, a form submission can trigger a Zap or Make scenario, which then requests verification and sends an HTTP request to Volanea after a filter passes.

This route is useful for prototypes and internal operations, but it has limits. Complex templates, high send volume, idempotency, observability, and secret isolation are usually easier to manage in code. Treat the automation platform as production middleware only if its plan, error handling, execution limits, and credential controls meet your requirements.

A conceptual Make scenario is:

1. Trigger: a form, CRM, commerce, or database module reports a new record.
2. HTTP request: call Emailable’s verification endpoint with that record’s email address.
3. Filter: continue only when state is deliverable, tag is valid, and any additional business rules pass.
4. Render: build the subject and HTML from fields in the original trigger record.
5. HTTP request: POST the Volanea message body with the Volanea API key in an Authorization header stored in the platform’s connection or secret field.
6. Data store/log: persist a stable event ID and the outcome.

Do not use a generic “webhook catch hook” as though Emailable will post verification events to it. The automation must actively call the verification API after its upstream trigger fires. If your workflow needs more than a basic request-response check, such as retry queues, concurrency limits, message-event handling, or template versioning, move the orchestration into a serverless function or worker.

When this breaks: failure modes in the Emailable-to-Volanea hop

A verification-and-send workflow crosses two APIs and often a third system that initiated the job. Failures should be designed for rather than treated as rare exceptions.

Retries can create duplicate sends

The most dangerous failure happens after Volanea accepts a send but before your middleware records success. Your worker may time out, crash, or lose the response, then retry the job. The retry can verify the same address again and submit the same message a second time.

Prevent this with an application-owned idempotency record. Use a durable key such as event type + source event ID + recipient ID, mark it as processing before the send, and store the final delivery response after success. A queue retry should first check whether that key already has a completed send.

Do not use the email address alone as the idempotency key. A customer can legitimately receive different receipts, invitations, or account alerts at the same address. The key must identify one specific business event.

Timeouts do not tell you whether a send happened

Set separate short timeouts for verification and delivery, and classify errors. A timeout while calling Emailable means you lack a verification decision; do not quietly treat it as deliverable. A timeout while calling Volanea is ambiguous: the email may have been accepted even though your client did not receive the response.

For ambiguous delivery requests, check your idempotency store and any provider-side message evidence available to your account before retrying. For noncritical email, a delayed retry is usually safer than an immediate retry storm. For time-sensitive messages, present an in-app fallback or a clear user-facing status instead of pretending delivery is guaranteed.

Verification fields may be absent or unsuitable for your rule

Do not destructure every possible Emailable attribute and assume it will always be present. API behavior, account features, request type, exports, and automation connectors can expose different fields or represent empty values differently. Your code should validate the fields it requires and treat an absent state, tag, or boolean signal as an explicit “cannot decide” condition.

This is especially important in no-code tools, where a field may not appear in a mapping panel until a sample run has produced it. Build an explicit fallback branch for missing data. Do not map a missing boolean to false and accidentally interpret “unknown disposable status” as “confirmed non-disposable.”

Keep the policy narrow: require the fields you truly need. If the workflow only requires state === "deliverable", do not make sends fail because an optional analytic field is absent. Conversely, if a compliance rule requires a consent field from your CRM, fail closed when that source field is missing.

Payload mapping errors can send the wrong content

The verification response’s email should match the application email you intended to check. Compare them after normalizing whitespace and casing rules appropriate to your application. If they do not match, stop the send and investigate rather than using whichever value happens to be returned.

Message composition has its own risks. Escape untrusted text before inserting it into HTML, validate URLs used in templates, and never allow a form field to select an arbitrary sender address or raw HTML body. The sender, template ID, and recipient authorization should be controlled by server-side business logic.

A successful API response is not inbox placement

A successful Volanea API response means the platform accepted the send request. It does not prove the recipient read the message or that a mailbox provider placed it in the inbox. Deliverability also depends on sender-domain authentication, content, recipient engagement, complaint rates, prior sending history, and receiving-server policy.

Monitor Volanea delivery events, bounces, and complaints. Feed permanent bounces and unsubscribe requests into your own suppression list before the next workflow run. Verification prevents some bad attempts; post-send events tell you what happened after an accepted message left the sending platform.

Operational safeguards for a production workflow

The integration becomes more valuable when its results are observable. Store enough metadata to answer “why was this message sent, skipped, retried, or bounced?” without storing message secrets unnecessarily.

For each job, record:

• The source event ID and idempotency key.
• A privacy-appropriate recipient identifier and the normalized email address where permitted.
• Emailable’s state, tag, reason, and score at decision time.
• The policy version used to make the decision.
• The Volanea response or provider message identifier after a successful request.
• Retry count, error category, and timestamps for verification and sending.

Metrics should distinguish verification failures from email delivery failures. If Emailable requests are failing, you may have a credentials, quota, network, or timeout problem. If verification succeeds but Volanea sends fail, investigate sending credentials, sender-domain setup, message validation, account limits, or the Volanea API response. If sends are accepted but bounce rates rise, look at list quality, application address collection, and mailbox-provider feedback.

Rate limits deserve attention too. A sudden import of 100,000 records should not produce 100,000 simultaneous verification requests followed by a burst of unthrottled email. Use bounded worker concurrency, exponential backoff for transient failures, and separate queues for high-priority transactional mail and lower-priority marketing workflows.

Alternatives to verifying before every send

Pre-send verification is not always the best first control. For a password reset, the user’s prior account-confirmation state may be more meaningful than a fresh verifier result. For a double-opt-in program, the confirmation click is direct proof that someone controlled the inbox at that point in time.

Consider these complementary approaches:

• Confirm ownership with a double-opt-in email before adding a person to recurring promotional mail.
• Validate syntax and normalize obvious whitespace errors at form submission, then use verification for higher-risk flows.
• Maintain a suppression list from hard bounces, complaints, and unsubscribes.
• Reverify dormant or imported records before a large campaign rather than every recently active recipient.
• Use Volanea’s event data to measure the actual delivery consequences of each verification policy.

The best system combines pre-send prevention with post-send feedback. A strict verifier-only policy can reject legitimate people; a send-everything policy can damage reputation. Your rules should be calibrated against the purpose of the message and the evidence your application has about the address.

Conclusion

The reliable way to send email from Emailable with Volanea is not a direct Emailable plugin or outbound webhook. It is an orchestrated server-side flow: an application event starts the job, middleware requests an Emailable verification, a documented policy evaluates the response, and Volanea sends the message when the result is eligible.

Keep the Volanea API key in server-only secrets, preserve application context outside the verification payload, and add idempotency before enabling retries. With those controls in place, Emailable can reduce avoidable sends while Volanea remains the purpose-built infrastructure responsible for delivery.

FAQ

Can Emailable directly send an email through Volanea?

No. Emailable is an email-verification service, not an outbound email sender, and this integration does not rely on a native Volanea app or a direct Emailable outbound webhook. Use a server, worker, Zapier, or Make as middleware.

What is the trigger for this workflow?

The real business trigger comes from your app, form, CRM, or billing system. Emailable’s part of the flow is a single-email verification request, whose response provides the verification decision before the Volanea API call.

Should I send only when Emailable says deliverable?

That is a sensible conservative starting point for many transactional messages, but the right rule depends on message type. Required receipts, security notices, and account-recovery flows may need a different documented fallback policy.

Where should I store the Volanea API key?

Store it in a server-side secret manager or encrypted environment variable used by your middleware. Never expose it in browser code, public form configuration, client-side automation, or URLs.

Can retries send duplicate emails?

Yes. A timeout after Volanea accepts a request can leave the middleware uncertain whether delivery was initiated. Use a durable application-level idempotency key for each business event before retrying.