How to Send Email From 8x8 With Volanea

If you need to send email from 8x8, the dependable approach is to use 8x8’s Zapier integration as the event source and send through a small server-side relay to Volanea. That pattern keeps the email API key out of browser-visible settings, gives you a durable audit trail, and lets you control retries before a call event becomes a customer email.

8x8 does not provide a native Volanea app, marketplace installation, or built-in Volanea connector. It also is not a good idea to treat a phone-system event as though it were an email-delivery system. Instead, use the tools for what they do well: 8x8 records the communications event, Zapier receives the event through its 8x8 app, your relay applies business rules and idempotency, and Volanea sends the message through its transactional email API.

This guide uses the 8x8 Zapier trigger named New Call. A newly received or logged call is the concrete event that starts the workflow. The precise fields shown by Zapier can vary with the 8x8 account configuration and the type of call, so build and test the Zap against a real 8x8 call before switching it on for customers.

What the 8x8-to-email architecture looks like

The integration has four hops:

1. A call is recorded in 8x8.
2. Zapier’s New Call trigger reads the new 8x8 call event.
3. Zapier posts the relevant call fields to a private endpoint that you operate.
4. The endpoint validates the event and calls Volanea’s REST email API.

That additional endpoint may look unnecessary when Zapier can make HTTP requests itself. In practice, it is the right boundary for a transactional email workflow. It means the Volanea credential is stored as a server-side secret, not exposed in a front-end application, shared browser configuration, or a URL. It also gives you one place to reject malformed data, suppress duplicate sends, generate safe HTML, and record an email correlation ID.

The basic flow is:

8x8 call occurs
  -> Zapier: New Call
  -> Webhooks by Zapier: POST /integrations/8x8/call
  -> your relay
  -> Volanea POST /v1/emails
  -> recipient inbox

A useful first use case is an internal call-alert email. For example, send the sales team a message when a call arrives from a known high-value customer, when a voicemail-related workflow requires follow-up, or when an unanswered call reaches a selected queue. Avoid sending an email for every phone event without filtering; high-volume call traffic can create noisy inboxes and unnecessary sending cost.

The real 8x8 trigger: New Call in Zapier

The event in this integration is not “a webhook installed in the 8x8 marketplace.” It is the New Call trigger offered by the 8x8 app in Zapier. In Zapier, create a new Zap, choose 8x8 as the trigger application, and select New Call as the trigger event.

Connect the 8x8 account when Zapier asks you to authorize it. Then use Zapier’s test step to load a real recent call. This step matters because telephone systems have legitimate differences in event data: an inbound call, outbound call, transferred call, missed call, and queue call may not all include the same values.

Treat the Zap test record as the field contract

8x8 does not make Zapier output a universal, developer-versioned public webhook schema. Zapier presents fields from the connected account and can change the shape of the test bundle based on the call record. Therefore, do not hard-code a field based only on a field label in a screenshot.

In the Zap editor, inspect the actual test data and map its stable identifiers. A call bundle commonly includes values equivalent to:

{
  "call_id": "8x8-call-7f2d9d",
  "from_number": "+14155550123",
  "to_number": "+14155550999",
  "direction": "inbound",
  "start_time": "2026-09-28T14:30:05Z",
  "duration": 42,
  "status": "completed"
}

This is the normalized payload your Zap should send to the relay, not a claim that every 8x8 account returns these exact property names. In the Webhooks by Zapier step, each value on the right side is selected from the New Call test output. If your account labels the caller field Caller ID, From, or another name, map that actual output to from_number in the outgoing JSON.

That explicit normalization is valuable. Your server should receive one stable schema even if the display names available in a Zap differ later, or if you choose another 8x8 event such as a voicemail-oriented workflow in the future.

Decide which calls deserve email

A call record alone is usually not sufficient justification for an email. Add a Zapier Filter before the webhook action when possible. Examples include:

• Send only where the direction is inbound.
• Exclude completed calls shorter than a chosen threshold, such as five seconds.
• Send only when the destination number belongs to a sales or support queue.
• Exclude blocked, anonymous, or test caller numbers.
• Send an internal alert only during staffed hours, then route after-hours events to an on-call workflow.

Keep business-critical policy in the relay too. A Zapier filter makes the workflow easier to read and can reduce traffic, but server-side validation is the final enforcement point. Anyone who discovers your endpoint should not be able to manufacture arbitrary customer emails by posting a caller number.

Build the Zapier webhook action

After the 8x8 New Call trigger and any filters, add Webhooks by Zapier as the action app. Choose its custom-request or POST action, configure the method as POST, and send JSON to an HTTPS endpoint you control, such as:

https://automation.example.com/integrations/8x8/call

