How to Send Email from Notion with Volanea

Send email from Notion without copying addresses into another tool: use a Notion database automation to POST selected page properties to a secure relay, then have that relay call Volanea’s email API. This is the dependable pattern because Notion can trigger outbound webhooks on paid plans, but it is not a safe place to keep a sending API key.

Volanea does not provide a native Notion app, Marketplace listing, or one-click Notion plugin. The integration is still straightforward: a database page changes state in Notion, Notion’s Send webhook action posts its selected properties to your endpoint, and your endpoint validates and maps that data into POST /v1/send.

The example in this guide uses a common operational trigger: a page in a Notion database has its Status property set to Ready to send. You can adapt the same design for a page added to a database, a lead captured through a Notion form, an invoice marked approved, or a manually clicked button. The important part is that the email is modeled as a deliberate database workflow, not as an uncontrolled side effect of every edit.

The integration architecture

The safe architecture has three hops:

1. A user updates a page in a Notion database.
2. A database automation runs when the page’s Status is set to Ready to send, then uses Send webhook to POST selected page properties to your endpoint.
3. Your serverless function or application endpoint validates the incoming request, prevents a duplicate send, and calls Volanea with the secret API key.

That middle service can be a Cloudflare Worker, AWS Lambda, Vercel Function, containerized application endpoint, or another server-side runtime. It does not need to be large. Its job is to be the security and reliability boundary between a collaborative workspace and your email infrastructure.

Do not point Notion directly at Volanea’s send endpoint. Notion’s webhook action supports a URL and optional custom headers, but placing a Volanea secret key in an automation header would expose a credential to people who can inspect or edit that automation. It also removes the place where you should validate input, enforce recipient rules, generate an idempotency key, and convert Notion’s selected properties into a deliberate email request.

The relay gives you a clean separation of responsibilities:

• Notion owns the business decision: this database page is ready to generate an email.
• Your relay owns authorization, validation, deduplication, observability, and formatting.
• Volanea owns the authenticated send request and downstream email delivery pipeline.

This division is more than a security preference. It means an accidental Notion property change cannot send arbitrary content to an arbitrary address merely because someone gained access to a workspace database.

What Notion can actually send

Notion has native outbound HTTP capability through its Send webhook automation action. It is available on paid plans for buttons, database buttons, and database automations. The action sends an HTTP POST request to a URL you provide. In a database automation, you can choose database page properties to include in the webhook content.

For this workflow, use a database automation, not an integration webhook subscription. The two features solve different problems:

• A database automation webhook action is the outbound request that Notion sends because your workflow condition occurred.
• An integration webhook is intended for software integrations that subscribe to events from Notion and then fetch current data through the Notion API.

A database automation is the right fit when you want an editorial or operational state transition—such as Draft to Ready to send—to initiate the workflow. Notion’s automation model calls each row a page in a database, so throughout this guide “record” means a Notion database page.

There are limitations that affect email design. Notion webhook actions support POST only. They can send database page properties, but not page contents. A database button cannot select properties for the webhook content in the same way a database automation can. Notion also does not provide a built-in payload preview, so you should capture a non-production request at a request-inspection endpoint before implementing your production mapping.

That last point is important: property types affect their JSON representation. A text property, select property, multi-select property, person, relation, date, and formula value are not interchangeable. Your receiver should validate exactly the fields you selected, and your setup process should record a sample from your own workspace before you go live.

Build the Notion database for an email event

Start with a database dedicated to outbound operational messages. You can call it Email queue, Customer notices, Application replies, or something that matches your process. Keep the structure explicit enough that a teammate can determine why an email will send by reading one page.

For the example, create these properties:

The Email event ID deserves special attention. Give each page a stable unique value when it is created. A UUID is ideal, but a durable internal ID will work if it is truly unique across message events. Do not use Status, the recipient email address, or a timestamp rounded to minutes as the idempotency identifier; any of those can collide or change.

Use a status property rather than triggering on any edit. If your automation triggers on a broad condition such as “page is edited,” an innocuous correction to a recipient’s name can resend a message. A narrow trigger—when Status is set to Ready to send—makes intent visible and reduces accidental sends.

You should also decide who may move a page into Ready to send. If sending an email has customer-facing, contractual, or regulated consequences, treat the status transition as an approval step. A useful workflow is:

