Send email from YouTube when a channel publishes a video, changes a title, or updates a description by receiving YouTube’s native channel-feed push notifications and forwarding the relevant event through Volanea’s REST API. There is no native Volanea YouTube app, marketplace listing, or browser-side plug-in—and that is a good reason to use a controlled server-side relay rather than expose an email credential in an automation configuration.

The supported YouTube trigger: channel feed updates

YouTube does have an outbound HTTP mechanism, but it is narrower than the generic “webhook builder” found in many SaaS products. The YouTube Data API supports channel-feed push notifications through PubSubHubbub, also known as WebSub. Your callback endpoint receives an Atom XML feed entry when a channel uploads a video, updates a video’s title, or updates a video’s description.

That means the concrete trigger for this integration is a YouTube channel feed update. In practical terms, the event you will usually treat as the send trigger is a newly uploaded video, identified by the yt:videoId value in the Atom payload. However, the notification model does not give you a separate event type that guarantees “published publicly for the first time,” so your relay must make an explicit business decision about which updates deserve an email.

This distinction matters. A creator may upload a private video, revise its title twice, change its description, schedule it, and later make it public. The same feed-notification mechanism can alert your endpoint during that lifecycle. If your requirement is “alert staff whenever a channel uploads,” the feed event is enough. If your requirement is “email subscribers only once when a video becomes publicly watchable,” enrich the event with the YouTube Data API before sending and retain a durable record of the video ID.

The core architecture is:

Your server subscribes to the YouTube channel’s feed at the Google PubSubHubbub hub.
The hub verifies that your callback URL is reachable.
YouTube updates the channel feed after an upload or supported metadata change.
The hub sends an Atom XML document to your callback URL.
Your relay parses the XML, decides whether it represents a send-worthy event, and maps it to an email.
Your relay calls Volanea’s POST /v1/send endpoint with a stable Idempotency-Key.

YouTube is the event source; it is not the email-sending runtime. Volanea is the delivery API. Your middleware is the security and reliability boundary between them.

What YouTube sends to your callback

A YouTube channel feed notification is not JSON. It is an Atom XML payload. The useful fields are contained in an entry element, including the YouTube video ID, the channel ID, title, public watch URL, author name, publish time, and update time.

A representative payload has this shape:

<feed xmlns:yt="http://www.youtube.com/xml/schemas/2015"
      xmlns="http://www.w3.org/2005/Atom">
  <link rel="hub" href="https://pubsubhubbub.appspot.com" />
  <link rel="self" href="https://www.youtube.com/xml/feeds/videos.xml?channel_id=UC_CHANNEL_ID" />
  <title>YouTube video feed</title>
  <updated>2026-10-16T15:20:30+00:00</updated>
  <entry>
    <id>yt:video:VIDEO_ID</id>
    <yt:videoId>VIDEO_ID</yt:videoId>
    <yt:channelId>UC_CHANNEL_ID</yt:channelId>
    <title>A new video title</title>
    <link rel="alternate" href="https://www.youtube.com/watch?v=VIDEO_ID" />
    <author>
      <name>Channel name</name>
      <uri>https://www.youtube.com/channel/UC_CHANNEL_ID</uri>
    </author>
    <published>2026-10-16T15:10:00+00:00</published>
    <updated>2026-10-16T15:20:30+00:00</updated>
  </entry>
</feed>

The payload does not include an email address, a customer record, an audience segment, purchase information, or a dependable “publicly published” boolean. Those fields are not missing because of a Volanea setting. They are simply not part of the YouTube channel-feed notification. Your implementation must choose the recipient from server-side configuration, look it up in your own database, or call another system that owns the audience relationship.

For an internal notification, the mapping is straightforward: send to a fixed operations address such as video-alerts@example.com. For a creator workflow, look up the destination address by yt:channelId. For a subscriber announcement, do not infer consent from YouTube subscriptions; use an email list where consent and unsubscribe state are managed independently.

Why the integration needs middleware

YouTube’s native push feature posts XML to a public callback URL. It does not offer a screen where you configure arbitrary downstream HTTP requests with a bearer token, JSON body, headers, retry rules, and a secret vault. Therefore, a direct YouTube-to-Volanea POST is not the supported design.

A small serverless function, container endpoint, or application route is the right middleware layer. It performs four jobs that YouTube cannot do on its own:

Accept the hub’s subscription-verification GET request and return hub.challenge.
Accept and parse the Atom XML POST payload.
Apply your business rules, including deduplication and any follow-up YouTube Data API lookup.
Store the Volanea credential privately and make the authenticated REST request.