Set the content type to JSON. Add a private shared secret in a header, for example X-Integration-Secret. This is not a replacement for HTTPS, and it is not the Volanea API key. It is a separate credential used only to authenticate Zapier to your relay.

Use a body like this, mapping each value from the New Call test record:

{
  "event_type": "8x8.new_call",
  "call_id": "{{New Call: Call ID}}",
  "from_number": "{{New Call: From Number}}",
  "to_number": "{{New Call: To Number}}",
  "direction": "{{New Call: Direction}}",
  "start_time": "{{New Call: Start Time}}",
  "duration_seconds": "{{New Call: Duration}}",
  "status": "{{New Call: Status}}"
}

The double-braced values above are explanatory placeholders, not literal Zapier field syntax you should paste without mapping. Zapier inserts field tokens through its picker. The field names in the picker are the authoritative names for your connected 8x8 account.

If a field is missing in a sample record, send an empty value rather than inventing one. For example, an unanswered call may have no reliable duration, or an event may not have a meaningful final status at the time Zapier reads it. Your relay should accept optional fields and make its decision based on the fields that are truly present.

Map the 8x8 payload to an email intentionally

The email should answer a useful operational question, not simply reproduce every telecom field. For a missed-call alert, recipients generally need to know who called, which number was reached, when it happened, and where to follow up. They do not need raw integration metadata or a verbose JSON dump.

Here is a practical mapping for an internal alert:

A resulting message might have the subject Inbound call from +1 415 555 0123 and a brief text body with the destination, time, status, and a link to the appropriate internal system. If you are using the event to trigger an external email, be more conservative: obtain appropriate consent, avoid revealing sensitive call details, and make sure the recipient relationship justifies the message.

Phone numbers can be personal data. Keep the email content minimal, ensure internal recipients have a legitimate need to see it, and do not put call recordings, account notes, or unescaped caller-provided values into an email template by default.

Send the Volanea email from a secure relay

The following Node.js example receives the normalized payload from Zapier and makes the Volanea REST call. It uses environment variables for credentials and a simple in-memory example for clarity. In production, replace the in-memory idempotency check with a database row or a durable key-value store.

Before deploying, verify the current endpoint, authentication header, and message-object requirements in the email API reference and setup guides. API credentials and sending-domain requirements can change, and your configured sender must be authorized for the Volanea account.

import express from "express";

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

const processedCallIds = new Set();

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

app.post("/integrations/8x8/call", async (req, res) => {
  if (req.get("X-Integration-Secret") !== process.env.ZAPIER_8X8_SECRET) {
    return res.status(401).json({ error: "unauthorized" });
  }

  const {
    event_type,
    call_id,
    from_number,
    to_number,
    direction,
    start_time,
    duration_seconds,
    status
  } = req.body;

  if (event_type !== "8x8.new_call" || !call_id || !from_number) {
    return res.status(400).json({ error: "invalid call event" });
  }

  // A durable database unique constraint is better than this Set in production.
  if (processedCallIds.has(call_id)) {
    return res.status(200).json({ duplicate: true });
  }

  // Example policy: alert only on inbound calls.
  if (direction !== "inbound") {
    processedCallIds.add(call_id);
    return res.status(200).json({ skipped: "non-inbound call" });
  }

  const caller = escapeHtml(from_number);
  const destination = escapeHtml(to_number || "not supplied");
  const occurredAt = escapeHtml(start_time || "not supplied");
  const callStatus = escapeHtml(status || "unknown");
  const duration = escapeHtml(duration_seconds || "not supplied");

  const emailPayload = {
    from: process.env.VOLANEA_FROM_EMAIL,
    to: [process.env.CALL_ALERT_RECIPIENT],
    subject: `Inbound call from ${from_number}`,
    text: [
      "A new inbound 8x8 call was received.",
      `Caller: ${from_number}`,
      `Destination: ${to_number || "not supplied"}`,
      `Time: ${start_time || "not supplied"}`,
      `Status: ${status || "unknown"}`,
      `Duration: ${duration_seconds || "not supplied"}`,
      `Call ID: ${call_id}`
    ].join("\n"),
    html: `
      <h2>New inbound 8x8 call</h2>
      <ul>
        <li><strong>Caller:</strong> ${caller}</li>
        <li><strong>Destination:</strong> ${destination}</li>
        <li><strong>Time:</strong> ${occurredAt}</li>
        <li><strong>Status:</strong> ${callStatus}</li>
        <li><strong>Duration:</strong> ${duration}</li>
      </ul>
    `,
    headers: {
      "X-8x8-Call-ID": call_id
    }
  };

  const response = await fetch("https://api.volanea.com/v1/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.VOLANEA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": `8x8-call-${call_id}`
    },
    body: JSON.stringify(emailPayload)
  });

  const responseBody = await response.text();
  if (!response.ok) {
    console.error("Volanea send failed", response.status, responseBody);
    return res.status(502).json({ error: "email provider rejected request" });
  }

  processedCallIds.add(call_id);
  return res.status(202).json({ accepted: true });
});

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