• Draft: content and recipient can still change.
• Review: a teammate checks wording, recipient, and consent.
• Ready to send: the automation sends exactly one email event.
• Sent: the relay accepted a successful Volanea response and recorded it.
• Failed: a validation or API failure needs review.

Notion database automations cannot be triggered by other database automations. A button action can trigger a database automation, but an automation writing a property should not be your mechanism for chaining another email automation. Design the workflow so one deliberate status change initiates the email, then let your relay or an operator handle the result state.

Configure the Notion database automation

Open the relevant database and select the lightning-bolt automation control, then create a new database automation. The exact visual layout may evolve, but the configuration should express the following logic:

• Trigger: Status is set to Ready to send.
• Action: Send webhook.
• Webhook URL: your public HTTPS relay endpoint, such as https://example.com/hooks/notion-email.
• Content: select Recipient email, Recipient name, Subject, Message, Email event ID, and Status.
• Custom header: a shared inbound secret, for example X-Notion-Relay-Token: <long-random-value>.

The custom header is not the Volanea API key. It is only a separate secret that lets your relay reject random internet traffic before it processes a payload. Generate it as a long random value, store its matching copy as a server-side secret, and rotate it if an editor who had access to the automation should no longer have that access.

Notion says webhook actions themselves do not require authentication, which means the receiver must take responsibility for authenticating or otherwise authorizing incoming requests. A hard-to-guess URL alone is not sufficient protection for an email-sending endpoint. Use the custom header plus validation and rate controls.

Select only the properties needed to create the message. Minimal payloads make schema changes safer and reduce the chance of leaking internal data. For example, do not send a customer’s full notes field, internal approval comments, or related database values merely because they are convenient to select.

The Notion webhook payload and field mapping

A Notion Send webhook action posts the database page properties selected in the database automation. Notion does not publish a fixed, universal payload schema for webhook actions or offer an in-product payload preview; it specifically recommends sending a test to an inspection endpoint to see the request from your database. Therefore, treat your captured test request as the contract for your workspace and pin your receiver to the selected property names.

For the property set in this guide, configure and test the relay against this payload shape—the selected property names are the keys the relay expects:

{
  "Recipient email": "maya@example.com",
  "Recipient name": "Maya Chen",
  "Subject": "Your request has been approved",
  "Message": "Hi Maya,\n\nYour request is approved and ready for the next step.\n\nThanks,\nThe Example team",
  "Email event ID": "c5f9f341-9d60-45de-bd9a-5f1f5159ea08",
  "Status": "Ready to send"
}

Before production, send a test page through the actual Notion automation and compare the received JSON with your receiver’s logs. If your workspace produces a different representation for a property type, update the extraction function rather than guessing. This guide intentionally uses simple Email and Text properties because they are easier to validate than formulas, rollups, relations, or rich page content.

The relay maps those fields as follows:

Keep the from address out of Notion. Configure it in the relay as a server-side environment variable, such as EMAIL_FROM=Example Team <updates@example.com>. This prevents a database editor from impersonating a different sender and ensures every message uses an address from a sending domain you have verified in Volanea.

Working webhook relay code

The following example is a minimal Cloudflare Worker-style endpoint. It accepts Notion’s POST, verifies a shared header, validates the selected properties, derives a safe HTML alternative from the plain-text message, and sends the mapped request to Volanea.