This arrangement is also safer than trying to place a secret key in a client-visible page, a frontend bundle, a public query string, or a generic public configuration object. A Volanea secret key authorizes email sends. Anyone who obtains it can potentially send as your verified domain until you revoke or rotate the key.

Use a server-side secret store appropriate for your host: environment secrets for a serverless function, encrypted application configuration, a cloud secret manager, or the protected environment-variable facility provided by your deployment platform. The key should be available only to the runtime that receives and processes trusted events. It must never be returned by an API endpoint, committed to source control, embedded in a static site, or logged when a request fails.

Set up the YouTube channel subscription

Before your callback can receive notifications, subscribe it to the channel’s feed through the Google PubSubHubbub hub. The feed topic uses the channel ID, not the channel handle, custom URL, or display name.

Use this topic format:

https://www.youtube.com/xml/feeds/videos.xml?channel_id=UC_CHANNEL_ID

Your callback URL must be publicly reachable over HTTPS and must respond to the hub’s verification request. During verification, the hub issues a GET request containing query parameters such as hub.mode, hub.topic, and hub.challenge. Your callback validates the topic and returns the exact challenge value as plain text.

A subscription request can be made server-side or from a secure administrator script:

curl -X POST https://pubsubhubbub.appspot.com/subscribe \
  --data-urlencode "hub.mode=subscribe" \
  --data-urlencode "hub.topic=https://www.youtube.com/xml/feeds/videos.xml?channel_id=UC_CHANNEL_ID" \
  --data-urlencode "hub.callback=https://automation.example.com/webhooks/youtube" \
  --data-urlencode "hub.verify=sync"

Treat the channel ID and expected feed topic as configuration, not as values supplied by an incoming request. That makes it possible to reject a callback verification request for an unexpected channel and prevents a general-purpose endpoint from being silently subscribed to arbitrary feeds.

The subscription process is separate from email delivery. No Volanea API key belongs in this request. YouTube only needs the callback URL and topic; your server needs the Volanea secret later, when it decides to send an email.

Working Node.js relay: Atom XML to Volanea email

The example below uses Express and fast-xml-parser. It handles the callback verification handshake, parses the incoming Atom XML, escapes user-controlled text before placing it in HTML, uses the yt:videoId as the durable identity for an email event, and posts the completed message to Volanea.

Install the dependencies:

npm install express fast-xml-parser

Set these server-side environment variables before deploying:

YOUTUBE_CHANNEL_ID=UC_CHANNEL_ID
VOLANEA_API_KEY=sk_...
VOLANEA_FROM=Video Alerts <alerts@your-verified-domain.example>
NOTIFY_TO=ops@example.com

Then use this relay:

import express from "express";
import { XMLParser } from "fast-xml-parser";

const app = express();

const CHANNEL_ID = process.env.YOUTUBE_CHANNEL_ID;
const VOLANEA_API_KEY = process.env.VOLANEA_API_KEY;
const VOLANEA_FROM = process.env.VOLANEA_FROM;
const NOTIFY_TO = process.env.NOTIFY_TO;

if (!CHANNEL_ID || !VOLANEA_API_KEY || !VOLANEA_FROM || !NOTIFY_TO) {
  throw new Error("Missing required server-side environment variables");
}

const TOPIC =
  `https://www.youtube.com/xml/feeds/videos.xml?channel_id=${CHANNEL_ID}`;

const xmlParser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: "@_",
  removeNSPrefix: false,
  trimValues: true
});

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

function asArray(value) {
  return Array.isArray(value) ? value : value ? [value] : [];
}

// The hub calls this endpoint to verify that we control the callback URL.
app.get("/webhooks/youtube", (req, res) => {
  const mode = req.query["hub.mode"];
  const topic = req.query["hub.topic"];
  const challenge = req.query["hub.challenge"];

  if (mode !== "subscribe" || topic !== TOPIC || !challenge) {
    return res.status(400).send("Invalid YouTube subscription verification");
  }

  return res.type("text/plain").status(200).send(String(challenge));
});