The important field mapping is explicit: from_number becomes the subject and caller detail; to_number, start_time, status, and duration_seconds become contextual content; and call_id becomes both an application correlation value and idempotency material. That is substantially safer than passing the entire Zapier bundle directly to an email API.

Where the Volanea API key belongs

The Volanea API key belongs only in the relay’s secret store or protected server environment. For the example above, set VOLANEA_API_KEY in the hosting provider’s encrypted environment-variable configuration, alongside VOLANEA_FROM_EMAIL, CALL_ALERT_RECIPIENT, and the separate ZAPIER_8X8_SECRET.

Do not put the Volanea key in any of these places:

• JavaScript delivered to a browser.
• A mobile application bundle.
• A public Git repository or a .env file committed to source control.
• The 8x8 call data payload.
• An email template, ticket comment, or Zapier field visible to people who do not need administrative access.

A Zapier webhook action can technically carry an authorization header to a third-party API. That may be acceptable for a low-complexity workflow managed by a tightly controlled operations account, but it spreads an email-sending credential into Zap configuration and makes policy enforcement harder. A relay separates the integration credential from the sending credential: Zapier gets permission to call one narrowly scoped endpoint; only that endpoint can send with Volanea.

Rotate credentials deliberately. If the Zapier secret leaks, rotate only ZAPIER_8X8_SECRET. If the Volanea key leaks, revoke and replace the sending key in Volanea and update the server secret. Do not reuse the same secret for both jobs.

Reliability, idempotency, and message design

Calls and emails have different reliability models. A communications event can be retried, delayed, duplicated, or arrive without all final details. An email API can accept a send request even though the eventual inbox outcome is subject to provider processing and recipient-server policy. Design for those realities rather than expecting a single synchronous transaction.

Use call ID as the natural idempotency boundary

The call ID is the best starting point for deduplication because it identifies the underlying communication event. Store it in a table with a unique constraint before sending, along with a state such as received, sending, accepted, or failed.

A production sequence could be:

1. Receive and authenticate the Zapier request.
2. Validate the schema and create the call record with a unique call_id.
3. If the record already exists and has been accepted, return a successful response without sending again.
4. Build the email from validated fields.
5. Send to Volanea with an idempotency key derived from the call ID.
6. Save the provider response ID and mark the record accepted.

This protects against both duplicate upstream delivery and a retry that occurs after the relay sent the email but before Zapier received the HTTP response.

Keep the customer-facing subject stable

Do not include volatile fields such as a duration that may be absent or updated in the subject. A stable subject improves grouping in internal inboxes and makes alert rules easier to build. Put optional details in the body.

Use a recognizable sender identity on a domain you control. Authenticate the sending domain according to Volanea’s setup guidance, and use a monitored reply-to address if recipients are expected to respond. An alert sent from an unmonitored address often turns an automated notification into a dead end.

When this breaks

Every integration needs an operating model for failures. The weak point is usually not the basic send request; it is the boundary between 8x8’s event, Zapier’s task execution, your relay, and the email provider.

Retries can create duplicate emails

Zapier may retry an action after a network failure or non-success response. The relay might also receive the same logical call more than once if the upstream event is replayed. If the first Volanea request succeeded but the relay timed out before returning a response, a retry can otherwise produce a second alert.

Return a fast success response for an already processed call_id, and make the Volanea idempotency key deterministic. Store the outcome durably. Do not rely only on an in-memory set, which disappears during a restart or does not work across multiple server instances.

Webhook timeouts can hide a successful send

Webhook steps expect a prompt HTTP response. If your relay waits on slow database work, template rendering, or an email-provider call that takes too long, Zapier can regard the action as failed even when the downstream request eventually succeeds.

Keep the request path short. Validate and claim the idempotency key quickly, enqueue the send for a worker where possible, and return 202 Accepted once the event is safely recorded. The worker can then call Volanea, retry transient provider failures according to your policy, and log the final response.

Some call fields may be absent

A test event from one 8x8 call type is not proof that every subsequent event contains every field. Duration, status, destination, or timing fields can be missing depending on the event timing, routing pattern, account setup, or data exposed by the connected plan and integration.

Make only call_id and the data necessary for your business rule required. Use fallback text for optional fields. If a caller number is essential to the workflow but absent, log the event for investigation and skip the email rather than sending a misleading notification.

Incorrect number formatting causes poor matching

Phone numbers may appear with punctuation, country codes, extensions, or local dialing formats. If you match callers to contacts or decide alert routing by destination, normalize numbers before comparison. Store the original display value separately so the email can show what an operator expects to recognize.