Store VOLANEA_API_KEY, NOTION_RELAY_TOKEN, and EMAIL_FROM as server-side runtime secrets or environment variables. Do not hard-code them in source control.

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", {
        status: 405,
        headers: { Allow: "POST" },
      });
    }

    // This is an inbound relay secret configured as a Notion custom header.
    // It is NOT the Volanea API key.
    const relayToken = request.headers.get("X-Notion-Relay-Token");
    if (!relayToken || relayToken !== env.NOTION_RELAY_TOKEN) {
      return new Response("Unauthorized", { status: 401 });
    }

    let notion;
    try {
      notion = await request.json();
    } catch {
      return new Response("Expected JSON", { status: 400 });
    }

    // Field mapping from the selected Notion database properties.
    const recipientEmail = String(notion["Recipient email"] || "").trim();
    const recipientName = String(notion["Recipient name"] || "").trim();
    const subject = String(notion["Subject"] || "").trim();
    const text = String(notion["Message"] || "").trim();
    const eventId = String(notion["Email event ID"] || "").trim();
    const status = String(notion["Status"] || "").trim();

    if (status !== "Ready to send") {
      return new Response("Page is not ready to send", { status: 422 });
    }

    if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(recipientEmail)) {
      return new Response("Invalid Recipient email", { status: 422 });
    }

    if (!subject || !text || !eventId) {
      return new Response("Missing Subject, Message, or Email event ID", {
        status: 422,
      });
    }

    const escapeHtml = (value) =>
      value
        .replaceAll("&", "&")
        .replaceAll("<", "&lt;")
        .replaceAll(">", "&gt;")
        .replaceAll('"', "&quot;")
        .replaceAll("'", "&#039;");

    const greeting = recipientName
      ? `Hi ${escapeHtml(recipientName)},<br><br>`
      : "Hello,<br><br>";

    // This is the Volanea REST API call created from the Notion properties.
    const volaneaResponse = await fetch("https://api.volanea.com/v1/send", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${env.VOLANEA_API_KEY}`,
        "Content-Type": "application/json",
        // Reusing this stable value makes a retry of the same Notion page
        // safe instead of creating a second logical send.
        "Idempotency-Key": eventId,
      },
      body: JSON.stringify({
        from: env.EMAIL_FROM,
        to: [recipientEmail],
        subject,
        text,
        html: `<p>${greeting}${escapeHtml(text).replaceAll("\n", "<br>")}</p>`,
      }),
    });

    const result = await volaneaResponse.text();

    if (!volaneaResponse.ok) {
      console.error("Volanea send failed", {
        status: volaneaResponse.status,
        eventId,
        response: result,
      });
      return new Response("Email provider rejected the request", {
        status: 502,
      });
    }

    console.log("Volanea send accepted", { eventId, response: result });
    return new Response("Accepted", { status: 200 });
  },
};

The Volanea request uses POST /v1/send, bearer authentication, JSON content, a verified from address, one recipient in to, and both text and HTML message content. The Idempotency-Key header is the key reliability control: the same Notion email event should have the same key on every retry.

For a more sophisticated implementation, store the event ID and resulting response in a database before or alongside the send request. That allows operators to inspect an event later and distinguish “Notion fired twice” from “the relay retried after a timeout.” It also lets you write a Sent status and delivery reference back to Notion through the Notion API, although that write-back should be designed carefully so it does not trigger another send automation.

For endpoint options, authentication patterns, and sending capabilities beyond this focused example, see the email API reference and setup guides.

Where the Volanea API key belongs

The Volanea API key belongs only on the server side: in a Cloudflare Worker secret, Lambda environment secret, Vercel encrypted environment variable, secrets manager, or another protected runtime configuration mechanism. It does not belong in a Notion property, formula, page body, automation URL, automation custom header, browser application, public repository, or client-visible configuration file.

The distinction between the two credentials in this integration matters:

• NOTION_RELAY_TOKEN is an inbound shared secret stored in the Notion webhook action as a custom header and checked by your relay. It limits who can invoke that one endpoint, but it should be considered accessible to people with relevant Notion automation editing access.
• VOLANEA_API_KEY is the email infrastructure credential stored exclusively in the relay environment. It authorizes calls to Volanea and must never transit through Notion.

Why not place the Volanea key in a custom Notion header? First, anyone with enough access to view or edit the automation may be able to access or replace it. Second, the key could appear in exports, screenshots, browser tooling, audit trails, or support investigations. Third, it would grant a Notion configuration direct email-sending authority without the validation controls in your relay.

Use separate keys and rotate them independently. If the Notion relay token leaks, replace it in the automation and deployment. If the Volanea API key leaks, revoke or rotate it in Volanea and update only your server-side secret. Keeping those incidents separate reduces blast radius.

Make the send operationally safe

A webhook integration is not complete when the first test email arrives. Email is a side effect, and side effects need intentional controls.

Validate before sending

Validate recipient addresses, required fields, permitted statuses, subject length, and message length before calling Volanea. If only company recipients should receive these messages, enforce an allowlist domain rule. If the database is a customer communication queue, validate consent and business conditions in the relay or upstream workflow rather than assuming every email property is eligible.

A useful policy is to reject any payload that has fields you do not expect, especially in workflows that can send externally. This makes a Notion property rename or automation reconfiguration fail visibly rather than silently changing an email template.

Keep sender identity server-controlled

The from address should be a constant server-side configuration value. Never map a Notion text field directly to from, replyTo, custom headers, tracking configuration, or arbitrary template identifiers unless the relay uses a strict allowlist.

This avoids both sender spoofing and accidental deliverability problems. Your sender should belong to a domain configured for sending in Volanea, with the appropriate domain authentication records in place.

Use a real event ID, not request randomness

Generate one identifier per intended email event and reuse it whenever the same event is retried. In this guide, that is Email event ID. A random ID generated anew inside the relay defeats idempotency because each retry would look like a new send.

If you use an external queue or database, persist a record keyed by that event ID. Save the original recipient, subject fingerprint, message fingerprint, provider response, timestamp, and final status. This gives you a durable audit trail even if Notion properties later change.

Separate acceptance from delivery

A successful response to the send endpoint means the request was accepted for sending; it is not the same as proof that a recipient opened, received, or acted on the email. Build operational reporting around the email events and delivery outcomes relevant to your account, rather than treating the Notion automation’s lack of an error indicator as final delivery confirmation.

For recipient-quality checks before a message enters the queue, use an email address verification tool as one signal among others. Verification does not replace permission, suppression handling, or a deliberate transactional versus marketing classification.

When this breaks: Notion-to-relay failure modes

The weak point in this workflow is not merely “webhooks can fail.” It is the specific boundary where a Notion database automation makes an HTTP request to your relay. Design for the actual failure modes at that hop.

Notion retries or a user re-triggers the event

A timeout can leave Notion or an operator uncertain whether the relay received the request. A user might move Status out of Ready to send and back again. The same database page can also be duplicated or edited in ways that create a second event.

Without protection, these cases can produce duplicate email. The first line of defense is Idempotency-Key: Email event ID on the Volanea request. The second is a relay-side event table or durable store that records each ID before doing downstream work. The third is workflow design: after a successful send, move the page to Sent and make Ready to send an explicit, controlled state.

Do not assume a POST is exactly-once delivery. Treat it as at-least-once behavior and make the downstream side effect idempotent.

The relay takes too long to answer

Your endpoint should validate, claim the event ID, send to Volanea, and return a response promptly. If it performs slow enrichment, PDF generation, unbounded database queries, or calls to multiple third-party services before responding, it increases timeout risk and therefore duplicate-risk pressure.

For complex work, accept the webhook quickly after persisting a job and process the job asynchronously. Preserve the same event ID from Notion through the queue and onto the Volanea Idempotency-Key header. That way, a redelivery does not become a second email even if the first worker is still processing.

A selected Notion property is missing or changes shape

Properties may be empty on some pages. A page created from a template might not populate the recipient field. Someone may rename Recipient email, convert Message from text to another property type, or remove the property from the webhook content selection.

Your relay must fail closed. Return an error for a blank recipient, blank subject, blank message, blank event ID, or unexpected status. Log the event ID and the names of missing fields, but avoid logging full message bodies or customer addresses unnecessarily.

Notion’s webhook action only sends database page properties, not page contents. If your actual email body is written in the page body rather than the Message property, it will not arrive through this webhook action. Either move the required content into a selected property, use a server-side Notion API fetch with appropriate authorization, or use a template in Volanea with approved variables. Do not assume page text is automatically included.

The automation is paused after a failure

Notion indicates that a failed webhook action can cause the automation to be paused, requiring a manual resume. Make this a documented operational check. If messages stop sending, inspect the database automation for its error indicator before assuming the email provider is down.

A practical runbook should include: inspect Notion’s automation state, inspect relay logs by Email event ID, inspect the Volanea API response or message events, fix the underlying issue, resume the Notion automation, and deliberately requeue only the affected pages.

Someone calls your webhook URL directly

A public webhook endpoint will receive scans and unwanted traffic. Reject requests without the relay token, enforce a strict method check, validate JSON, restrict payload sizes, and rate-limit at your edge. If your platform supports it, place the endpoint behind a Web Application Firewall rule that allows only POST to its exact route.

Because Notion’s outbound automation webhook action does not give you a provider-signed payload verification flow documented for this use case, the shared custom header is a practical minimum. For higher-risk workflows, place the endpoint behind an authenticated gateway or use a relay platform that provides stronger ingress controls, then preserve the same idempotency design downstream.

Direct relay versus Zapier or Make

You have two reasonable integration paths, depending on who owns the workflow and how much control you need.

Direct Notion webhook to your relay

Choose this when you can deploy a small endpoint and need strong control over validation, authorization, logging, idempotency, custom templates, and failure handling. The code example in this guide uses that pattern.

Advantages include a server-side Volanea key, consistent source control for mapping logic, direct control of response behavior, and no requirement to let a no-code workflow tool hold the sending credential. It is usually the best production option for customer-facing messages, invoices, approval notices, or other emails where duplicates are costly.

Notion webhook to Zapier or Make, then Volanea

Choose an automation platform when the workflow owner needs a visual builder and accepts its execution model, pricing, credential storage, and operational conventions. Notion explicitly positions webhook actions as a way to initiate workflows in tools such as Zapier and Make.

The safe version is still not “paste the Volanea key into a broadly shared workspace and hope.” Use the platform’s protected connection or secret facility where available, restrict editor access, map only approved fields, and implement an event ID or deduplication step. If your Zapier or Make plan cannot reliably provide the input fields, custom headers, or error handling you require, use the direct relay instead.

For either approach, document exactly which party owns retry decisions. A second automation tool can add another retry layer, which makes a stable idempotency key even more important.

Testing before you let Notion email customers

Use a staged rollout. First, point the Notion webhook at a request inspection endpoint or a non-production version of your relay. Trigger a page transition and save the actual JSON body and headers received from your workspace. Confirm the property names and value representations before you point anything at a live sender.

Then test the following cases in a Volanea test or controlled environment:

1. A normal page with every required property populated.
2. A blank Recipient email value.
3. An invalid recipient address.
4. A status other than Ready to send.
5. The same exact payload twice with the same Email event ID.
6. Two different pages with different event IDs but the same recipient.
7. A message containing <, >, &, quotes, and multiple line breaks.
8. A Notion automation failure followed by manual resume and intentional requeue.

Do not limit testing to delivery. Inspect the received text and HTML versions, make sure the from address is expected, verify no internal fields appeared in the content, and confirm your logs provide enough information to investigate an incident without storing unnecessary personal data.

Once you are satisfied, start with an internal recipient allowlist. Move to a small controlled production workflow, then expand. This protects your sending reputation and gives you time to catch schema assumptions before they reach customers.

Conclusion

The reliable way to send email from Notion with Volanea is not a nonexistent native plugin. It is a focused automation architecture: a Notion database page moves to Ready to send, Notion posts selected properties to a protected relay, and the relay creates an authenticated, idempotent Volanea send request.

This pattern keeps a powerful email API key out of a collaborative workspace, makes the email trigger visible to your team, and gives you a place to control recipient rules, HTML encoding, logging, retries, and duplicate prevention. Start with simple Email and Text properties, capture the exact payload from your own workspace, and treat Email event ID as the permanent identity of one intended email—not one HTTP attempt.

FAQ

Can Notion send an HTTP webhook directly?

Yes. On paid plans, Notion’s Send webhook action can send an HTTP POST request from buttons, database buttons, and database automations. For email workflows, a database automation triggered when a Status property is set to a chosen value is usually the clearest model.

Is there a native Volanea integration in the Notion Marketplace?

No. Volanea does not ship a native Notion app, Marketplace listing, or plugin. Use Notion’s webhook action with a secure middleware endpoint, or route the webhook through an automation platform such as Zapier or Make.

Can I put my Volanea API key in a Notion webhook header?

You should not. Store the Volanea API key only in server-side secret storage. A Notion custom header may hold a separate inbound relay token, but it is not an appropriate home for your email-sending credential.

Why did one Notion page send two emails?

The webhook may have been retried, the status may have been set to Ready to send more than once, or the first request may have completed while its response was lost. Use one stable Email event ID per intended message and pass it in Volanea’s Idempotency-Key header on every attempt.

Can the email body come from the Notion page body?

Not through the database webhook action alone. Notion webhook actions can send database page properties, not page content. Put a concise message in a selected property, fetch page content server-side through the Notion API, or use an approved Volanea template with controlled variables.