// YouTube sends an Atom XML feed document, not JSON.
app.post(
  "/webhooks/youtube",
  express.text({ type: ["application/atom+xml", "application/xml", "text/xml", "*/*"] }),
  async (req, res) => {
    try {
      const feed = xmlParser.parse(req.body);
      const entries = asArray(feed?.feed?.entry);

      if (entries.length === 0) {
        return res.status(204).send();
      }

      for (const entry of entries) {
        const videoId = entry["yt:videoId"];
        const channelId = entry["yt:channelId"];
        const title = entry.title || "Untitled YouTube video";
        const author = entry.author?.name || "YouTube channel";
        const publishedAt = entry.published || "";
        const updatedAt = entry.updated || "";

        const alternateLink = asArray(entry.link).find(
          (link) => link?.["@_rel"] === "alternate"
        );
        const videoUrl =
          alternateLink?.["@_href"] ||
          `https://www.youtube.com/watch?v=${encodeURIComponent(videoId)}`;

        // Reject events for any feed other than the configured channel.
        if (!videoId || channelId !== CHANNEL_ID) {
          continue;
        }

        // The same video may create notifications for upload and metadata updates.
        // This key intentionally allows one notification email per video.
        // Change the key if your business rule requires update alerts as well.
        const idempotencyKey = `youtube-video-alert:${channelId}:${videoId}`;

        const subject = `New YouTube video: ${title}`;
        const text = [
          `${author} has a YouTube video update.`,
          "",
          `Title: ${title}`,
          `Watch: ${videoUrl}`,
          `Video ID: ${videoId}`,
          `Published: ${publishedAt}`,
          `Updated: ${updatedAt}`
        ].join("\n");

        const html = `
          <h1>New YouTube video</h1>
          <p><strong>${escapeHtml(author)}</strong> has a video update.</p>
          <p><strong>Title:</strong> ${escapeHtml(title)}</p>
          <p><a href="${escapeHtml(videoUrl)}">Watch the video</a></p>
          <p><strong>Video ID:</strong> ${escapeHtml(videoId)}<br>
          <strong>Published:</strong> ${escapeHtml(publishedAt)}<br>
          <strong>Updated:</strong> ${escapeHtml(updatedAt)}</p>
        `.trim();

        const volaneaResponse = 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({
            from: VOLANEA_FROM,
            to: [NOTIFY_TO],
            subject,
            text,
            html
          })
        });

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

      return res.status(204).send();
    } catch (error) {
      console.error("YouTube webhook processing failed", error);
      return res.status(500).send("Unable to process YouTube notification");
    }
  }
);

app.listen(process.env.PORT || 3000, () => {
  console.log("YouTube relay is listening");
});

The meaningful field mapping is explicit in the code: entry["yt:videoId"] becomes both the event identity and part of the idempotency key; entry.title becomes the subject and email content; the alternate Atom link becomes the email CTA; entry.author.name, entry.published, and entry.updated are included as context. The recipient and sender are deliberately sourced from protected server configuration because YouTube does not send email-recipient data in this payload.

For more endpoint options, templates, domains, and message fields, consult the email API reference and setup guides before extending the relay.

Decide what counts as a send-worthy event

The most common mistake in this integration is assuming that every notification represents a brand-new public video. YouTube’s documented feed notifications also cover title and description updates. If your handler sends immediately for every XML entry, a routine title edit can produce another email.

Start with a clear policy. An internal team alert may reasonably be one email per video ID, regardless of later metadata edits. A content operations workflow might want one notification for the initial upload and another only when the title changes. A subscriber announcement flow generally needs a stricter public-availability check and consent-aware audience logic.

One email per video

The code above implements the safest default for internal notifications: one logical email per channel and video ID. It creates the idempotency key youtube-video-alert:<channelId>:<videoId>. If the same event is delivered again while Volanea retains the idempotency result, the repeated request does not create a second email.

This policy deliberately ignores later title and description changes. That is desirable if the message says “a new video is available,” but not if your message promises current metadata. For that case, fetch the current video resource before composing the email, then store your own event state so an update policy remains predictable after the idempotency retention window ends.

Alert on title or description changes

If editorial changes matter, include a version signal in your persistent database record. For example, store the last processed updated timestamp and a normalized title. When another notification arrives for the same video ID, compare the newly received fields to the stored values and send only when the change meets your rule.

Do not use the received timestamp alone as a permanent deduplication strategy. It distinguishes updates, but it does not prove that a video is public, does not remove the possibility of a repeated delivery, and does not preserve the business context of why an email was sent.

Email a marketing audience only after an eligibility check

A YouTube feed is a content event, not an email-marketing consent event. If you plan to email a list, your relay should first verify that the video meets your release criteria and then send only to contacts eligible for that type of communication.

In particular, never treat a YouTube subscriber as an email subscriber. YouTube subscriptions and email consent are separate relationships, with different privacy expectations and unsubscribe requirements. Maintain consent, suppression, and audience rules in the system that owns your email contacts.

Auth handling: where the Volanea API key belongs