Do not silently guess a country code from a local number unless your business has a reliable country context. A wrong normalization can route an alert to the wrong team or attach the wrong customer record.

Provider errors need a clear retry policy

A 4xx response usually means a request, authorization, sender, or recipient problem that should be fixed rather than retried endlessly. A temporary 5xx response or network failure may justify a bounded retry with backoff. Record the provider response and the Volanea message identifier when available so support staff can distinguish an event that was never sent from one that was accepted for delivery.

Test before enabling production alerts

Start with a dedicated internal recipient and a dedicated test caller number. Make a real test call, wait for the 8x8 New Call trigger to appear in Zapier, inspect the webhook request in relay logs, and confirm the resulting email content. Testing only with manually typed JSON misses the field and timing variations that matter most.

Use this checklist:

• Confirm the Zap trigger is New Call and the connected 8x8 account is the intended production account.
• Inspect an inbound call, an unanswered call, and a short test call where possible.
• Verify each Zap field token maps into the normalized JSON key you expect.
• Confirm requests without the integration secret receive 401.
• Trigger the same call_id twice and verify only one email is accepted.
• Confirm the sender domain and reply-to behavior are appropriate.
• Check the plain-text and HTML versions of the message.
• Review logs for the call ID, Zap execution reference, and Volanea response.

Once the basic alert works, add monitoring. Alert when relay authentication failures rise, when email requests are rejected, or when a sudden increase in call events creates an unexpected email burst. Operational alerts should help a team act, not generate a second layer of noise.

Alternatives to a custom relay

A small relay is the recommended path when call alerts matter, credentials need strong separation, or you need duplicate protection. It is not the only possible implementation.

You can use a serverless function on a platform your team already operates. The logic stays the same: Zapier posts normalized call data, the function validates it, and the function uses a server-only Volanea secret. This is often simpler than maintaining a long-running Express process.

For a proof of concept, Zapier can post directly to an email API action or a generic HTTP action. That reduces code but makes it harder to centralize data validation, store durable idempotency state, and control the credential lifecycle. Treat direct automation-to-provider delivery as a prototype, not automatically as the final production architecture.

Make can also act as middleware when a team standardizes on Make scenarios. The same constraints apply: inspect the actual 8x8 event fields, use a private downstream endpoint for the email key, and build idempotency around the 8x8 call identifier. Switching automation tools does not remove the duplicate-send or missing-field problem.

Operational and deliverability implications

Sending a call alert is transactional communication when it is tied to an operational event and directed to the people who need to act. It should not be repurposed into unsolicited outreach simply because a caller’s phone number exists in a communications record.

Keep recipient lists narrow, send from an authenticated domain, and use concise content. If your volume grows, separate alert classes: urgent missed-call alerts may go to an on-call address, while completed-call summaries may be batched into a report rather than delivered one message at a time.

Also consider the second-order effect of duplicate alerts. A duplicate marketing email is annoying; a duplicate urgent support alert can lead to two agents calling the same customer or two staff members opening duplicate tickets. Idempotency is therefore an operational coordination feature, not merely a technical nicety.

Conclusion

To send email from 8x8 with Volanea, use the 8x8 New Call event in Zapier as the trigger, normalize the call fields in a Webhooks by Zapier POST action, and send the email from a protected server-side relay. The relay is where you authenticate the integration, preserve the Volanea API key, handle optional call fields, prevent duplicates, and create an email that is genuinely useful to its recipient.

Build the first version around one real call type and one internal alert. Once you have verified the field mapping and retry behavior with live 8x8 events, extend it with routing rules, durable storage, and monitoring rather than adding complexity prematurely.

FAQ

Does Volanea have a native 8x8 integration?

No. Volanea does not provide a native 8x8 marketplace app or plugin. Use 8x8 through Zapier and connect it to Volanea through a secure server-side HTTP relay.

What 8x8 event starts this email workflow?

This guide uses Zapier’s 8x8 New Call trigger. The Zap runs when a new call event is available to the connected 8x8 integration, then maps that call data into a normalized JSON request.

Can I put the Volanea API key directly in Zapier?

It is technically possible to configure API authorization in an automation HTTP step, but a relay is safer for production. It keeps the sending key in server-side secret storage and gives you a place for validation, logging, and idempotency.

How do I stop duplicate call-alert emails?

Store the 8x8 call ID in a durable database with a unique constraint, return success for duplicate events, and use the same call ID to derive an idempotency key for the Volanea send request.

What happens if an 8x8 field is missing?

Treat nonessential fields as optional, provide clear fallbacks in the email, and skip the send when a field required by your routing rule is absent. Always test with real call types because Zapier output can differ by call and account configuration.