voiceflow email integration tutorial: how to send email from your chatbot

Voiceflow is one of the better tools for building conversational agents. But the moment your chatbot needs to send an email (a transcript, a confirmation, a follow-up), you hit a wall. Voiceflow doesn't have a native email block. You need to wire up an external service, figure out API payloads, and handle failures yourself.

I've tested most of the common approaches: direct API calls to SendGrid, Gmail via Zapier, Resend through function blocks, and a few others. Each has real tradeoffs depending on whether you're sending one-off transactional messages or running a multi-tenant deployment. This tutorial walks through the options so you can pick the right one for your setup.

How to send email from Voiceflow (step-by-step)#

1. Choose an email API (SendGrid, Resend, Mailgun, or an agent-native provider like LobsterMail)
2. Sign up for the service and obtain your API key
3. In Voiceflow, add an Integration block or a custom Function block to your flow
4. Configure an HTTP POST request with the recipient address, subject line, and email body
5. Map your Voiceflow variables (like {user_email} and {user_name}) into the API payload
6. Add error handling to catch failed sends and notify the user
7. Test the full flow in the Voiceflow canvas before publishing

That's the high-level path. But the details matter, especially around which email service you pick and how you handle the integration. Let's break it down.

Option 1: direct API calls with the Integration block#

Voiceflow's Integration block lets you make HTTP requests to external APIs without writing JavaScript. This is the simplest approach if you already have an email API account.

Here's what a SendGrid integration looks like in practice. You create a POST request to https://api.sendgrid.com/v3/mail/send with your API key in the Authorization header:

{
  "personalizations": [
    {
      "to": [{ "email": "{user_email}" }],
      "subject": "Your conversation summary"
    }
  ],
  "from": { "email": "bot@yourdomain.com" },
  "content": [
    {
      "type": "text/plain",
      "value": "{transcript_text}"
    }
  ]
}

Replace {user_email} and {transcript_text} with your Voiceflow variables. SendGrid requires a verified sender domain or email address, and you'll need an API key with "Mail Send" permissions at minimum.

The Integration block works, but it has limits. You can't easily format HTML emails, handle complex error responses, or do conditional logic based on the API response. For that, you need a Function block.

Option 2: Function blocks with JavaScript#

Voiceflow's Function block (formerly the Code block) gives you a JavaScript environment where you can make fetch calls, format data, and handle responses programmatically. This is where things get more flexible.

A basic email send using Resend looks like this inside a Function block:

const response = await fetch('https://api.resend.com/emails', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer re_your_api_key',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    from: 'bot@yourdomain.com',
    to: user_email,
    subject: 'Your conversation summary',
    html: `<h2>Hi ${user_name},</h2><p>${transcript_text}</p>`
  })
});

if (!response.ok) {
  send_status = 'failed';
} else {
  send_status = 'sent';
}

The user_email, user_name, transcript_text, and send_status variables need to be declared in Voiceflow first. Map them in the Function block's variable panel, then use send_status downstream to branch your flow (show a success message or a retry prompt).

This approach handles HTML formatting, error states, and conditional logic. The downside: you're embedding API keys in your Voiceflow project, which means anyone with editor access can see them.

Option 3: Zapier or Make as middleware#

If you'd rather avoid writing API calls entirely, Zapier and Make (formerly Integromat) can bridge Voiceflow to almost any email service. The flow works like this: Voiceflow hits a Zapier webhook URL, Zapier receives the payload, and a Zap sends the email through Gmail, Outlook, SendGrid, or whatever you've connected.

This is the approach most Voiceflow tutorials recommend, and it works fine for low-volume use cases. A few things to watch out for:

Latency. Zapier webhooks add 2 to 5 seconds of delay per trigger. Your user is waiting inside the chatbot while this happens. For a single email, that's tolerable. For a flow that sends multiple messages, it stacks up.

Cost. Zapier's free tier gives you 100 tasks per month. If your chatbot sends one email per conversation and you have 200 conversations a month, you're already paying $19.99/month for the Starter plan. That adds up fast when you factor in the email service cost on top.

Reliability. Zapier occasionally drops webhooks or delays execution during peak hours. There's no built-in retry from the Voiceflow side, so failed sends just disappear unless you add monitoring.

For prototypes and internal tools, Zapier is fine. For production chatbots handling customer-facing email, I'd go with direct API calls instead.

Comparing email providers for Voiceflow#

Not all email APIs are equal when you're calling them from a chatbot. Here's how the common options stack up:

The gap nobody talks about is what happens when your agent needs to receive email too, not just send it. Most of these providers are send-only. If your Voiceflow chatbot needs to check for replies, parse incoming messages, or wait for a verification code, you're looking at a completely different integration. That's where the agent communication stack gets interesting, because email becomes a two-way channel rather than a one-way notification pipe.

Capturing and validating email addresses#

Before you send anything, you need a valid email address. Voiceflow's Capture block can collect user input, but it doesn't validate email format by default.

Add a Function block after your Capture step to check the input:

const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (emailRegex.test(user_email)) {
  email_valid = 'true';
} else {
  email_valid = 'false';
}

Then branch on email_valid. If false, loop back and ask again. Simple, but it catches typos and empty inputs before you waste an API call.

For production use, consider adding a confirmation step: "I'll send the summary to user@example.com. Is that correct?" People fat-finger email addresses constantly, and a mistyped address means a bounced email that counts against your sender reputation.

Sending conversation transcripts#

One of the most common Voiceflow email use cases is sending a conversation transcript to the user. Voiceflow's Transcript API gives you access to conversation history, but pulling it into an email requires a few steps.

In a Function block at the end of your flow, you can build the transcript from the variables you've collected throughout the conversation. A simpler approach: accumulate messages into a transcript variable as the conversation progresses, appending each exchange. Then pass that variable to your email API call.

The Voiceflow documentation has a solid recipe for this using their Transcripts API with Resend. The pattern is: fetch the transcript via API, format it as HTML, send it. If your conversations are short (under 20 exchanges), the in-variable approach is simpler. For longer conversations, the API approach scales better.

When middleware becomes the bottleneck#

Here's something I keep seeing with Voiceflow email setups: the email integration becomes the most fragile part of the entire system. The chatbot logic works perfectly. The NLU handles intent classification well. But the email step fails silently because an API key expired, a Zapier zap got paused, or a rate limit kicked in.

If your agent is doing more than basic notifications, things like signing up for services, responding to inbound messages, or managing ongoing email threads, you might want infrastructure that was designed for agents from the start. LobsterMail takes a different approach: your agent provisions its own inbox and handles email as a native capability rather than a bolted-on integration. There's a whole list of things agents can do with their own email that goes beyond what a simple send-on-trigger setup supports.

Error handling that actually works#

Whatever email provider you choose, build error handling into your Voiceflow flow. Here's the minimum:

1. Check the API response status code in your Function block
2. Store the result in a variable (send_status)
3. Branch your flow: success path shows a confirmation, failure path shows a friendly error and optionally retries once
4. Log failures to an external service (even a simple Google Sheets webhook) so you can spot patterns

Don't let failed emails disappear silently. Your users won't tell you they didn't get the email. They'll just leave.

Testing without sending real emails#

Before you go live, test your integration without hitting real inboxes. Resend and SendGrid both support sandbox modes. You can also use services like Mailtrap or Ethereal to capture outbound emails in a test inbox.

In Voiceflow, use the canvas test mode and hardcode a test email address during development. Switch to the dynamic variable only when you're ready to publish. This prevents accidental sends to real users while you're debugging your flow.