The Volanea API key belongs in your middleware’s private server-side secret configuration. In the Node example, it is read from process.env.VOLANEA_API_KEY and inserted only into the outbound Authorization: Bearer ... header when the server calls https://api.volanea.com/v1/send.

It does not belong in YouTube Studio, a YouTube channel description, an embed script, the callback URL, a client-side JavaScript variable, or an Atom feed subscription request. YouTube’s push-notification flow does not need the Volanea key, and a visitor’s browser has no legitimate reason to receive it.

A useful operational separation is:

YouTube channel ID: configuration that identifies which channel feed your endpoint accepts.
Callback URL: public HTTPS address that must receive verification and notification traffic.
Volanea API key: private credential available only to the relay runtime.
Sender identity: a Volanea-configured sender from a verified domain.
Recipient or audience lookup: a server-side setting or database query, never an untrusted raw feed field.

Use a restricted operational process around key rotation. Create a replacement key, deploy it as a secret, confirm a controlled test send, and revoke the old key. Avoid printing authorization headers or full Volanea error requests to logs; sanitized correlation information such as the YouTube video ID and Volanea response status is normally enough for troubleshooting.

Deliverability choices for YouTube-triggered email

A technically successful API request is only the first step. The email still needs a recognizable sender, authenticated domain, relevant content, and an appropriate sending pattern. Configure VOLANEA_FROM to use a domain you control and have verified, rather than a personal mailbox or a domain unrelated to your organization.

The message should make the event obvious in the subject line. “New YouTube video: Building a webhook relay” is more useful than “Notification.” Keep the email concise, include the actual YouTube watch URL, and provide a plain-text alternative alongside HTML as the example does.

For internal alerts, a fixed operations inbox is usually enough. For customer-facing sends, use an audience that expects these messages, preserve opt-out status, and avoid turning frequent metadata edits into bursts of mail. A channel that publishes daily should not necessarily send a daily email to every contact; the appropriate frequency is a product and consent decision, not a webhook configuration detail.

If you need predictable message volume or want to understand the cost model before building a multi-recipient workflow, review transactional email pricing. For simple event notifications, one direct transactional send per qualifying event is easier to audit than routing content updates through an untracked mailbox or a consumer email account.

When this breaks

Every integration has two hops: YouTube-to-your-callback and your-callback-to-Volanea. Treat failures independently. A successful YouTube delivery does not prove that an email was accepted, and an accepted email send does not prove that YouTube will notify you about every content lifecycle change you care about.

A repeated YouTube notification causes duplicate sends

Webhook-style delivery must be treated as at-least-once, not exactly-once. If a callback response is lost, delayed, or returns a failure status after your code has already started processing, the upstream side can retry. You may also receive separate notifications for an upload and subsequent title or description updates.

Use two layers of protection. First, make your handler idempotent at the application layer by retaining processed event records keyed by channel ID, video ID, and your chosen event policy. Second, send the same stable Idempotency-Key to Volanea for retries of the same logical email. Do not generate a new random idempotency key each time the callback runs; that would turn a retry into a brand-new email request.

The example key is intentionally conservative: one email per video. If the business requirement is one email per qualifying version, persist a version or semantic event type yourself and derive the key from that durable state, such as youtube-public-release:<videoId>.

Your callback times out or does too much work synchronously

The hub expects a responsive endpoint. If your route calls multiple external APIs, renders a complex template, scans a large database, and then waits for an email response before acknowledging the POST, transient latency becomes a delivery risk.

For a low-volume internal alert, the simple synchronous example is often suitable. For production workflows, store the parsed event and enqueue a job quickly, then return a success response. A worker can perform metadata enrichment, audience selection, and the Volanea send with controlled retries. The durable queue record also gives you a place to inspect failures without asking YouTube to replay an old notification.

Expected payload fields are absent

The YouTube Atom feed contains feed and video metadata, not a full videos resource. It does not include your email recipient, contact properties, subscriber consent, campaign segment, or a reliable generic “published to public” flag. Those fields are unavailable by design, not unlocked by selecting a different YouTube plan.

If you need additional video information, use the yt:videoId from the notification to retrieve the appropriate video resource through the YouTube Data API. That separate request may require an API key or OAuth authorization depending on the data you need. Handle absent thumbnails, descriptions, author values, and links defensively even after enrichment, because integrations should not fail merely because optional presentation data is unavailable.

The callback fails verification

A failed subscription verification almost always means the callback is inaccessible, it does not return hub.challenge exactly, or it rejects the expected hub.topic. Check that the deployed URL is HTTPS, publicly reachable, and not intercepted by an authentication wall, browser challenge page, or redirect that the hub cannot use.

Also verify the topic string exactly. The configured channel ID must match the expected feed URL, including the https://www.youtube.com/xml/feeds/videos.xml?channel_id= format. A channel handle such as @examplechannel is not a substitute for the channel ID in this feed topic.

Volanea rejects the request

A 4xx response usually means the request must be corrected rather than blindly retried. Check that Authorization has the Bearer scheme, the sender uses an approved sending domain, the to array contains valid recipient addresses, and the JSON body uses the supported field names.

A network error, timeout, or temporary 5xx response should be retried from your worker with the same idempotency key and the same logical message body. Log the video ID, channel ID, idempotency key, HTTP status, and returned Volanea message identifier when available. Do not log the API key or full recipient data unnecessarily.

Testing the complete path safely

Test each boundary separately before relying on the workflow for a launch or customer communication. Starting with a real upload can make diagnosis slow because you do not know whether the subscription, feed notification, XML parsing, rule evaluation, or email API call was the first problem.

Use this test sequence:

Deploy the callback and call its GET verification route with harmless test query parameters to confirm it returns only the supplied challenge when the topic is expected.
Submit the subscription request and confirm that the hub’s actual verification GET succeeds.
POST a saved representative Atom XML document to a non-production version of the callback and confirm the parser extracts yt:videoId, title, author, and alternate URL.
Set NOTIFY_TO to a controlled inbox and use a verified test sender to validate the Volanea request, HTML output, text fallback, and subject line.
Upload a test video on the subscribed channel, then inspect your relay logs and Volanea send records.
Edit the video title and confirm that your deduplication policy behaves as intended rather than sending an unexpected second message.

A disciplined test makes the operational contract clear: the feed delivers a content-change signal, your application determines whether that signal merits email, and Volanea handles the outbound send. Keep a small fixture XML file in your test suite so parser changes and library upgrades cannot silently break namespace handling.

Alternatives when the native feed is not enough

YouTube’s native push notifications are the direct route for channel-feed changes, and they are the best fit when your requirement begins with “a channel uploaded or updated a video.” They are not a general automation platform. There is no native YouTube trigger for every creator workflow, no built-in recipient collection, and no arbitrary outbound request designer in YouTube Studio.

If your desired trigger lives outside the channel feed—for example, a form submission, a membership event, a CRM stage change, or a purchase—you need that other system to trigger the email. A workflow tool can sometimes act as middleware, but it still needs a safe place to hold the Volanea credential and a deliberate mapping from event fields to sender, recipient, subject, and content.

For a YouTube upload notification, a direct WebSub callback plus a small serverless relay is generally more transparent than adding layers of automation. You can see the raw Atom payload, make explicit deduplication decisions, enrich with the YouTube Data API only when needed, and retain ownership of email credentials and logic.

Conclusion

To send email from YouTube with Volanea, subscribe a secure callback endpoint to the YouTube channel’s Atom feed, parse the XML notification, and call Volanea from server-side code. The actual trigger is a channel feed update—most notably an upload, title update, or description update—not a marketplace app event or a generic YouTube automation action.

The robust implementation is intentionally modest: store the Volanea key only in protected runtime secrets, map yt:videoId, title, author, and the watch link into a clear transactional email, and use a stable idempotency key plus durable event tracking to prevent duplicate sends. Once that foundation is working, you can add video-resource enrichment, a queue, audience rules, and templates without changing the security model.

FAQ

Can YouTube send an email directly through Volanea?

Not directly. YouTube can push channel-feed notifications to your public callback endpoint through PubSubHubbub/WebSub, but your server-side relay must parse the Atom XML and call Volanea’s REST API. There is no native Volanea YouTube marketplace app or YouTube Studio plug-in flow.

What YouTube event starts the email?

The trigger is a YouTube channel feed update. YouTube documents notifications for video uploads, title updates, and description updates. Your code decides which of those events should result in an email.

Does the YouTube webhook include the recipient email address?

No. The Atom notification includes video and channel metadata, such as yt:videoId, yt:channelId, title, author, watch URL, and timestamps. Choose recipients through protected configuration, your application database, or a consent-aware contact system.

How do I stop duplicate YouTube alert emails?

Deduplicate using a durable application record and send Volanea a stable Idempotency-Key derived from the logical event, such as the channel ID and video ID. Reuse that same key whenever the same event is retried.

Should I send an email for every YouTube title edit?

Usually not. A title or description change can produce a feed notification after the original upload. For internal alerts, one email per video ID is a practical default. For editorial workflows, store prior metadata and send only when a meaningful change meets your defined rule.

How to Send Email From YouTube With Volanea